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.
Options
Is referencing an assembly's "Display State" broken in creating a drawing view?
StephenG
Member Posts: 367 ✭✭✭
I have an assembly with a couple of display states where both of them have an instance "hidden".
When I attempt to insert a view the insert view dialogue has the pull down to select a Display State, but they are not listed. The field just shows "Show All".
When I attempt to insert a view the insert view dialogue has the pull down to select a Display State, but they are not listed. The field just shows "Show All".
0
Best Answer
-
Options
john_mcclary
Member, Developers Posts: 3,898 PRO
Right, any change, or slight modification including undoing an action you may have done after creating a view will require an update.
This is to maintain a strict release state. It only reflects the updates you make, when you demand it. This lets you keep making changes for the next version while someone continues to use the last know good drawing. (for those of us who do not utilize release management)5
Answers
If you create a "Display State" in the assembly after the drawing has been created containing a view referencing that assembly, the Drawing must be updated before the display state appears in the list of available "Display States" to select from.
I noticed that ANY change to information referenced in a drawing, whether the change is affects what appears on the face of the drawing or not, requires the drawing to be updated. Even changing meta data of referenced data triggers the need for an update. At this time is appears that Onshape takes the "Safe Approach" and regenerates all the views and annotation to make sure everything is properly reflected in the drawing.
It seems I spend a lot of time hitting the "update" button and waiting for the drawing to regenerate.
This is to maintain a strict release state. It only reflects the updates you make, when you demand it. This lets you keep making changes for the next version while someone continues to use the last know good drawing. (for those of us who do not utilize release management)
Just to be clear, this is the display state icon . . .
and on view creation, all defined display states are shown . .
Please feel free to post a public link if you would like any further help.
Appreciate the effort to unconfuse me, but I was not confused. I see how one can be easily confused because Onshape can be confusing at times. Many fields in Onshape dialogue boxes lack labels which provide clarity (reduce confusion), for example, Insert View.
Comment on "Named Views"
Somewhat cumbersome to use because it lacks "Update" capability and is not associative in the drawing. I use "Named Views" to create non-std drawing views with arbitrary camera POVs that best show what I want shown in the drawing. If I need to make a subtle change to the camera angle I have to delete the view and reinsert it.
It is a mistake to leverage "Named Views", which support 3D design activity, with creating non-standard drawing views. The usage scenarios are completely different.
I have a workaround that allows me to establish a POV with the ability to change it later, but it is an extra step with more data management which shouldn't be necessary.
Comment on Drawing Updates
Onshape needs to be a lot smarter about when a drawing update is required and what portions of the drawing need to be updated. The process needs to be "surgical" rather than always invoking the "nuclear option" of regenerating every view in the drawing at the slightest hint that something has changed.
I hope I explain it correctly.
Decouple the assy or part from the drawing. It's working for me.
I design to a point when the design should be versioned. Something that's kind of complete. Version it. Then in the drawing, reference the version. Drawings run much faster when referencing a version. Updating is annoying and only happens when you're doing design & drawings at the same time. Me, I'll do the drawing at the end. This to me is a preferred design pattern. OS will do it simultaneously, but versioned detailing is much better.
Also, create your drawings in another document depending who you need to share. ie... sheet metal drawings should be a sheetmetal document, machined drawings in a machine document. When you go to share, this will make more sense.
When you reference a document inside another document, versioning kicks in.
This means your project should be in a folder handling many documents.
This project schema is working very well for me. Try it, you'll like it.
Everything in a document is no es bueno.
It has been my practice to create a drawing during the design process. I find it helpful because it allows me to capture/express critical tolerancing information during the design process. I know it would be better to add this information directly to the 3D and have the ability to leverage it, if and when a drawing needs to be created, but Onshape currently lacks that functionality.
Your point about using multiple documents to share and to create supporting information by other disciplines is well taken. Even though I am a one person show and most of what I use Onshape for is very simple, I now see the benefit of separating things into different documents and use a "Project" folder to "collect" all pertinent documents together.
You are correct in that I should be versioning my document (design) more frequently to make it easier on Onshape. I see that having an intimate knowledge of how Onshape manages data references and how it impacts performance is important, unfortunately most people (like me) learn it through pain and suffering, as opposed to reading a white paper on the internals of Onshape data management. I find pain to be an very effective teacher.
Thanks again for the very useful info.