Assembly inside of an Assembly (No Blue Update Icon)

Michael_Coffee

When you have an assembly composed of just parts, any revisions to those parts will cause the update icon to turn blue, indicating there is a new version of the part available. Pretty straight forward. However, if I have that assembly inside of another assembly, the icon will not turn blue.

Part (V1->V2) -------> Assembly (Blue Icon) -------> Main Assembly (No Blue Icon)

If I version the assembly, the main assembly icon will turn blue, like it's supposed to. However, let's say I didn't know the part was versioned and I am only working in the main assembly. There isn't any indicator to tell me that I need to update anything and I continue to propergate an old version into new assemblies. Take for example an assembly that is composed of 7 levels. I will see new versions from level 6, but not in level 5 or below.

Each part/assembly also exists in their own document (just for clarification). If they all existed in the same document, I'd never have this issue to begin with. I'm hoping maybe I'm just missing something here, because almost all of our assemblies have at least three levels to them. Not being able to tell when lower level parts are updated makes the entire process frustrating, because not being able to see the change kinda defeats the system itself, yes?

If this is a known issue, I haven't found any thread talking about it, but I will very gladly make an improvement request for it Maybe also I'm just not seeing something I need to do in order to make it show up.

john_mcclary

There wouldn't be anything to sut for you to make it show up. One nice thing about Onshape is there aren't many settings. So the user experience is pretty much the same from one user to the next. 

This sounds more like a bug than an improvement. Have you submitted a ticket through the "?" Icon in your document. That's a good way to get direct support for these ui issues

Michael_Coffee

@john_mcclary

Not yet, but I'm about to. I wanted to see from others if this was a normal thing with Onshape, but it sounds like I'm not the only one thinking that it is a bug. Thank you for commenting

owen_sparks

I don't think it's perceived by onshape as a bug, it's more of a limitation of the current implementation...  Either way if an update notification can only be seen one assembly deep it very much limits its usefulness. 

This rather knocked the wind out of my sails a while back when thinking I'd do a mega assembly of our whole factory and would be able to make changes to tiny sub assemblies and just push them into a multi layer assembly :-(

Owen S.

Michael_Coffee

@owen_sparks

Exactly! =( We have large assemblies with who knows how many subs and the limitation of only seeing the ones directly below really bummed me. However, I did put in a ticket for the issue, linking a model for them to see what is happening, and they said it's been an ongoing improvement they're working on. I got the impression it's been something in the works for a little while, so we will see it down the line somewhere

billy2

I think:

Documents referencing other documents invoke versioning.

At no other times does this happen.

Changing parts will not kick off a blue update icon when everything is in the same document.

Creating a new version in a document causes blue icons in other referenced documents. Changing parts/assemblies will not cause blue icons, you have to create a version 1st. I like this. Versioning is like saying I'm done with this.

In multi-level assemblies, versioning a bottom level document will require you to version each level up to the top. I think this is what you want. I don't think this should ever be automatic.

Moving an assembly out of a document will invoke versioning, put'n it back into the document and versioning stops.

Keeping drawings in another documents invokes versioning to what ever you're detailing. This is what I do. I never have drawings in the same document with the parts/assemblies.

Invoking versions is new and works at the document level. That's why onshape has documents.

billy2

It's kinda of a pain dealing with the versions when designing a new product. I would recommend keeping everything inside one document until the design matures. I'm using indentured folders to manage the assy levels in a document.

Once sub-assy's stabilize, move them to their own documents. This is when versioning begins. 3 levels deep when designing something is great, good project structure, just keep it in a document.

I have no idea what you're doing, but I have an opinion. In the design phase, try building it in a document and then pruning that document before manufacturing.

All projects go from design to manufacturing and one style is not good for the other. In the design phase keep things in a document (there's no performance issues that I know of). Then when it's released and heading to manufacturing, change the project structure by moving things to their own documents. Manufacturing will love the control.

I'm not sure having lower level assemblies driving automatic versioning to the top is a good thing. Automatic software is dangerous and I think each sub-assembly needs human consideration. Not every change to the bottom should drive to the top. I think there's a backwards compatibility consideration along each level that needs to be asked.

Having my drawings in another document, from the start, is fine because the last thing I do is the drawing. My layout is stable. I'll never do a drawing while designing. I don't need/want that flexibility. Keeping my drawings in another document make sense for me.

There's a lot to document control and I think there's going to be a solution that we'll all learn.

billy2

When moving an assembly from one document to another, I'd like to choose which dependency go with it. I'm thinking all should go, but I'm not comfortable with this either.

I thought a while back, I had this choice and now I don't . 

Moving drawings  will pull the dependencies, moving assys doesn't move dependencies. This should be consistent. Right now I think it's backwards. Next week I'll want the other. I like to change my mind. Just let me pick what goes and what doesn't.

Currently I move the assy and then I move the dependencies. Not a big deal. But it's 2 steps.

Currently I start the drawing in it's own document so there's no moving required. This is a Philipism by the way.

john_mcclary

There is a performance hit for opening a doc with many tabs. Or at least there used to be.

At one point Onshape devs recomended about 15-20 tabs as a break off point.

the reason is each tab needs to spin up another instace of a server.  So it can become resource hungry. And on a shared scaleable cloud, we should at least be aware we are burning up unecessary resources. Kind of like not running the water while you brush your teeth. You will likely never run out, but if everyone did it, the city would need another water tower paid by your taxes. Or in onshape's case more servers, which could trickle down into higher subscriptions eventually. 

billy2

I guess that means I'll have to get things done sooner so I can move'm out into their own document.

My boss will like that.

Michael_Coffee

@billy2

I might have conveyed myself incorrectly. When I'm talking about the blue icon, I just want only the notification to be propagated up. It is already automatic for letting us know, but it needs to be done higher than just the immediate assembly it is in. I do not want an automatic versioning. That would be a nightmare >.>

On principle, if a part is revised, it should be compatible with all previous releases that use it. In that context, any revision must propagate up the assembly chain. Now, that doesn't mean every assembly that uses the part should be revised up. In some structures, this isn't a problem. In others, such as the environment I work in, one part might be used in many and revising up will quickly cascade into a never ending series of revisions where the only reason is "Revised #". With that in mind, I do not equate versions and revisions to be the same thing. Versions are captured states of data in Onshape. Adding a mate connector, for example, or adding vendor information to the model, does not constitute a revision. It does require a version to capture the data for later models. Versions, in contast to revisions, are exceedingly quicker to look over and verify there isn't any change to the model's fit, form, and function. Revisions require paperwork. We don't want more paperwork.

We need the notification because, while having many models in the same document does get around the versioning aspect of Onshape, our parts already exist. We are past the initial design process. However, let's say we need to add a hole to a plate. If we add it, it will not propagate up where it needs to be shown. It will only ever use an old revision and that is not good for later design work that requires that part.

billy2

@Michael_Coffee thanks for the explanation.

In my world every thing goes to the top. We talk about part re-use but no one does it. I know when a lower level part changes and I don't share your problem.

Parts used everywhere on differing products is a totally different problem. Opening a top on a wide range of products and knowing if it's correct would be difficult. Did something change below? I understand your struggles.

In this case, not only would I want to know that something below is old, but I'd want to know where it was. And of course, I'd want a one button update. Seems like we need a notify to top option when we change a part. Maybe in an assembly, there's an option to see all the way to bottom looking for changes. I could see this being useful.

When you release a part, do you run a where used? Seems like you should understand the impact. But to that end, who cares, I wouldn't fix them all. I'd wait and do them when I had to. To your point, you can't remember all this.



Documentation control is difficult and getting it right is hard especially since you & I want differing things.

billy2

@john_mcclary well I blew past those numbers a long time ago. I'm at 500 tabs in my top and this is a small assembly. Next week I'll start a big one.

I guess I should say to all that I'm sorry for causing the leak. Now I'm feeling badly about sinking the ship...

john_mcclary

Lols

MBartlett21

billy2 said:

Parts used everywhere on differing products is a totally different problem. Opening a top on a wide range of products and knowing if it's correct would be difficult. Did something change below? I understand your struggles.

In this case, not only would I want to know that something below is old, but I'd want to know where it was. And of course, I'd want a one button update. Seems like we need a notify to top option when we change a part. Maybe in an assembly, there's an option to see all the way to bottom looking for changes. I could see this being useful.

@billy2
@john_mcclary
@Michael_Coffee

This was released two releases ago, but was disabled due to performance issues:
https://forum.onshape.com/discussion/11865/improvements-to-onshape-june-18th-2019/p1

Michael_Coffee

@billy2

Unfortunately we don't have a "where-used" function inside of Onshape.

@MBartlett21

I can see why there were performance issues trying to impliment an "automatic" versioning, which I assume is essentially what is happening. I would have loved if the notification part was kept, as well as the "pin reference" in the case of dealing with parts that are obsolute but still needed for servicing, so maybe they could reimpliment that part in a later release. Since the work had been done before previously, it should be easier to use certain parts of the code rather than write a different script. Of course, I'm being optimistic. I have absolutely no clue how complicated the code could be >.>

In retrospect, I would prefer the notify and force the user to decide to travel down and to the parts themselves. Yes, it's more work, technically, but ultimately you're going to either verify previous changes as needed for your design, or find out that a revision that was made cannot actually be done because of XYZ. I think of it as a checks and balances situation. Not everyone has a where-used function (ie us), so this check would at least make sure we can catch anything we missed.