cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Improve management of various configurations (aka: fix ownership of selective instances)

Improve management of various configurations (aka: fix ownership of selective instances)

I am referring to the configuration of an assembly, as in it's topology. I am not referring to the Configurations (the tool often used for exploded views).

I believe we are limited in our ability to vary the configuration of parts between like assemblies. One example would be you've got a product you sell (car, train, robot, whatever), but you sell two configurations of the product. Let's go with a car

  1. 10023, Collection of all car configurations for top level configuration management
    1. 10024, Car with standard tires
      1. 10025, Standard Car Chassis - this is common across all configurations
      2. 10026, base model tires/wheels
      3. 10027, Standard Car Badge
    2. 10028, Car with Premium tires
      1. 10025, Standard Car Chassis - this is common across all configurations
      2. 10029, premium model tires/wheels
      3. 10030, Premium Car Badge

Pretty easy to set up right? 10025 is a shared assy, everything else are their own parts/assys. The problem I have is that in a similar arrangement, the screws that hold the Car Badge on are part of 10025's structure, and the holes that mount the badges are in different locations. Please assume this is a legitimate structure - there is some reason the screws are part of 10025, and not part of the badge kit, etc.

This is where it falls apart for me - I thought it was pretty easy still. Selectively Unshare the fasteners that hold the badge, using 10028 as the context, and move the fasteners to the appropriate position. It all looks great until you go to save 10028 back to ModelManager, and notice that the top level, 10023 is that assy that is flagged as modified, not 10028. That doesn't make any sense because you haven't changed anything in 10023. Presumably you've established 10028 as taking over ownership of the location of the fasteners. This should be fixed.

Things get weirder when you try to set up a sales promotion, where you can buy a premium car and get a skateboard for free. Since your company lives and dies by model based definition, you build a model to reflect this. You load 10023 to show all your available configurations, create a new assy, and create a share of 10028, and add in the skateboard.

  1. 10031, Sales promo assy
    1. 10028, Car with Premium tires
    2. 10032, skateboard.

Looks great until you zoom in on your car and see the screws have reverted back to the standard location - they've lost their premium location. This should be fixed, since now you can't do your rendering for the advertisement. . .

Below is my real-life example of selective instancing not behaving appropriately:

I start with an unmodified assy:

SelectiveInstanceContext1short.jpg

Because the holes in the ConfigKit are in different locations across a variety of robots, I need to show the Gripper Module in a different position. I select one of the sub-assys to be selectively unshared (GripperModule.01), and I select the assembly that, in this instance, I want to own the position of GripperModule.01 (ConfiguredRobot.549idA.950p):

SelectiveInstanceContext2.PNG

Notice that the top level shows the little floppy disk of modification, this should be showing on ConfiguredRobot.549idA.950p, since that's what I selected as the Context.the top level should be unchanged.

SelectiveInstanceContext3short.jpg

I've had conversations where I've been told this is appropriate behavior, but I can't wrap my head around that. If I do the work shown above, then come back the next day and load only 10033332-6 from ModelManager by itself (it is a standalone assy after all), GripperModule.01 will not be in the right place, because ownership of the location of GripperModule.01 has been mistakenly given to the top level.

1 Comment
Community Manager
Status changed to: Archived