"Freeze" an object placed in Assembly, similar to suppressing a part derivation?

[DonStauffer99]

If I derive one part from another, I can suppress the derivation, and no changes to the base part will propagate to the derived part until and unless I un-suppress the derivation. I find this useful, especially when I do it using the API.

In assemblies, I haven't seen a similar capability. I can suppress a part's placement in the assembly, but that makes it disappear. I can make it invisible, but I don't want it to go away; I just want it to stay the same no matter what happens in the part, until I want it to change.

So far the only way I have thought of would involve deriving a part from the assembly. Then I could control that derivation. I can do that if I have to, but it seems inelegant and harder to manage, and adds another file.

So I'm looking for a capability to freeze an object placed in an assembly so it doesn't update, as happens with suppressing a part derivation.

Any ideas are appreciated.

[WCrihfield]

This seems like a pretty odd request, because the only geometry in an assembly, other than the work features or sketches created directly within it, is the geometry of inserted component occurrences.  The geometry of those component occurrences is created as 'proxy' (copied, not original) geometry, within the assembly, so it must accurately represent the geometry from the model file that the component occurrence references.  So, one way or another, your model within the referenced model file, must look the way you want it to look within the assembly.  We can use 'representations' to help with that.  There are 3 types of representations, ModelStates, view representations, and positional representations.  ModelStates primarily record component and feature suppression statuses, but also record parameter values, iProperty values, and other similar changes made while they are active.  View representations record appearance & color changes, as well as visibility status changes applied while they are active.  So, if you created a special ModelState, and a special view representation within the source model file, activate them, then set things up the way you want them to look in the assembly, then activate a different ModelState and view representation within the source model, in which all other changes after that point are made.  Then when you place instances of that source model into an assembly, set those occurrences to that special ModelState & view representation.  Then, when you want those occurrences to show more accurately, set them to a different ModelState & view representation.  That seems like the normal way to achieve something like that.  There is also the 'substitution' process, but I think that would involve creating an alternate model file, which you mentioned not wanting to do.

[DonStauffer99]

It's not going to work if I have to do stuff in the source part. The whole purpose is to make it so the source part can change parametrically for other assemblies, and only change in any assembly it's used in if that assembly changes its parameters, and then it's only needed long enough to update the assembly.

I had a feeling this wouldn't be possible so I moved forward by deriving a part from the assembly. Then I can just suppress the derivation in the part. It does the job at the expense of a little additional complexity and an additional part.

I'm having an interesting problem now with the fact that I've put some parts into a sort of diamond hierarchy. I have a base part with a couple sketch blocks, two parts derived from that, and an assembly that uses those 2 parts. There's only one parameter in the assembly which goes to both of its component parts. I have everything else propagating just fine, but that one doesn't make it into the base part (sketch blocks).

I'm guessing the cascade of parameter changes confuses it when 2 derived parts try to change the base part at almost the same time (even though they're changing it to the same value). I really need one to completely finish before the other runs at all and begins transferring parameter values. So I need my external rule (that all these parameter rules call to do the actual work) to be essentially non-reentrant. One instance of it must finish before another runs. I'm thinking of a shared boolean variable maybe, and a loop to wait for the variable to permit entry. Except that always has a problem in that the first thing it will do once it's allowed in is set the flag to keep other instances from moving forward, but in between it's possible another instance gets in. A race condition. I hate asynchronous event handling because of stuff like this.

[DonStauffer99]

Maybe the best way would be to have a 3rd rule in the assembly just for the parameter which is passed to both legs of the diamond hierarchy. Then it can do the change to each leg in turn, waiting for one to finish before the other starts. I think that will work.

The whole thing is to make it all work top down, so each base part acts like a subroutine called with parameters. The link between parts is only unsuppressed long enough to change parameters in the base and update the derived. Then it's resuppressed. So I get a part controllable by parameters in the derived part. Each part in the hierarchy can add pieces, and other constructs later can use the part(s) with their own parameters, and nobody interferes with anybody else. I've got it working except for this race issue. I think I have a solution I'll try tomorrow.

[WCrihfield]

Hi @DonStauffer99.  I have been away on vacation since my last reply here on the first day of July, and just got back to work this morning.  While going through tons of emails and notifications, I came across your replies on this discussion, and on another discussion about iPart member vs factory cell values.

As for this discussion, based on what you said in your previous posts, and the direction you are going, it sounds like you may already have a better understanding about what is involved/required than I do at this point, so I may not be of much further help.

Although I do use 'derive' functionality on a somewhat regular basis, I think I mostly use it for different purposes, and usually manage those associations manually, instead of by code.  I usually just leave the 'Link' either suppressed or broken, and only un-suppress that link momentarily on rare occasions to replace the source model file, because those models are usually just for visual, fit guidance/checking, or BOM related purposes.  Some of our largest or highest level assemblies include representations of complex purchased products that would normally be an assembly, with lots of parts &/or sub assemblies involved.  Some of the components within these purchased products remain relatively 'static', others change in size &/or position, and some are 'optional'.  So, instead of requesting a CAD model of every size variation or option difference from the vendor for including in our own assemblies, we request one or two CAD models with all relevant options included, then create a template part to represent their whole product in our assemblies, because parts have more modeling capabilities than assemblies.  The template part will include derived parts from the vendor's assembly that never change size, but may change position, then also include sketch blocks of all the 'profiles' of parts that change in size.  Those profiles are extruded to extents controlled by named parameters, rules, and a form, which also control the positions of the derived parts.  Then if we need to represent a different size or option in one of our assemblies, we can quickly generate our own from a template.

I do not really use much 'skeletal' assembly modeling techniques or include derived components in assemblies for the purpose of directly changing their parameter values from a parent level assembly by code.

[DonStauffer99]

I went with using ordinary parts instead of iParts. The key is to set each of the rules to "Fire Dependent Rules Immediately", which also will pause the rule when it changes a parameter that triggers a dependent rule, until the dependent rule finishes. That one took me a long time to realize.

Essentially, the base part works like a "subroutine" in code. In a subroutine, I might pass Length, Width and Height and expect the subroutine to do its job, using the 3 values I pass it to customize that job. If I want a different version of what the subroutine does, I pass it different values. Here, I set up a base part controlled by parameters, which are represented in the analogy by the values you can pass to the subroutine (normally called the subroutine's "formal parameters", but I didn't want to get ambiguous with Inventor "parameters).

Then I suppress the link, so when one user sets those parameters and updates, it doesn't change every part that ever used it to parameters that have nothing to do with them. So my code has to unsuppress the link, change the base part parameters, update, and resuppress the link. But if the base part is part of a hierarchy with similar usage, I need to do the update recursively. For ease of use I put all the code into an external rule and call that from each regular rule in each part, passing it information on the base part parameters and values to set.

If I later want to change some "invariant" of the base part, the next time the update process runs, the changes will propagate to the derived class. That could be done by changing a parameter arbitrarily, or just running a parameter change rule manually. This would have to be done by each "user" part, which is a small hassle but it won't happen all that much.

I have this basically working but I'm now working out the bugs.