Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- 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.
Migration of vaults
pete_yodis
OS Professional, Mentor Posts: 666 ✭✭✭
I'm throwing this out there to get a conversation going... How many of you are starting to think about how you would eventually migrate data from a current generation file based data management vault into something like Onshape? I know it's early days and Onshape does not yet have what you need as far as data management in total, but what are your thoughts? Would you want Onshape to host all your legacy file based CAD data in all it's revision history? See any caveats that would prevent that? Would you leave legacy data in a different platform and move forward with new Onshape data all on it's own? Or, would you desire to make everything work in Onshape?
0
Comments
I'm hoping to get more parametric automation on design work so that I wouldn't need to copy&modify as much as I'm used to.
I have rather small amount of data since we only design for our own production.
no seriously, your comment hits the nail squarely on the head Pete. It is the drawings that are the issue. 3D data is 'relatively' easy to move using STEP or other formats. Indeed, there is a lot to be said about keeping legacy dumb models rather than native files only (for reference, when we release production data we retain the STEP, Parasolid and STL files as well as a SolidWorks pack and go archive).
the issue is drawings. Last time I switched systems internally in this little 3 man office we had around 10,000 drawing sheets...note the distinction...sheets...linked to models. We archive to PDF and DWG with every data release. As far as I am aware there are no 3rd party systems that open native SolidWorks drawing files (linked or otherwise). Ditto for other CAD systems.
Most companies I know who switched CAD systems retain at least one active on subs license of the old one for the purposes of conversion of old formats. Indeed, one customer I have, when they switched from SolidEdge to SolidWorks a few years ago just sub contracted out the entire process to a company in India to remodel and create drawings of all the legacy files into SolidWorks native. No small task.
if you want a business model for VARs in the future, look no further than file conversion.
For me, part or assembly files will stay in the original design software file format. If projects need to be reworked in Onshape, they will be recreated from the drawings or revised from dumb solid imports.
in SolidWorks you can save out a drawing file as a detached drawing which removes the link to the model at save time and lets you make some edits (but nothing that requires the model to load, like repositioning sections or adding breaks or crops). You can also save out DWGs from detached files.
If Onshape could open a SolidWorks drawing file and treat it as a detached file for minor edits, it would be something. Would be even more something if there was a way to relink to the SW or archived data and maintain all the drawing notation.
But then, Onshape has no drawings, yet.
My drawings are mostly dead already, we don't create standard drawings for each part or so.. Our workflow is kinda funny, usually I first create the looks and rendered images in cad. Then I get some minimum prints out to create cut lists, cnc programs and other works. Then I bring final dxf back to cad from cnc to apply holes into parts (it's just faster this way) and create assembly instruction images in cad.
In future I'm hoping to have smart parametric parts which would be shaped purely with parameters and move those parameters to cnc would create the drillings.
Years ago, I tried to create assembly documentation/instructions with drawings but it was just too painful so we have just used screenshots (from 3d workspace) as material for Inkscape.
I don't know if I have said it out loud earlier but I hate drawings, I really hope named views will create an option for them when standard form is not needed.
If I would ever archive drawing on each part, it needs to be completely automatic procedure (in my case this could be automated).
1) Old model converted into new Onshape model from a user choice on an as needed basis.
2) Someone applies the drawing information (from PDF files) to the Onshape Model. This is PMI or MBD, but it now eliminates the need to remake a drawing, in one sense. I would want Onshape to function like Synchrounous Technology here - such that the surfaces are the driving parameters and not the underlying sketches (remember the converted models into Onshape will not have underlying sketches either). https://designandmotion.net/siemens/siemens-solid-edge/siemens-solid-edge-and-the-st7-release/
Now we have an Onshape model at the latest revision that conveys the spirit of the old model AND drawing. If folks want a separate 2D drawing after that, that's fine and can be done and hopefully done efficiently from the information that already exists on the model and not a rehash of the same information in a potentially faulty redundant way.
3) The Onshape model and or drawing combination is released at the next revision level as "redrawn".
4) The previous generation model and drawing is archived for reference and safe keeping.
I also wonder if.... Onshape could replace WorkGroup PDM or EPDM and SolidWorks users would check-in to Onshape instead of checking into the previous vault. This would be a lot to ask, BUT it would provide a way for folks to work in both CAD realms with Onshape being the Glue that keeps it all together as well as the obvious bright shining future.
I also wonder what the partnership between Onshape and GrabCAD is all about. Maybe GrabCAD is that glue that keeps it together and does the aforementioned above. That adds another layer, which is OK as long as there is not much friction between all the authoring systems and management systems.
@michael3424 The downside is that yet another document is added to the mix of what is needed to convey information. When you have 83,000 +, you try to keep things simple enough. PDF is the band-aid to the problem of heavy CAD programs not having a good way for people to view information. Onshape solves that with Full Cloud Browser based viewing. Nothing more is needed. Going back to PDFs once we are cruising on Onshape is like going back to the old band aids just because that's what we know. With Onshape, we just need to share the document - and maybe soon even better than that with a public view option... Here's a discussion for reference...
https://forum.onshape.com/discussion/898/share-model-outside-onshape-public-link-view-only
On the other hand, I'm working with 20+ year-old drawings of a late 1800's IC engine and have all the parts drawings, but no complete assembly drawing and am currently stuck trying to figure out where a couple of the parts go. Even a dumb assembly would be helpful for that problem.
Far from simply raw data (whose provision can easily be outmatched both in quantity and accuracy in 3D), a good 2D set of plans is heavily processed into information, and in some respects, reaches further into knowledge support.
Sometimes multiple views will share a real-life location and viewpoint, but depict reality differently, to fulfil differing needs.
For large, complex projects in particular, there is considerable skill exercised in drawing our attention to what is important and what is potentially problematic by choosing and ordering and inter-relating views, and deciding what and how much to show in each one, what to leave out, and on important but hopefully rare occasions, what to fudge.
These three ways to exercise discretion are the pillars of abstraction, and abstraction is at the root of all conceptual thinking.
London's Underground "Tube Map" is a famous example of the third of these pillars. The breakthrough realisation was that, because the sense of direction and depth are lost when travelling through the earth, they can beneficially be left off the list of things to be faithfully depicted. The result is less than 2D, and yet considerably more useful than 3D, which is presumably why all subsequent metro systems copied the idea, and still do eight decades later.
Tools of 2D abstraction applicable to engineering drawings start with detail views, discretionary depiction of hidden detail, items omitted or scrap sectioned, alternative positions shown in different linestyles, imaginative (and sometimes topologically impossible) contouring of section planes, suggestive use of witness lines, schematic diagrams and judicious hybrids of schematic with representational - and this is just a peek into a grab-bag of possibilities which are limited largely by imagination alone.
That's one reason it's so unexpectedly difficult to wring automatic 2D output from 3D models.
I don't think the reason Onshape's drawings remain seemingly stuck in "constant time to completion" phase is that they're sitting on their hands.
A well drafted set of 2D drawings is like having a skilled guide walk you through an archeological dig, as opposed to "here's the keys, fill your boots"
---
There's no reason why individual 3D developers cannot step up to this plate, but it's a boggling challenge to come up with a sufficiently unified approach to rival the status quo ante, which is remarkably decipherable across all engineering disciplines, and across the planet.
And I think, at the root of this, it's because 2D linework is not proprietary in the slightest degree.
It's not even, in the slightest degree, platform specific. It's innately, inherently universal.
It has been around since we walked out of Africa.
3D geometry, as soon as we attempt to capture it, becomes intensely proprietary.
It's not a conspiracy, or a failure of imagination, which has kept 3D pdfs from supplanting 2D ones.
It's the gulf between what's possible and what's practicable.
"TubeMapZ1 TFL" by http://www.tfl.gov.uk/assets/downloads/standard-tube-map.pdf.
Licensed under Fair use via Wikipedia -
https://en.wikipedia.org/wiki/File:TubeMapZ1_TFL.png#/media/File:TubeMapZ1_TFL.png
Back to the Migration story....
My workflow above was more of a dream/desired workflow for a time in the future. I see that as the most efficient possible one. How about for the now, if Onshape were ready?
What would your desired workflow be for dealing with conventional/current file vaults and also the Onshape full cloud database CAD platform? How do you mingle these, or don't you? Do you leave the old data in the old system and say all new products are in Onshape, and bring needed data in the old system into the new one on an as needed basis? Or would you prefer Onshape to be the complete new system? (I've migrated data twice from previous systems into newer ones and we always moved everything and rolled forward completely in the new one). And again, what is GrabCAD up to in this area with Onshape as a partner? What is the path for a conventional vault user that doesn't want to be tied to the aging systems and subscription revenue tied to them and not applied to something like Onshape/GrabCAD?
And which was in any case not addressed to you particularly.
But although you seem to misunderstand what I wrote, I do apologise for using your thread as something of a soapbox.
I started my post with the intent of sharing something which popped into my head, as a possible barrier - rarely mentioned, let alone dissected - to the faster adoption of 3D as a self-sufficient project descriptor. I did incidentally think was a topic which concerned and perplexed you.