Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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.

Can not find a part in assembly

hans_11hans_11 Member Posts: 1
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 ?????

Best Answers


  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭
    edited July 2015
    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_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭
    edited July 2015

    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'?

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

Sign In or Register to comment.