Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Assembly Configuration Not Working As Expected
AsherAtSignalDesign
Member Posts: 32 ✭
I have a Part Studio with a configuration list that determines the output part. I am inserting this Part Studio into a configured Assembly with a corresponding configuration list. I am running into a couple of major annoyances that culminate in a problem:
- Configurations have to be manually added and can't simply be inherited, which is crazy. They should auto-accumulate as they are included in the assembly, then have the option to combine or hide them!
- There does not seem to be any way to configure list-based part configurations at the point of insert. The parts have to be re-configured, at which point the configuration can be assigned. This is a very strange workflow and seems to lead to the problem.
- Even though the Parts Studio puts out exactly one part corresponding to each list configuration, the Assembly doesn't seem to know how to handle this.
The result is that the first part I insert works, but when the configuration is changed for the list item that changes the resulting part from the Parts Studio, it simply breaks instead of replacing the part.
How do I make this work? This seems like the most basic of use-cases for configurations. I'm trying to set things up so that I can organize work from the "part in context" option. Is that not going to cooperate with major configuration-based changes to the parts?
Comments
The issue is that even though in your specific case each configuration only generates a single part, this is not a "requirement" for configurations so Onshape doesn't assume it's the "same" part. Basically your use case is a very narrow use case for a configuration system that is much broader than that and I think that's why it's not working the way you expect.
If you use a completely different sketch to extrude a part depending on the configuration (even from the same extrude feature), Onshape will interpret it as a different part, which is a bit unfortunate… The simplest way I can think off solving this would be to create a composite part (using a query variable for "all solid bodies" as the input). Then inserting that in your assembly should automatically pick up whichever solid body your configuration produces. I would also make sure you add an explicit mate connector to your part to use for mating...
As far as bringing over the configuration inputs, you can use the "copy input" from the part studio and paste it into your assembly to create an identical list, however it is just a shortcut and won't maintain associativity (i.e. if you add any new rows in your part studio you would have to add them to your assembly.)
In this specific case it would be helpful to have the assembly "inherit" the configurations but what if you are inserting many different parts that each have their own sets of configuration inputs? Automatically inheriting these would quickly create a real mess…
It should be possible to right-click and configure any input inside the insert dialogue, although I just tried it and it seems to not be working… Maybe there's a bug in there…
lastly, I am not sure what you are planning on doing with "in context" but I suspect you might be better served by using the "derive" workflow instead as contexts are not well suited to working with multiple configurations…
I tried to create a composite part using a configuration for which part is included. That does prevent errors when the assembly configuration list value changes, but it does not change the corresponding part. This seems to be a function of how you cannot configure the list directly and can only do so after the fact.
If I add the Part Studio composite part and then reconfigure the inserted part so that it is configured with the Assembly list configuration it shows me the originally inserted part and composite part but doesn't allow any selection regarding the composite part. If I then change the list configuration, the part does not change.
Is there a different way that you are suggesting creating the composite part? I understand how to do so by query via Featurescript, but am not familiar with doing so otherwise.
I've been using the derive workflow, but that ends up with all sorts of cross-contamination in the Parts Studios. I can combine when needed, but not needing it for everything is already making a big difference.
I don't understand why this isn't the core purpose of the configuration system. Maybe you can provide some insight as to how it is instead intended to be used?
At present, it seems to me like it is currently a broken partial implementation that is—as far as I can tell—the symptom of a lead engineer's irrational resistance to object oriented programming.
I'm not sure what part isn't working for you. Currently you do have to manually map the assembly configurations to the part studio configuration but once you this the composite part switches as expected. This could be a good application for an AI helper to automatically generate the mappings for cases like this.
https://cad.onshape.com/documents/a43df0add559f12915a21c5f/w/a5f403f65059413c62e427ba/e/a23ce41c252d209bd6c23f48?configuration=List_Q9NZt9LBaXwgKy%3DTriangle&renderMode=0&tangentEdgeStyle=1&rightPanel=configPanel&uiState=692f21bf2a1b5f781c2bc613
If you look at the public model below, it does show what assembly configurations can do (I remembered seeing this one, there are probably better examples). While it would be useful for your specific example, you can imagine that building this assembly would have been a nightmare if Onshape automatically added configuration inputs when inserting each configured sub-component.
https://cad.onshape.com/documents/4833676df7d2a808ac4b52b7/w/1779c4496f69618947b539b5/e/75f2654cbbb785c3812333d2
While it's definitely not perfect, I'm not sure where the "irrational resistance to object oriented programming" comment is coming from! I personally think the Onshape configuration system blows away any other "out of the box" functionality from other CAD packages…
The correct behavior of flowing configurations through a document is non-obvious. We've given this a great deal of thought and are planning improvements in this vein. In Onshape, particularly complex functionality is often released on an MVP basis; that way, you get a basically functional product up front and can expect improvements down the line.
@eric_pesty Thanks for the video. That clarified things. I was missing the query variable - I was not aware of that feature from the GUI.
Doing the same thing with a composite part constructed by using configuration-based selection of parts did not work. Not sure if there is a concrete reason for this or if it is a strange quirk.
As far as flow-through configurations, I believe the focus should be on how to create a system to combine or make private particular configurations. Each part that contributes a configuration would initially become part of a hierarchy of configurations. It could be left this way if it makes sense, or more likely it would be reorganized by combining multiple configurations or deciding that certain configurations are private (and would stop cascading).
Alternatively, I would suggest the same thing but with each contributing part having an option to opt-in to configuration cascades. I would be OK with this, but it seems to me that the default should be to assume that cascading of public configurations (a new concept that would be added) is desirable.
As far as OO — all of this would be obvious if the part were an object that brought its context (another object) along as one of its attributes. Configurations would be proper to their object and so the task would be how to properly represent their cascading, not whether they would cascade.
Similarly, things like inquiring after variable values from a particular context would be straightforward as they would be portable in the OO context. So, for example, an assembly would be able to rely on a configuration variable.
The shortcoming of the non-OO approach are particularly clear when using Featurescript, where even an object that was just created has to be found via a query in order to refer to it rather than simply being directly available as the corresponding code unit where it was created.
There is no doubt that the OnShape configuration system is better than other CAD systems. That's a starting point, at least.