Model broken, server in invalid state

tony_459

I left my model earlier today in a fine state only to return to it now completely broken.

The main assembly is bleeding red, and the subassemblies are too.

I see in the feature history that tech support did a number of rollbacks, no doubt to help, and I figured I'd just revert to what I know was my last known good version.

No luck. I tried reverting to a still earlier version, but same problem. Lots and lots of red.

There are red mates and there are red parts, and if I hover over the red parts I get the error message that the server is in an invalid state.

Twice before I've returned to models I knew I'd left in good state only to find them mysteriously broken---in one case many weeks after I'd last visited the model. One of those models, my hardest and longest to date, wound up in the trash bin.

Is Onshape aware of the issue? Is something being done to prevent models from breaking like this? You can't work on a broken model---it's gridlock, a complete road block---and you can't stop wondering if and when and how you'll get your model back, emphasis on if.

john_mcclary

I have had that happen a couple of times myself. Usually if you contact support and share your document with them, they can help.

Jason_S

@tony_soares459 ,

I have fixed this and verified that all assemblies open as expected.

ilya_baran

@tony_soares459
I took a look at the document and logs and saw a couple of things:
1. A number of events over the last week that should have manifested as support codes.  Did you see support codes over the last few days?
2. These events were caused by resource limitations caused, I believe, by a modeling anti-pattern common in your document: deriving from the same (giant) part studio using multiple derive features, rather than deriving multiple parts using one feature.  Make that change throughout your part studios and I expect you'll see much better performance and fewer issues.

TL;DR: No more than one derive feature per base part studio.

@john_mcclary
When did you have this happen?  Could you please dm me with a zendesk number when you had a "document isn't what it used to be" issue?

john_mcclary

You all fixed it every time already

tony_459

Thank you all for responding---and thank you, Jason, for resolving the server error.

The machine is large and complex, and that means the model will be large and complex. I wish it didn't have to be!

The part studios grow large because every part depends on every other, or close to. I would have hundreds of small part studios if I created one per part or even one per ten parts. As is, I have tens of part studios. I think Onshape has a blog highlighting the ability to model multiple parts in a single studio as a strength?

Well, I often have to update the versions of some but not all derived parts. This is very important to me. If I update the versions of certain derived parts, the model breaks: a simple change in a dimension or constraint can cause an Extrude or Split or Delete Part to go wrong, meaning hundreds of broken features downstream and a week lost over what at start was a simple change in a dimension or constraint. 

Onshape is very picky on this matter. I could extend an Extrude by a fraction of an inch only to discover that part IDs following a split downstream have changed, causing a Delete feature downstream of the split to remove the wrong part, causing tens of sketches and extrudes and sweeps dependent on the now missing part to break, causing a week to go by just to get back to an unbroken part studio.

And yet, these are things I need to do. 

So... I avoid the issue by using multiple Derived features and updating only those that I absolutely must---and only if I absolutely must, as every update comes with the risk that things below the Derived feature will break. And I insert my Derived parts as far downstream in the feature history as possible, so that I don't inadvertently use them as references early on, and so that if I update them, I don't have to wait for the entire feature stack to regenerate  

TL;DR: I need multiple Derived features per part studio so that many things don't break when I update the Derived version.

Jake_Rosenfeld

@tony_soares459

It sort of sounds like establishing all the positioning in a top-level assembly and then using in-context modeling may be a better approach than deriving at different versions into your part studio. Then your top level assembly could contain the versions you are currently comfortable using, and you can update the context as appropriate when you want to edit specific parts.

Just my take on it though, maybe are things that block this approach for you.

tony_459

Thanks, Jake.

Thing is, I need parts from quite a few different subassemblies for reference. The only way to get them all with in-context modeling is to make the very large main assembly my context. That is a lot of geometry, far far more than the handful of parts I would otherwise have derived.

Wouldn't this slow down rather than speed up things? My experience has been just that---that even a simple operation like applying a parallel mate between lines in a sketch is far slower when done in the context of the main assembly. Maybe this shouldn't be the case?

Jake_Rosenfeld

@tony_soares459

When doing in-context, we only actually bring in the geometry that is referenced by a feature.  The rest is just a ghost that does not actually affect the part studio. So, it matters when you ask about slowing things down if you are asking about interactive performance (rotating, panning, zooming the model) or regeneration (regen) performance (how long it takes to change/add features).  In-context should be much better for regen performance because it just has to copy a little bit of the context into the Part Studio and then use it for the feature.  It might slow down interactive performance depending on your machine though, because as you say we will be displaying the entire assembly.

The regen performance compared to deriving more than once from the same complicated part studio should be drastic though.  When you derive from a part studio, we need to regenerate that Part Studio to get the result of the derive.  If you import the same Part Studio twice, you are doing that regen twice and then extracting different data both times.  With in-context, you just take a snapshot of the geometry as it is (one-time cost) and are making little extractions from that, no regen required.

tony_459

Thanks again, Jake.

But if the derived part comes from a version (as opposed to main), wouldn't you also be working with a snapshot of the geometry as it was when you created that version?

After all, a version is itself a snapshot, and its geometry is fixed, so a regen should be unnecessary so long as you point to a version---no?

Jake_Rosenfeld

@tony_soares459

Ideally, yes, and we try to do as much version caching as we can.  Realistically, we cannot possibly store the full geometry for every version saved in the system.  It would be a _lot_ of data. The "snapshot" in the version is a snapshot of the state of the Feature List, and we put tons of safeguards in to make sure that that Feature List regenerates the same every time.

tony_459

Ah! Thanks, Jake. That is good detail to know. But you wouldn't you just need to store the geometry of the specific derived parts for the specified version number?

billy2

@tony_soares459

We'll be going over designing in an assembly at our user group on March 11th. We'll be webcasting it, 6pm pst.
https://rustyshed.com/?quill=5e52a6dbf97817411d9b45dc

"anti-pattern" what the hell is that?
http://agilemodeling.com/essays/enterpriseModelingAntiPatterns.htm

tony_459

One issue with in-context modeling:

If I remove the part from the assembly---to put in a subassembly instead of the main assembly, say---I lose the ability to update the assembly modeling context. This means that if the parts I need as references change, I have no way to propagate those changes to my part studio.

Another issue:

If I keep my part in the original assembly for context and I update various parts in that assembly and I need to propagate some but not all updates to my part studio (because only some are important and because the others would break things)... then I have no way to do this. I can update the entire context or not update any of the context, but I can't update some of the context.

It would be nice also to be able to hide and show specific context parts, as assemblies can be very large and the extra clutter can make it difficult to see and select the just the right thing. You can exit out of the part studio and go back to the context assembly to do the hiding and showing, but the extra steps and the extended wait turn what should be an instantaneous automatic action into a long hiccup in your modeling.

My wish:

It would be super useful to have in-context modeling just to create reference sketches from which to model various parts. In fact, this is pretty much all I need from my derived parts. Thing is, right now, you have to insert a part in the context assembly in order to retain the assembly context---or you lose the ability to update that context for the reference sketch.

I've done models in which I created reference sketches that I then inserted as Derived in other part studios. But I had to create the sketches manually, they very very often broke, and I still had to deal with the Derived features. I rarely need the derived parts themselves (save for the few cases in which I actually want to build on a part)... I just need the reference points that I get from the derived parts.

Just my thoughts based on my limited experience with in-context modeling. I'm still hoping this will allow me to work on large assemblies, because it's clear that too many derived parts will cripple the model and I don't have a good alternative for those. I need need need other parts for reference... but I'm not convinced that in-context modeling, as it is today, is the way out for me.

billy2

Project structure and how references are assigned is a really big deal and often over looked. I'd focus on a good project structure. If there are others in your group, write it down and have everyone follow it.

The problem with everything talking to everything else, it's chaotic. I'm not sure what you're building, but choose your references wisely. If you want it to scale keep it organized.

In the past, we wouldn't allow reference across sub-assy's. All reference went down to lower dependencies only and stayed in a branch of the tree. You could say that's an extreme limitation, but we had 6 engineers designing and no engineers fixing what other did. 

It's a big, post your project structure if you figure one out.

tony_459

My issue isn't with project structure. It's with ways to reference external parts. I can use derived parts and I can use in-context modeling. The first cripples my model. The second lacks the flexibility that drew me to the derived parts in the first place. I have no good way to reference external parts, and that is what I guess this post has morphed into (because my original intent was to point out that models keep breaking without input on my part, and that shouldn't happen ever, even if resources hit a limit).

billy2

Here's my assy where I'm designing:


Here's the part studio that has my make parts:


The bearings and cylinder came from mcmaster and assembled in the assy but are used to make the parts (incontext).

tony_459

I know how to make parts in context. I don't make them that way for the reasons I mentioned above. 

billy2

If all you want to do is control location in an assembly with a sketch; create a part studio with sketches then add the part with sketches to the assembly.

Attach inserted components to sketches in the assembly.

Change the sketch in the part, goto the assembly and update.

Make sure to call the sketch "skeleton".