It was early in the week. Maybe I wasn't quite back from the weekend, who knows. I replaced some components in an assembly, using layout. This often works flawlessly. This time, as the parts I replaced had patterned base features used for later Reference patterns, every one of "referenced" components failed/froze. Any best practices on how to avoid this? Mass 'Reroute fetures'? This was a lost day of tedium; help would be much appreciated.
David Janes (newly newbied, utterly humbled)
Hi David,
another ProE annoyance indeed ... and it is still implemented 8-(
The long way around this is: first delete the original pattern, replace all components using layout, then recreate patterns and pick all referring components to pattern them again.
Since it is possible to redefine the pattern options of the "master" feature to table driven one can save complex patterns :-) and it is good practice to have the related components arranged into a single subassembly (e. g. bolt, nut & washer) to ease pain.
Why the replacement ob subassemblies can´t work on the whole pattern is beyond me ... whenever I know beforehand that a "replace" task will become necessary I make both feature (e. g. hole) and subassembly (e. g. bolt & nut) after a table driven "master" (e. g. axis, point), and make multiple use of the pattern table.
Walther
Janes wrote:
another ProE annoyance indeed ... and it is still implemented 8-(
The long way around this is: first delete the original pattern, replace all components using layout, then recreate patterns and pick all referring components to pattern them again.
I know some people like pattern tables, I try to respect that. But I hate them. Here's why a.. You know how, with instance patterns, you can pick an instance in the model tree and the part lights up? Not so with table patterns; these are as dumb as the Half-Amateur/TABLE they are built on (don't get me started on this decrepit, bullshit functionality, we'd be all day). b.. No more can you change a pattern increment value and have the instances update automatically; you have to go into each one and add values by hand (sit there with a calculator and add 2x, 3x, 4x, etc.) c.. You have no idea where the zero/zero point of the pattern is, so you start off, with any mods to the pattern, with some detective work (not fun, not productive), just to establish the baseline from which you are modifying (more stupid shit) d.. And Pro/TABLE is just crap, useless garbage, junk to work with; a headache, a grotesque boil; the "Elephant Man" of Pro/e
Since it is possible to redefine the pattern options of the "master" feature to table driven one can save complex patterns :-) and it is good practice to have the related components arranged into a single subassembly (e. g. bolt, nut & washer) to ease pain.
I greatly agree with creating groups of components and patterning the group; group fails, all components fail; group succeeds, all components succeed~not doing the same thing once for the washer, again for the lock, again for the screw.
Why the replacement ob subassemblies can´t work on the whole pattern is beyond me ... whenever I know beforehand that a "replace" task will become necessary I make both feature (e. g. hole) and subassembly (e. g. bolt & nut) after a table driven "master" (e. g. axis, point), and make multiple use of the pattern table.
Here's what I thought of doing, haven't tried it yet. Hide the old component, assemble new without ref to old; take pattern (original comp?) and reroute to new comp refs; delete old comp. Should be clean, maybe a little more work than Replace but, in the long run, less trouble.
Some stuff learned along the way in this somewhat useful excercise in humiliation: a.. Comps in patterns and groups appear, in the model tree status column, to be regenerated, but the features/components WITHIN may all be frozen b.. Beside Modelcheck>Interactive, the most useful tool for checking for "Frozen" and other errant conditions, is the Binoculars (^F), Search for "component", Status, "Frozen" (or "Suppressed", etc), highlight, move to active list, Tree expands/highlights to reveal culprits; RMB actions possible on same c.. No ref pattern works correctly unless you reference the FIRST instance of the original, base pattern d.. You can, however, redefine a second, third, etc. instance independently by picking it and doing 'Ed Def'; often, rest of patterned comps regen correctly e.. Groups stand in the way of redefining member placement, so 'Ungroup' is necessary f.. Start at top of tree; often, when you fix early dependencies, the later dependencies get fixed successively, consequentially, automatically g.. The pattern friendliest, most bullet proof way of creating new parts that Replace smoothly is building them as instances of a family of parts David Janes
On Oct 11, 7:04=A0am, "Janes" wrote: ... "Here's what I thought of doing, haven't tried it yet. Hide the old component, assemble new without ref to old; take pattern (original comp?) and reroute to new comp refs; delete old comp. Should be clean, maybe a little more work than Replace but, in the long run, less trouble."
I have done exactly that, both where patterns were involved and where they weren't; in cases where "Replace" would not be "adept" enough. It works like a charm.
What version are you working with? WF4.0 has an awesome feature for this. It allows you to change the references (parent and child) of the components when you replace by unrelated component.
What version are you working with? WF4.0 has an awesome feature for this. It allows you to change the references (parent and child) of the components when you replace by unrelated component. At work I'm on WF2 & WF4, at home, WF3. Is this new feature documented somewhere? Sounds interesting. Have you used it?
David Janes
On Oct 11, 7:04 am, "Janes" wrote: ... "Here's what I thought of doing, haven't tried it yet. Hide the old component, assemble new without ref to old; take pattern (original comp?) and reroute to new comp refs; delete old comp. Should be clean, maybe a little more work than Replace but, in the long run, less trouble."
I have done exactly that, both where patterns were involved and where they weren't; in cases where "Replace" would not be "adept" enough. It works like a charm. Oh, great, good to hear! Now, all I have to do is be sharp enough on a Monday morning to remember to try it? Did you find the components with the Binoculars and build a query? Would be really cute if you could pick components of a certain name and mated to a certain surface. But, I guess if they're reference patterned, it'd just be all the components (groups) in that pattern.
David Janes
Replace a component, set the type to Unrelated, and there is button in the lower-left corner of the Replace dialog box (Map refs?) that allows you to view all downstream references to the component being replaced as well as the replacing component.
In this box you pick the analogous reference on the new part for each reference on the old. It will walk you through it, or you can work asynchronously from the list of references.
I've used it with very good success.
That said, ref patterns have a bad habit of failing sometimes. It happens just enough to bother me but never costs me enough time to log tickets and try to attack it by SPR. Oh well.
Dave
On Oct 11, 7:04 am, "Janes" wrote: ... "Here's what I thought of doing, haven't tried it yet. Hide the old component, assemble new without ref to old; take pattern (original comp?) and reroute to new comp refs; delete old comp. Should be clean, maybe a little more work than Replace but, in the long run, less trouble."
I have done exactly that, both where patterns were involved and where they weren't; in cases where "Replace" would not be "adept" enough. It works like a charm. Oh, great, good to hear! Now, all I have to do is be sharp enough on a Monday morning to remember to try it? Did you find the components with the Binoculars and build a query? Would be really cute if you could pick components of a certain name and mated to a certain surface. But, I guess if they're reference patterned, it'd just be all the components (groups) in that pattern.
David Janes And, with foresight, here's a way I learned today, using "Duplicate Objects" in Intralink. Assembly relations are preserved, new configurations built with new components, all previous relations captured in metadata, passed to Pro/e. And any drawings associated to the components get duplicated with new names as well. And, yeah, they're fully dimensioned, as before.
Check out an assembly/drawing, in workspace with the Select drawing box checked (be sure to hit Update button), select all that need to change/duplicate and do "Duplicate Objects". In relationships, pick None, hightlight and clone. You've got an entirely new assembly, with new parts/components, assembled correctly, each with drawings named for new components, for almost zero cost to consumer.
Yes, this seems like a lot more "fire power" than is needed to "replace" components. But, consider that, when you start replacing components, you really ought to be replacing configurations. Then, what you need is a way to track subtle variations in configuration, not the mechanics of producing them. Intralink can easily handle that. (I hear the disturbing news that you lose both abilities with PDMLink! Confirm, deny!?!)
David Janes
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.