Document

nick_taranto

Am I understanding what a document is?

I understand that it like a project.

Any number of assemblies, sub-assemblies and parts are within a document no matter how large it gets to be.

Thus it is possible to have 10 very large projects in the free version and when that limit is reached you can delete old projects or make them public.

Am I off base?

Thanks

nav

Hi @nick_taranto I suggest you read these two posts about the issue.

https://forum.onshape.com/discussion/1414/nitty-gritty-details-of-free-plan/p1

https://forum.onshape.com/discussion/1026/what-will-be-the-upcoming-changes-to-the-onshape-free-plan

billy2

That's right, or you can group like parts together also. 

I group in documents:
Motorcycle parts 
Household parts
Brackets

Having too many documents is un-manageable and grouping like parts, not necessarily projects is a good idea.

andrew_troup

@nick_taranto a document can also contain non-Onshape files, like brochures, specs, calculation spreadsheets etc...

shashank_aarya

@nick_taranto You can share the document to any number of users whenever collaboration in work is required

pete_yodis

@nick_taranto You might enjoy attending this upcoming session on documents...

https://www.onshape.com/onshape-project-container-sept-3

3dcad

I'm still struggling with this. Otherwise it would be clear, but recently I begin testing versions and branches; they are document wide.
So if you have all your brackets in one document and need a new version for one of them - the new version covers all of your brackets.

I would like to have tab history and tab versions.

_Ðave_

@3dcad

 +1 for tab history and Versions

 Wouldn't that be wonderful, I've also been struggling with how to accomplish revisions of individual parts also.
Individual tab history and versions could be an approach that may solve my problems.
Thanks for making the improvement request

pete_yodis

Yes, the current revision/version mechanism is not granular enough.  Currently you could keep individual parts in their own document, but without the ability to cross document reference you are stuck designing a part that can be properly revision managed, but not used in an assembly outside of it's own document.  When Onshape releases cross document referencing this will solve that.  I wonder beyond that if we will have granular enough control that bodies within documents (even within a tab) will get the ability to have history/versions.  This would match what people are currently accustomed to.  For example, you have a part studio where 25 bodies are generated and managed.  Can each of the bodies have their own revision/version tracking apart from a whole document level capture?  And also, can a body in a part studio be used outside of that document in some other unrelated document?  This will be needed in due time.  The document in Onshape seems a little like an abstraction at the moment.

andrew_troup

I wonder if there's ever realistically going to be a way to de-intertwine the history of parts which are designed mutually in-context...

We might just have to resign ourselves to not being able to have (as they supposedly say in parts of Italy), both "a full barrel, AND a drunk wife"

pete_yodis

andrew_troup said:

I wonder if there's ever realistically going to be a way to de-intertwine the history of parts which are designed mutually in-context...

We might just have to resign ourselves to not being able to have (as they supposedly say in parts of Italy), both "a full barrel, AND a drunk wife"

In a platform like SolidWorks, you can de-intertwine the relationships defined mutually in-context.  You delete all relations that are "in-context".  I've done it myself and instructed others to do the same for sake of simplicity of managing the data in the long run, and making use of parts that are then potentially used in other products where the in-context relationships would be doubly confusing.


I wonder if at some point Onshape may allow all bodies defined in a part studio to be saved out to their individual part studios and the in-context relationships "nuked" in a sense.  This might signal the end of the layout stage and the beginning of maintaining the data in the long haul.

I wonder if folks will want each document to define only one part number.  This would be similar to staying away from the conundrums of having multiple part numbers defined in configurations within a single file.  Yes, it demos well and looks really slick - but try managing that information over the long haul compounded by thousands of part numbers in who knows which files.

andrew_troup

In choosing the word "mutually", I was trying to flag the situation where some entities on part A referenced entities on part B, and vice versa -

which is dicing with death in Solidworks (because the likelihood of inadvertent future creation of circular references, hence spontaneous unsupervised size changes), but routine in an Onshape Part Studio ... and the viability of that bi-directional, yet risk-free referencing is one of Onshape's big attractions, it seems to me. Because adjacent parts in the real world DO often have a high degree of mutual interdependence, in contours and features as well as dimensions.
  
The parts in an Onshape studio do not have individual feature trees -- which is one component of what I meant by "history of parts" -- but there's also the undoable "sequence of operations" history.

The former (I would think) will become almost impossible to repair back to the point of being editable when a significant proportion of relationships and dimensions (including things like extrude distances) are dangling (which would be inevitable after separating "Siamese quintuplets" or worse), and I can't see how it would be realistic to provide any sort of meaningful "sequence of operations" history whatsoever for separated parts, because it would be so full of unexplained holes. (Even the present form is surprisingly difficult to interpret usefully, let alone use in any major way)

So it's arguable that the result of such a separation would offer little advantage over simply saving parts as dumb parasolid bodies.

Maybe there needs to be a quite different environment to support parts released to manufacturing, because the requirements suddenly change drastically at that point, as illustrated by @pete_yodis' example of discrete files for discrete part numbers: highly desirable for manufacturing, but problematic for live design ops.

Many of the advantages of Onshape seem to me to accrue prior to that stage. But I don't pretend to have thought about it in any depth .. yet. Thanks to those who've turned the discussion in this direction: it seems like the right time to be considering these issues. 

pete_yodis

@andrew_troup Yes, I wonder if released entities should be treated differently as well.  I don't know yet with the Onshape system.  It seems as the differing nature of layout design and managing information later leads us to a sort of bifurcated state.  Although it could be me not seeing enough and understanding enough in this realm.  I don't know how to rectify that at the moment apart from asking questions and trying things in my own layouts.  Onshape may have some tricks up their sleeves for us later, too.  I don't know.