Family table craziness

[kwsauter]

This is what drives me stark raving nuts with Proe. I have an assembly
family table with 12 different instances of the assembly in it. You
know, the usual stuff: some parts and assemblies suppressed, others
showing, depending on the instance. Everything was fine on Friday.
Today, I have a number of instances that should show certain assemblies
according to the family table, but when I open those instances, lo and
behold, there's nothing there! Either I have 1-3 parts showing, or
nothing at all. Some of the instances appear to be OK, but many of them
are just missing major parts, even though the family table says they
should be there, and some are empty.

Am I just missing something? Does anyone know how to deal with this?

Ken Sauter
DRS Reconnaissance Surveillance and Target Acquisition
Infrared Technologies Division
PO Box 740188
Dallas, TX 75374
214-860-6826
-

NOTICE: This e-mail transmission (and/or the attachments accompanying
it) may contain confidential or proprietary information belonging to DRS
Technologies or the sender. The information is only for the use of the
intended recipient. If you are not the intended recipient you are hereby
notified that any disclosure, copying, distribution or the taking of any
action in reliance on the contents of this information is strictly
prohibited. Any unauthorized interception of this transmission is
illegal under the law. If you have received this transmission in error,
please promptly notify the sender by reply e-mail, and then destroy all
copies of the transmission.

"This (document/presentation) may contain technical data as defined in
the International Traffic In Arms Regulations (ITAR) 22 CFR 120.10.
Export of this material is restricted by the Arms Export Control Act (22
U.S.C. 2751 et seq.) and may not be exported to foreign persons without
prior written approval from the U.S. Department of State."



This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[wfalco]

One thing to always be wary of when using family tables is the domino
effect. Turning something off must not have children. I am sure you are
aware of that. However, as you build your matrix Pro/E in session can
fool you if not fully regenerated. I will purposely erase all from
session, even restarting Pro/E just to feel like the day after. This is
something I know web folks do. It's easy to miss something. I takes a
great deal of concentration as the table becomes more complex. There is
always a reason why.

On Mon, May 24, 2010 at 8:17 AM, Sauter, Kenneth W (SA-1) wrote:

This is what drives me stark raving nuts with Proe. I have an
assembly family table with 12 different instances of the assembly in it.
You know, the usual stuff: some parts and assemblies suppressed, others
showing, depending on the instance. Everything was fine on Friday.
Today, I have a number of instances that should show certain assemblies
according to the family table, but when I open those instances, lo and
behold, there's nothing there! Either I have 1-3 parts showing, or
nothing at all. Some of the instances appear to be OK, but many of them
are just missing major parts, even though the family table says they
should be there, and some are empty.
Am I just missing something? Does anyone know how to deal with this?
Ken Sauter
DRS Reconnaissance Surveillance and Target Acquisition
Infrared Technologies Division
PO Box 740188
Dallas, TX 75374
214-860-6826
- <">mailto:->
<">mailto:->
NOTICE: This e-mail transmission (and/or the attachments accompanying
it) may contain confidential or proprietary information belonging to DRS
Technologies or the sender. The information is only for the use of the
intended recipient. If you are not the intended recipient you are hereby
notified that any disclosure, copying, distribution or the taking of any
action in reliance on the contents of this information is strictly
prohibited. Any unauthorized interception of this transmission is
illegal under the law. If you have received this transmission in error,
please promptly notify the sender by reply e-mail, and then destroy all
copies of the transmission.
"This (document/presentation) may contain technical data as defined in
the International Traffic In Arms Regulations (ITAR) 22 CFR 120.10.
Export of this material is restricted by the Arms Export Control Act (22
U.S.C. 2751 et seq.) and may not be exported to foreign persons without
prior written approval from the U.S. Department of State."

[kwsauter]

I am certain there is always a reason why. The reason we use this
software is so we don't have to worry about the background housekeeping
that is necessary to keep everything sorted out. It is the software's
job to sort out those things so I can spend my time designing. It's
like having a manual transmission and a manual timing control on your
car. Not only would you have to manually shift gears, but you would
also have to manually adjust the timing as the car speeds up or slows
down to keep the engine running properly. None of us would be willing
to put up with that. why should we have to put up with it in Proe?


Ken Sauter
DRS Reconnaissance Surveillance and Target Acquisition
Infrared Technologies Division
PO Box 740188
Dallas, TX 75374
214-860-6826
- <">mailto:->

[lylebeidler]

The biggest bugaboo with that issue is that it doesn't necessarily warn or
inform you that it's suppressing children. For example, if A is in the
family table but B isn't, and you inadvertently make B a child of A, it will
suppress B when A gets suppressed, you may not ever get any
error/warning/indication that B is now suppressed.



--



Lyle Beidler
MGS Inc
178 Muddy Creek Church Rd
Denver PA 17517
717-336-7528
Fax 717-336-0514
<">mailto:-> -
<">http://www.mgsincorporated.com>

[wfalco]

I agree it's pretty much manual. This may explain why many people don't
like to use them.

On Mon, May 24, 2010 at 8:48 AM, Sauter, Kenneth W (SA-1) wrote:

I am certain there is always a reason why. The reason we use this
software is so we don't have to worry about the background housekeeping
that is necessary to keep everything sorted out. It is the software's
job to sort out those things so I can spend my time designing. It's
like having a manual transmission and a manual timing control on your
car. Not only would you have to manually shift gears, but you would
also have to manually adjust the timing as the car speeds up or slows
down to keep the engine running properly. None of us would be willing
to put up with that. why should we have to put up with it in Proe?

Ken Sauter
DRS Reconnaissance Surveillance and Target Acquisition
Infrared Technologies Division
PO Box 740188
Dallas, TX 75374
214-860-6826
- <">mailto:->
<">mailto:->

[wfalco]

Yes...that would be great.

[wfalco]

I agree it's pretty much manual. This may explain why many people
don't like to use them.

On Mon, May 24, 2010 at 8:48 AM, Sauter, Kenneth W (SA-1) wrote:

I am certain there is always a reason why. The reason we use this
software is so we don't have to worry about the background housekeeping
that is necessary to keep everything sorted out. It is the software's
job to sort out those things so I can spend my time designing. It's
like having a manual transmission and a manual timing control on your
car. Not only would you have to manually shift gears, but you would
also have to manually adjust the timing as the car speeds up or slows
down to keep the engine running properly. None of us would be willing
to put up with that. why should we have to put up with it in Proe?

Ken Sauter
DRS Reconnaissance Surveillance and Target Acquisition
Infrared Technologies Division
PO Box 740188
Dallas, TX 75374
214-860-6826
- <">mailto:->
<">mailto:->

[mainman]

When we use family tables here we tie everything to a general skeleton to keep from having parent-child relationship to individual parts. Takes out some of the issues out of the family table.



Sincerely,

Rick L.
Design Draftsman: Husky Corporation

[ptc-1932745]

From what I remember, the ‘preferred’ method lately has been to use interchange groups vs. family tables.



I can say that the interchange groups are much more robust and flexible, allowing for part or assembly replacements. We have even made ‘temporary’ interchange groups when we want to replace two unlike components in an assembly without hassle.

[kwsauter]

Which raises the question: If the software is parametric (i.e., it
manages relationships between parts, features, dimensions, etc.) and we
have to eliminate relationships to make something work 'properly', does
the software itself work 'properly'? When you have to defeat the
advertised purpose of using the software, what good is the software?


Ken Sauter
DRS Reconnaissance Surveillance and Target Acquisition
Infrared Technologies Division
PO Box 740188
Dallas, TX 75374
214-860-6826
- <">mailto:->

[kwsauter]

I have heard that interchange groups are limited to a very restricted
number of configurations, like 4 or so. Is that true?


Ken Sauter
DRS Reconnaissance Surveillance and Target Acquisition
Infrared Technologies Division
PO Box 740188
Dallas, TX 75374
214-860-6826
- <">mailto:->

[rreifsnyder]

If you're just using the family table to see the components in different positions by showing some and suppressing others, simplified reps are much better at this. Parts can be shown even if what they were assembled to is not. Also, when you open a rep, only those parts in the rep are called into session even if they are unrelated except through the highest level assy. Using family tables for suppressing things still calls all things into session first.

Rob Reifsnyder
Mechanical Design Engineer/ Pro/E Librarian
L
Mission Systems & Sensors (MS2)
497 Electronics Parkway
Liverpool, NY 13088
EP5-Quad2, Cube 281

[dustin]

The problem with using simplified reps in this manner is that the reported mass properties will calculate for all the components in the model (only calculated in the master rep). So your weights, volume, surface area, etc. measurements would be inaccurate. One could also use styles to blank certain parts as well.

My personal recommendation would be to utilize connections in mechanism for this ... the reported properties would be intact, and you could see the full range of motion and look at any point of motion it it's range.

In Reply to Robert Reifsnyder:

If you're just using the family table to see the components in different positions by showing some and suppressing others, simplified reps are much better at this. Parts can be shown even if what they were assembled to is not. Also, when you open a rep, only those parts in the rep are called into session even if they are unrelated except through the highest level assy. Using family tables for suppressing things still calls all things into session first.

Rob Reifsnyder

[jskraba]

This is not completely true. When config.pro option >mass_property_calculate AUTOMATIC< it will calculate mass properties for simplified representation currently active (not just for master). The worst solution is to use styles since you only blank the components while they are still in memory.

Regards,
Jurij Škraba
Research & Developement Department for Hydromechanical Equipment
Litostroj Power | Production of Power Generation and Industrial Equipment |

[dustin]

I would dispute that claim. I have had the option mass_property_calculate set to automatic for years. When in a simplified rep of any kind, it will generate this message upon regeneration: "Assembly mass properties did not change since some components are excluded or substituted."

In Reply to Jurij Skraba:

This is not completely true. When config.pro option >mass_property_calculate AUTOMATIC< it will calculate mass properties for simplified representation currently active (not just for master). The worst solution is to use styles since you only blank the components while they are still in memory.

Regards,
Jurij Škraba