Assembly Configurations - ability to set Global Variables

dapug

I'm so bummed... I cannot choose a GLOBAL variable (variable studio) as an assembly feature to modify a value for assembly.  Why?   WHY?????  Please tell me you can, and that I am just missing something obvious.

Use Case:
Making global variables configurable and thereby apply to ALL parts (that happen to share than variable) in the assembly in one swoop... yeah.  WAY better than having to set a configuration on parts (in part studio), and then assembly config has to go refer to ALL the parts that need some sort of value change that would otherwise be very simply set from a single variable that those parts all shared.

Further info:
It's super annoying when you have a LOT of parts that happen to share a variable (the whole point of Variable Studio, right?), but then ALL of those parts would need that value not only set as configurable in the part studio, but ALSO would need to add each and every one of those as an "assembly feature" to then point to and modify them all in sync in Assembly Config.  Lame.  This gets out of whack and invalid REAL fast when you set, for example, a length on one part, but all the other parts (that must MATCH that length, hence the variable) do not actually sync up and force match in assembly. Now you have invalid dimensions in assembly! Grrr. No... they must be added, each and every one, as an assembly feature in your assembly input.  Ugh.

_anton

Can you share a document? Variables imported from variable studios can be used in configuration tables. They can also be used in assembly features.

dapug

In any document that has parts and a Variable Studio with values. Add a part to assembly. In Assembly, Configuration Panel, add a List.  Then click "Configure Assembly Features", and you see the message "Select instances or mates to configure with List input..."

It doesn't say "select instances, mates, or global variables".  And on the left pane under Instances, you can click around everywhere in there... no ability to set variables. I can set "unsuppressed" on a part or mate, but still no variables.

_anton

If the assembly's config affects the parts inserted into the assembly, then that information must be passed along to the parts via their part studio's configuration. The assembly can configure the part studio configuration at which parts are inserted.

Our architecture doesn't allow information to flow the way you suggest. Consider: what if you configured the same global variable from two different assemblies? Working with configs can be cumbersome, I know, but, even in an ideal world, it still wouldn't make sense to have one tab's config affect global variables.

Edit: I should add that I'd love some workflow improvements in config land, like what S1mon proposes (and especially configurable variable studios), but we'll get to it when we get to it. :P

S1mon

It would be nice if there was a good way to have a configuration input at an assembly level trickle down to all the parts which understand that type of input going down the assembly/sub-assembly/part tree. Recently we spent a lot of time configuring layers of assemblies and parts to pick up top level configs in order to manage color ways for our scooter. I realize there are many complexities of this, but it would be nice if there was an easier way to manage this.

dapug

_anton said:

Our architecture doesn't allow information to flow the way you suggest. Consider: what if you configured the same global variable from two different assemblies? 

@_anton actually, I'm not proposing that Assembly Config would modify the global variable.  What I am proposing is that it control/modify all the parts in the assembly that are built using a global variable, but ONLY apply it within the scope of that specific assembly.

I believe this is what S1mon was saying.  But just to be clear, here is that concept spelled out...

Say you have a global variable "TotalWidth", and you have 30 parts that all set their width to it.  Then, say you add these 30 parts into an Assembly, and in the Assembly Config, you create a List with "Normal" and "Wide", with different values.  Now, RATHER than going into the config of 30 parts, you simply add the global var TotalWidth as the Assembly Feature.  And poof!  All 30 parts respond to the simple config setting.

This way, all the parts that are set by that TotalWidth variable now respect the values, without me having to go into all 30 parts, and without having to set up config in the part studio!  BUT...  this does not actually change the global var itself, it only APPLIES it to THIS one assembly.  Not affecting other assemblies using those parts, nor even affecting the drawings of the parts in part studio.

Is there a way to move this post to Improvement Requests?

eric_pesty

I think a less "convoluted" way of achieving this would be to make the variable studio configurable and then all you would have to do is call the different configurations of the variable studio from the assembly. 
This would be more similar to the current workflows, with the key difference that changing the configuration a variable studio affects the whole document (or at least every tab that uses a one these values).

_anton

To basically parrot the preceding, there can be two improvements that would greatly ease workflows: 1. configurable Variable Studios and 2. some mechanism to trickle configs through different Part Studio/Assembly references. This will all take work; submit improvement requests so we can prioritize it.

steven_van_luchene848

any news on this? If I understand correctly, I have a challenge similar to this one. If something is configurable 5 subassemblies down, all assemblies above it need to be configured as well..(in effect I only need this assemblies to restructure the BOM, the actual configuration is of little importance. you don't seem to be able to acces a configuration (to configurate) that is more than 1 level down of the assembly you are working in. being able to control parameters in a variable studio from any of the assembly configurations would solve this. 
Which is a pain with highly hierarchical models.