Presented by
When Onshape added linked documents a few weeks back, I don’t think I even looked out from my box of Cheetos. On second look, it might just be the most important feature of the year thus far.
Life, the Universe and Everything
As of April 2016, Onshape lets you use parts from one project in another. This means you can have libraries of standard parts, for example, and reuse those parts in all 42 of your current projects. Make a change in the library part, and all 42 update.* (Cue intergalactic cabaret dancers.)
* They don’t update right away. That would be dangerous. What if you don’t want to update yet for a given project? Onshape lets you choose whether to update a given referenced part to the latest version or stick with the old one. More on that below.
If you’ve ever done any of the following, this feature is for you:
- Use the same part or assembly in two different projects
- Use a supplier’s part in your own assembly
- Share a part or assembly for use in a customer’s project
- Share one part with a supplier, but keep the rest of the project confidential
We all knew this feature was coming. It’s a prerequisite of any serious manufacturing MCAD system, and the entire Product Data Management (PDM) industry exists, in large part, as a way of working around the problem of data reuse.
PDM’s mythical “Single Source of Truth” is a lie. There is never a single source of Truth. Every project involves multiple truths coming from multiple sources: suppliers, part catalogs, previous projects, competitive products, ergonomic data, industry standards. If it were all about a single source of Truth, it would be easy. As Truth generally is, it’s more complex than a PDM salesman will admit, and it’s in the management of that complexity that there be dragons.
We all need to reuse data across multiple projects, but keeping that data up-to-date (or not) is surprisingly hard.
In file-based data management systems, data linking and revision control is an inherently slippery business. Not so with a central database.
In the cloud, all of your data lives in One Big Database. That means tools like Onshape have the advantage of not requiring special PDM procedures for file management, syncing across data centers for global access, etc. Everybody has unfettered access to the entire catalog at all times from one clean, simple, searchable UI, and all directly integrated into the CAD tool itself.
And lest you think this is easy, note that (as of today) the Other Guys don’t do it yet. In fact, Onshape is the only cloud tool so far to offer linked data across multiple projects, and it’s the only product on the market–cloud or otherwise–to make it look easy.
What’s most interesting about Onshape’s specific implementation is the way they handle engineering changes. Onshape’s built-in PDM system is unique, and easily one of the most important advantages of their ecosystem. The “branching and merging” paradigm they’ve built makes it trivial to try new ideas safely and efficiently, and that same fluid workflow applies to document linking.
A note to the blasé: those of us who’ve worked with enterprise PDM systems for CAD file management, this might seem like par for the course. You undoubtedly also know, then, that ePDM systems have massive IT overhead–usually at least one dedicated server and full-time technician–and that proper use of those systems requires week-long training sessions for system administrators, multi-day training sessions for each end-user, and careful adherence to best practices by everyone. Traditional PDM systems also have significant mental overhead for users, requiring users to think hard about each action to insure compliance with the broader system.
I’ve spoken with hundreds of CAD users, and I can say this with certainty: everyone hates PDM.
Onshape’s most important accomplishment is making PDM a no-brainer. It takes what used to be an expensive, time-consuming distraction, and does it all for free. What used to be advanced PDM features are now so effortless as to seem incidental. I can focus on design ideas without a wasting single thought on data management.
Mostly Harmless
I’m designing a wifi-enabled turret-mounted inter-continental water balloon ballista. We call it the B2, and it’s as epic as it sounds. It’s actually a new iteration of an older ethernet connected version of the same product (the B1). I need to reuse parts from the B1 in the B2, but with a few modifications.
Sounds easy. It’s not.
I actually have a whole defense contracting company built around ballistic turret launchers: the Needlessly Whizbang Mostly Harmless Low-Tech Weaponry Corporation of Northern Virginia (NWMHLTWCNV for short). Traction trebuchets, counterweight trebuchets, bombards, onagers, mangonels, ballistas, springalds… you know. Your basic medieval artillery arsenal retooled for water balloons and desktop computing.
Anyway, we’ve decided to use the ratchet pulls from the B1 in the new B2 model. As it happens, Simon’s been working on improving the ratchet pull system for the entire ballista line. This leaves me with a problem: what if I design my turret around the current ratchet pull mechanism, but then Simon makes an update? Doesn’t that risk breaking my model and setting me back during the prototyping phase?
Not a bit of it.
Milliways and the Golgafrinchans
Revision control ain’t the sexiest topic in the world, but can literally make or break a turret-mounted water balloon ballista, trust you me. When we make changes in the part library, we need to be careful about pushing those to other designs automatically, lest we cause problems for people working on live projects.
The joy of the Onshape linked document system is that you never actually link to a part per se, but rather a version of a part. Since all versions of all documents are saved for all time, this means you can safely reference any version of any document without fear of downstream changes.
Once Simon is done making his changes, my assembly gives me a little icon alerting me to the new version. I know I’ll eventually want to bring it in, but we’re right in the middle of prototyping. I’d rather not introduce the changes until we’ve seen how the first proto behaves. So I wait.
After the 0.1 proto is finished, I choose to update to the latest version, and viola: Simon’s changes are now in the B2 assembly. Looks great.
Just as importantly, the B1 assembly still uses the older version. That’s super important because we’re still shipping the B1. The assembly needs to accurately reflect the product as it exists on the market. With Onshape’s version system, that’s a given.
Thanks for All the Fish
So yeah, linked documents in Onshape. Pretty great in a team setting, but even more so if you’re a parts supplier or a user of parts from a part supplier.
Imagine, for example, if a catalog like McMaster were added to Onshape as a linkable document. No more downloading STEP files, just link directly to the part in the catalog. Use it in your design. When McMaster needs to update a part in its catalog because of a supplier change, for example, you’ll know your designs won’t be affected unless you explicitly choose to accept the updated version. You can already access the Traceparts library directly from within Onshape. Linked documents would only make integrations like these even better.
Definitely take a look. You can sign up for Onshape here.
