Can not find a part in assembly

hans_11

Hi All!

I am a mechanical engineer and use SolidWorks every day.
But in Onshape I have a problem (c:

when I stand in the assembly and wanted insert  a part

So I can not see my parts ?????

cyclonewade

@hans_11

Onshape documents are like containers, in which they contain assembly studio and part studio tabs. 

To insert a part in a documents assembly studio, the part studios (currently) must reside in the document container.  Onshape is working on document to document referencing, its not available currently.

I suggest you watch some of the excellent training videos to understand the difference between documents and traditional windows files.  You can copy and paste part studios from document to document easily, so getting your part studios from the existing documents into the "Filament bucket assy" should be pretty straight forward.

I'm also a SolidWorks users, so I understand the thought of creating multiple documents for single components.  In the case of Onshape, we have to think a bit differently.

Good luck.

Wade

viru

You have created required part for assembly in different document ( test1 and test2 ). To insert a required part in assembly you have to use "copy to clipboard" option to copy the part studio (part studio from test1 and test 2 document)

and "paste tab" option to paste in "filament bucket assy" document. Now you can insert required part in assembly. I hope in near future Onshape user can insert part from different document also.

andrew_troup

viru said:

You have created required part for assembly in different document ( test1 and test2 ). To insert a required part in assembly you have to use "copy to clipboard" option to copy the part studio (part studio from test1 and test 2 document)

and "paste tab" option to paste in "filament bucket assy" document. Now you can insert required part in assembly. I hope in near future Onshape user can insert part from different document also.

I personally hope Onshape does not introduce that ability. One of the key strengths of Onshape is that models never rely on references to external files - and if you need that ability, a more traditional MCAD package is perhaps a better fit for your needs.

Obviously library parts like fasteners need to be able to update across a whole organisation, but I would hope to see Onshape dealing with that by providing software tools to "push" the updates to the various documents using those parts, rather than the documents needing to "pull" them from a library.

That way, the documents would remain self-contained, and could never be orphaned.

3dcad

@andrew_troup Interesting approach. I've been waiting for possibility to create standard part documents and use those parts in part studios as well as assemblies (like traditional cad) without thinking the big picture. I'm also big fan of templates since I'm mostly working on sheet based material.

What if 'standard part' document is a shared one and is no longer shared or other similar situation that Onshape provides. I need to give this more thought since this is one of the key features I'm waiting for..

I agree on self-contained documents since it's pure pain to open old assemblies that might have lost, moved, removed or renamed parts inside.

Andrew (or anyone else), do you have more specific thought of how standard parts could be introduced in Onshape in order to avoid orphaned documents and support share situations that Ons provides?

traveler_hauptman

I'm confident that Onshape understands a portion of their customers have common parts and subassemblies that will be used in multiple products.

Regarding push vs pull, this is a solved problem in software package management using version control. Onshape uses version control. Problem solved.

(If you want push (automatic update) response to upstream changes you reference the 'latest version' in the repository, if you want pull (no/manual update) response to upstream changes you use the specific version number.)

Onshape can eliminate any problems associated with moving, deleting, and renaming externally referenced documents if they choose.

I'm looking forward to the issue voting system. It will be interesting to see what issues rise to the top....

cyclonewade

@hans_11

Onshape documents are like containers, in which they contain assembly studio and part studio tabs. 

To insert a part in a documents assembly studio, the part studios (currently) must reside in the document container.  Onshape is working on document to document referencing, its not available currently.

I suggest you watch some of the excellent training videos to understand the difference between documents and traditional windows files.  You can copy and paste part studios from document to document easily, so getting your part studios from the existing documents into the "Filament bucket assy" should be pretty straight forward.

I'm also a SolidWorks users, so I understand the thought of creating multiple documents for single components.  In the case of Onshape, we have to think a bit differently.

Good luck.

Wade

viru

You have created required part for assembly in different document ( test1 and test2 ). To insert a required part in assembly you have to use "copy to clipboard" option to copy the part studio (part studio from test1 and test 2 document)

and "paste tab" option to paste in "filament bucket assy" document. Now you can insert required part in assembly. I hope in near future Onshape user can insert part from different document also.

andrew_troup

viru said:

You have created required part for assembly in different document ( test1 and test2 ). To insert a required part in assembly you have to use "copy to clipboard" option to copy the part studio (part studio from test1 and test 2 document)

and "paste tab" option to paste in "filament bucket assy" document. Now you can insert required part in assembly. I hope in near future Onshape user can insert part from different document also.

I personally hope Onshape does not introduce that ability. One of the key strengths of Onshape is that models never rely on references to external files - and if you need that ability, a more traditional MCAD package is perhaps a better fit for your needs.

Obviously library parts like fasteners need to be able to update across a whole organisation, but I would hope to see Onshape dealing with that by providing software tools to "push" the updates to the various documents using those parts, rather than the documents needing to "pull" them from a library.

That way, the documents would remain self-contained, and could never be orphaned.

3dcad

@andrew_troup Interesting approach. I've been waiting for possibility to create standard part documents and use those parts in part studios as well as assemblies (like traditional cad) without thinking the big picture. I'm also big fan of templates since I'm mostly working on sheet based material.

What if 'standard part' document is a shared one and is no longer shared or other similar situation that Onshape provides. I need to give this more thought since this is one of the key features I'm waiting for..

I agree on self-contained documents since it's pure pain to open old assemblies that might have lost, moved, removed or renamed parts inside.

Andrew (or anyone else), do you have more specific thought of how standard parts could be introduced in Onshape in order to avoid orphaned documents and support share situations that Ons provides?

traveler_hauptman

I'm confident that Onshape understands a portion of their customers have common parts and subassemblies that will be used in multiple products.

Regarding push vs pull, this is a solved problem in software package management using version control. Onshape uses version control. Problem solved.

(If you want push (automatic update) response to upstream changes you reference the 'latest version' in the repository, if you want pull (no/manual update) response to upstream changes you use the specific version number.)

Onshape can eliminate any problems associated with moving, deleting, and renaming externally referenced documents if they choose.

I'm looking forward to the issue voting system. It will be interesting to see what issues rise to the top....

andrew_troup

My unqualified use of the terms "Push" and "Pull" was not very helpful - as/or perhaps was my suggestion that the crucial situation is standard parts, in the scenario where they are updated, propagating to assemblies. It's an important scenario, but not exclusively so. Any externally generated parts have the potential to raise at least some of these issues. Mea culpa. 

Seems to me the key thing, regardless of whether an amendment to a part belonging to an assembly is pushed or pulled, is that the recipient document, under Onshape's new paradigm, should not be routinely looking elsewhere for the information, but be self-contained at all times. 

In the Solidworks environment, the link generally stays live at all times (external files are referenced by assemblies) so any updates propagate without user intervention.

It seems to me there's a major advantage of a push presumption in regard to changes and updates, namely that the recipient document does not have to concern itself with whether the donor document has changed. Because in order to do that, it has to know where that document is, at all times. Which leads to obsessive behaviours, which can be tiresome to live with...

The donor document is being attended to when it is changed, so it seems to me to make sense to trigger the update from the donor (ie 'push' it)

This does not rule out a discretionary pull alternative ... so long as that is not the expectation, but is triggered only as needed  ... at which time the donor document can be located and served up by the user, or by a routine under nominal user control.

This, on reflection, is functionally barely distinguishable from pushing, it seems to me, but the user interface could be finessed to permit easy navigation from the recipient document to the donor document in order to set the push in train.

I do think there needs to be a flag in the recipient document to specify how it will behave when there is an attempt to push an update to it, seeking to revise one or more part studios: will it accept updates unconditionally (after checking the model does not fall over as a result), or will it raise a notification to the "owner" seeking permission, or perhaps some models (eg "as-built" models reflecting historical fact) might refuse outright until the flag condition is changed?

I think that's tightly bound up with version control, as traveler_hauptman  suggests, but I thing there are nuances which will come into play, and I'm not currently clear on just what they are.

andrew_troup

traveler_hauptman said:

I'm looking forward to the issue voting system.

Me too. Certainly long, and keenly, awaited. Perhaps a case of the opposite of déjà vu - maybe 'pas encore vu'?

traveler_hauptman said:

.
It will be interesting to see what issues rise to the top....

Indeed it will