Importing an .swb file from a supplier.

christopher_owens

Hello! I have attempted to import a file for a DE-STA-CO clamp created from their website's product page. I first tried importing the ZIP file (created using "SolidWorks, >=2001+" choice on their site), and received "Translation failed" messages in Onshape. I did this both on the Documents Page and in a Parts Studio. Then I uncompressed the ZIP file on my local computer and there was a text document file and a .SWB file for the clamp. I attempted to Import the .SWB file and all I get is a tab with the file listed. Anyone want to figure out how to get the clamp model to regenerate??? This goes along with 'Similar Parts' or working with supplier's models.

dennis_20

@christopher_owens, Every file import of an assembly in a non-native format will only bring in the parts and will not bring in the mates/constraints.  This is true between SolidWorks/PTC/Inventor, etc.  None of them can truly read the others' files and do more than bring in dumb solids (no mates).  At best the parts will come in in the same relative position they were in from their originating software (as you were able to do with some trial and error) and you can then add the appropriate mates yourself.

Until one software can truly read the information of another software this will be the case.  The best suppliers will make their solid files available in a choice of software that will save their components/assemblies in a format you can directly use without having to add constraints.  SolidWorks and Pro\Eh are two of the most popular.  OnShape is still in Beta.  I would not expect companies to offer their products in a native OnShape format until sometime well after it becomes a full production software package.  In the meantime you'll be doing what you've just done, but you'll discover what is the most expeditious procedure for you.

dennis_20

@andrew_troup,

... It must be burdensome for them to rewrite or reconfigure their websites with every annual update, for every legacy MCAD package they support.

This isn't really necessary.  Once a company has their files setup for a given software they do not have to update it for more recent versions as their older format files are still readable by the newer versions.  Some companies I've seen make their files available in (among other formats) SolidWorks 2001, but my current SWX2015 reads them just fine.

Besides that, in most cases we are looking for a good representation of the vendor's product and not their infinitely detailed production files, so even a dumb solid will do.  We just want to be able to find it easily and get it into our system for reference use.

With all due respect, the vendors that make their files available in various 3D formats will continue to do so until those particular packages die.  I don't see OnShape or any other 3D package for that matter becoming a de facto format.  IGES was supposed to be just that, a de facto 3D format standard, but it never did.

abefeldman

@christopher_owens - .SWB is actually a macro file, and the text document is likely the configuration file for the macro, which SolidWorks would use to generate your geometry.  Unfortunately, Onshape's translator can't perform that action.  Is it possible for you to download a different file type from their website, maybe a STEP or Parasolid (.x_t)  file?  The full list of file types Onshape can support is found here:  https://cad.onshape.com/help/#export.htm

christopher_owens

@abefeldman thanks for the help! I went back to the DE-STA-CO site and downloaded the clamp as a "Parasolid, Binary V15". I first tried to import the ZIP file, but got "Translation failed" (I figure it is because of the 'Terms of Use' text file in the ZIP). So I uncompressed the ZIP on my local computer and imported the 2002-S_90.x_b file and finally decided "Y axis up" and "Parts Studio Only" as the best choice. When I had Onshape create an assembly there were no constraints and the 'Parts Studio' showed the parts as they must of been individually modeled, stacked on top each other. The first choice left the parts in their assembled locations in the 'Parts Studio'. I figure this way I can assemble them so they move correctly. Since it was back in like 2004 that I did this before using SolidWorks, I think the clamp came in assembled and had the constraints so you could open and close the clamp for fixture design. But anyway, lesson learned!! 

dennis_20

@christopher_owens, Every file import of an assembly in a non-native format will only bring in the parts and will not bring in the mates/constraints.  This is true between SolidWorks/PTC/Inventor, etc.  None of them can truly read the others' files and do more than bring in dumb solids (no mates).  At best the parts will come in in the same relative position they were in from their originating software (as you were able to do with some trial and error) and you can then add the appropriate mates yourself.

Until one software can truly read the information of another software this will be the case.  The best suppliers will make their solid files available in a choice of software that will save their components/assemblies in a format you can directly use without having to add constraints.  SolidWorks and Pro\Eh are two of the most popular.  OnShape is still in Beta.  I would not expect companies to offer their products in a native OnShape format until sometime well after it becomes a full production software package.  In the meantime you'll be doing what you've just done, but you'll discover what is the most expeditious procedure for you.

christopher_owens

@dennis_20 Thanks!

andrew_troup

I think Onshape is eventually quite likely to become the premier de facto format for companies to publish models online.

I say this because it combines freedom from cost and complexity, with universal platform capability and versatile output formats.

Companies who wanted to, could simplify their offering by having only that single output format. It must be burdensome for them to rewrite or reconfigure their websites with every annual update, for every legacy MCAD package they support.

dennis_20

@andrew_troup,

... It must be burdensome for them to rewrite or reconfigure their websites with every annual update, for every legacy MCAD package they support.

This isn't really necessary.  Once a company has their files setup for a given software they do not have to update it for more recent versions as their older format files are still readable by the newer versions.  Some companies I've seen make their files available in (among other formats) SolidWorks 2001, but my current SWX2015 reads them just fine.

Besides that, in most cases we are looking for a good representation of the vendor's product and not their infinitely detailed production files, so even a dumb solid will do.  We just want to be able to find it easily and get it into our system for reference use.

With all due respect, the vendors that make their files available in various 3D formats will continue to do so until those particular packages die.  I don't see OnShape or any other 3D package for that matter becoming a de facto format.  IGES was supposed to be just that, a de facto 3D format standard, but it never did.

christopher_owens

If I remember right Pro/E at the start was only "backwards compatible" so many revisions. Perhaps SolidWorks learned from that!

dennis_20

Just for grins and giggles I still have some files from SolidWorks 1996 that I have not allowed to be saved in the current version.  SolidWorks opens them without a sceond thought.  But my oh my how my modeling techniques have improved!

abefeldman

@christopher_owens - glad to help!  At the moment, Onshape will only be able to read a .zip file if it contains a SolidWorks Pack&Go assembly.  For other file types, your best bet is to just upload the individual file directly, as you discovered.

@dennis_20 is correct about non-native file types being unable to contain mates, just relative position.  With that in mind, how would you expect the parts to be structured in Onshape after you imported them?

andrew_troup

dennis_20 said:

@andrew_troup,

... It must be burdensome for them to rewrite or reconfigure their websites with every annual update, for every legacy MCAD package they support.

This isn't really necessary.  Once a company has their files setup for a given software they do not have to update it for more recent versions as their older format files are still readable by the newer versions.  Some companies I've seen make their files available in (among other formats) SolidWorks 2001, but my current SWX2015 reads them just fine.

Besides that, in most cases we are looking for a good representation of the vendor's product and not their infinitely detailed production files, so even a dumb solid will do.  We just want to be able to find it easily and get it into our system for reference use.

With all due respect, the vendors that make their files available in various 3D formats will continue to do so until those particular packages die.  I don't see OnShape or any other 3D package for that matter becoming a de facto format.  IGES was supposed to be just that, a de facto 3D format standard, but it never did.

I freely concede that it is not necessary in theory to provide models in recent CAD formats, but it is what companies generally do in practice. Onshape provided us with a glimpse of one factor driving this behaviour: up until recently, dxf profiles were exported in the latest format, because it is the default expectation by tech-savvy people that "latest = greatest". (That, at any rate, was the explanation given). Of course, this shut out everyone who was not running the latest version of CAD software, or profile cutting software.

Because of their unusually responsive decision-making structures, Onshape listened to the users and quickly reversed this decision, so that dxf output is now in a very early version, which is far preferable, for the reasons you state.

But most companies are stuck in a broken paradigm, whereby their commercial needs are met by forcing users to keep the upgrade treadmill grinding. Furthermore, most companies would not be happy to tarnish their reputation with a website providing "ancient" output formats, such as Solidworks from last century (= last millenium!), or parasolid version numbers in single figures.

Vendor companies also have to cope with the continual emergence of new formats, as new MCAD packages have their turn in the sun. And the fine detail of their file formats is not typically open source, so it is a major undertaking in reverse engineering to provide truly robust models in a useful variety of formats.

Hence my proposition: that if Onshape becomes a multi-platform package, freely available and easily able to provide translation to most useful (rather than "latest greatest") file formats, hardware vendors could, (if smart enough) choose to make things a lot easier for themselves by providing models in a single format, and their clients would have a single viable and reliable workflow to translate those models into something usable by them all.

I don't pretend this will necessarily happen, and of course it won't happen across the board.  Nevertheless it would make a lot of sense, in instances where vendors chose that course of action.

But first, Onshape will have to succeed.