Importing Assemblies

Mecha

1) I noticed when importing a moderate size X-T assembly, all of my parts ended up stacked in a single location. It makes it really difficult to use it, with every imported part in a common origin.

2) I noticed when importing surfaces, they get translated into the part studio, but not the assembly. they are not considered parts at all and the geometry cannot be used.

billy2

In the sending CAD system, save the assembly into a part file. This produces bodies in a part file. Then import the part file.

If sending CAD is SW, open your assembly then click save-as sldprt, all components. You can then save the part file as a parasolids and bring it in or just import the sldprt. That's how I got my SW geometry into Onshape.

scott_harris

Also... we do not fully support surface yet so there are lots of limitation when creating and importing them. Currently, they will not show up in assemblies.

joe_dunne

Tip for part studio parts all coming in on top of each other.

Bill described one viable option of saving a SW part file from a SW assembly. And this is a viable option. However Onshape actually will do this for you if you select the option flatten uploaded assemblies as part studios.

mark_biasotti

I have a SW part that will not import correctly (i.e. bodies missing) but it does import correctly using parasolid. Is OS interested in debugging?

lougallo

If there are specific issues, please submit a ticket from the feedback form in the ? menu so we can debug it. Thanks...

Ben_

FYI I was toying with the idea of doing some bolean functions in an assembly. This cannot be done currently. So I took that assembly and translated it to STEP then took the STEP file tab and translated it to onshape with the Flatten assembly to part studio. That allowed me to be in the Part studio environment and do some bolean functions on a part.

File this under nifty workaround

lougallo

@Ben‌ This would make more sense when we have in-context editing since boolean operations should live in the part studio, not the assembly, unless it was like an assembly feature.

mark_biasotti

If you really want to best SW - then allow the user to reorient the default coordinate system in OS as an option. SW users have been asking for this since day-one.

M

billy2

To me the proper fix to this problem is to transform the geometry. I don't think a simple view manipulation will be enough.

How hard is it to rotate geometry 90 degrees about X while translating it? There's gotta be a function for this? Hopefully. Should be one line of code attached to one checkbox.

mark_biasotti

@bill‌
I don't think a simple view manipulation will be enough.

Hi Bill, if you are addressing my response I'm not talking about a view reorientation but actually reorienting the default coordinate sys and default datums to be Y is up verses Z is up.

M

billy2

Yes I was making a comment to your suggestion and stretching it a little further. My fear is that OS's solution will be a view manipulation which is how spaceclaim solved this problem. This doesn't work as drawing orientations aren't correct and other things don't propagate and work correctly after this quick fix.

Sorry, I didn't intend to demean your comment. Sounds like you want to move the root coordinate to the geometry and I want to move geometry about the root coordinate. I think we're on the same page.

OS please don't change default view with 'Y' up. This is what I should have said.

stevehess

HI @mbiasotti‌ , I completely agree re: coord systems orientation; a method of mapping coordinate systems (or setting CS orientation) is in the works. Soon..... I'll add you to the ticket on that one.