Example of Selective Instancing

[PeterKehoe]

This video shows an example of using Selective Instancing.

<script src="https://players.brightcove.net/6058022026001/default_default/index.min.js"></script>

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.

[ptc-1796640]

Very cool – lots of good information there. I learned a few things along the way (most importantly Sel Master 2D).

One thing I had trouble wrapping my head around (and am still not 100% sure it’s fully wrapped) is Context. It would be cool to see what happens if, at the beginning, all your assemblies are saved (no floppy disk), to show what ‘owns’ the selective instance information when you add it. This can be important when you want to move a part/assembly inside the Pick Mechanism, but want their location owned by CC680…

In my example below, the green rings of the the gripper modules are a few layers down in the Core Robot product structure. The Core Robot is the same across all configuration of the various robots. Thanks to Selective Instance, I only have to maintain one model for the Core Robot – if I add or remove parts anywhere in Core Robot, all robots are updated in these cases. To make this work I need to be sure that each ConfiguredRobot* stores the location of its Selective Instanced parts/assemblies.

In the configured robot below, you can see the gripper modules are in new locations defined by the configuration plates. The Selective Instance can own the location of both the major assemblies like the Gripper Modules, but also the individual parts like fasterners and internal hoses.

Here’s the two robots overlaid

[PeterKehoe]

I'm not sure I have a good handle on Context either. All of the examples of selective instancing I have seen or used have been relatively simple and I have not needed to change the Context. I would think that the context would indicate the level at which the selective instance information is saved, and also the level at which it would be shared. I'll need to play with it.

[ptc-1796640]

Here's an example where I'm adding a new iteration of our robot - I need to move the gripper modules to line up with the holes in the config plates. http://screencast.com/t/VzUwwBFRV2i

Notice that the Context is the CoreRobot, but it's the ConfiguredRobot that is modified. This was very confusing to me and lead to arguments with Tech Support about whether or not the feature was defective or not. I now understand that it works as expected, if you have the right expectations. That is, the Context is the assy below the assy that will actually own location of the selective instanced parts. My new argument is that 'Context' should mean 'the owner of the location the parts/assys being selective instanced'.

[ptc-1796640]

Here's an example where I am selecting a part that is not only multiple layers down, but is inside unreserved assys. http://screencast.com/t/OUV4L1mQK4

Because the part's assy is locked, Context is left blank for the user to decide who owns the selective instance. The default Context is the parent of the source. You may want the selective instance owned by some higher assy though.