OUR EXPERIENCE W/ ONSHAPE

A few weeks ago I announced that we were taking the plunge to Onshape for our production CAD needs.

Onshape announcment on Linkedin

A few weeks in I’m clear on two things:

  1. Onshape has a lot of work ahead of them.
  2. Even today, I don’t ever want to go back.

Let me tell you why.

skip this section if you just want the list of good/bad/annoying/TBD features

Having grown up in design consulting at Farm (and later spending time at Continuum), clients dictated CAD tools. As a result, I spent a lot of time (and consider myself a pretty advanced user of ) both Pro|Engineer (now Creo) & SolidWorks.

In recent years I’ve led the mechanical teams at two startups, putting me in a position to specify a CAD tool. I’ve historically preferred Creo for its control and raw power, but have chosen SolidWorks on both occasions due to its low cost and wider user base.

And it was fine. SolidWorks was fine. Just fine. It was fine.

Onshape came on my radar (thanks to Scott Mackie back in 2015. I got excited about the philosophy of (SolidWorks + Google Docs + Git), took part in the beta, played around with it a bit, but still felt that it wasn’t ready for prime time.

I then moved on with my life until I saw this tweet from Jon Hirschtick

You see, for me, the N-sided fill is a safety net. I don’t use it a lot, but sometimes sweeps and lofts just won’t do. Sometimes you need a patch.

Also, some time had passed, and I was curious to see if/how Onshape had progressed.

Furthermore, I was now part of a team that had EE/FW in Milan, mechanical/manufacturing and manufacturing operations in Korea. The remote nature and time zone difference meant that sometimes simple questions like “what is the distance between those parts”, could mean a 24-hour turnaround.

Boston — Milan is a 6-hour time difference

image-20210117000046496

Our Git flow. Pre-OnShape Solidworks Branching What’s interesting is that we were successfully using git/GitHub for a low-overhead version control of our SolidWorks database, so a combination of git/GitHub/edrawings would allow anyone to pull measurements as they could with Onshape.

This never actually happened though. Maybe it was unfamiliarity with git for some or an eDrawings issue with Mac on another, but in the end, it was a tool chain that set up barriers that would only be jumped in the most critical circumstances (i.e., still slowed down development).

Anyway, I followed up with Jon and got a trial. We did some diligence to prove to ourselves that our SolidWorks design was also buildable in Onshape.

It could (though my spline construction had to change), and we decided to make the switch.

Since the switch, I’ve tracked things I consider notable. They fall into three categories: the good, the bad, the annoying, and the TBD.

The Good

Branching/Merging

Onshape Branching

A huge value proposition of Onshape is its ability to branch and merge. This lets me explore other designs without polluting the CAD database of record, but then merge back in that exploration if it turns into the database of record.

The first time I branched (to explore an alternate configuration of a circuit board) I did so with reckless abandon: I made unrelated changes, added/deleted features, changed sketch dimensions and variable names, added folders, appended PDFs, and probably some other things.

I then went to merge… and it didn’t work. I got an error saying:

“Failed to merge V12 into current workspace dev. An internal error has occurred; support code ef5064da1450….”

Naturally, I wasn’t pleased. However within the day, I had several back and forths with support, and it had been identified as a bug. Within a week the bug was fixed, and I merged everything successfully back into my main branch.

So, yes, there was a bug. I was fortunate that we didn’t have a release in that week as there was work happening on multiple branches. That said, such a speedy response (and the ultimate AMAZING ability for such an array of changes to be merged) deserves props.

Keyboard shortcuts

I’m not a monster. Of course I used keyboard shortcuts in other CAD programs. Still, I found Onshape’s out-of-the-box to be pretty good. In anticipation of switching I changed my SolidWorks shortcuts to match and noticed productivity even then.

So not a tech advantage, but a design element that was well-considered (that’ll be a theme)

Onshape Shortcuts

Support

This can’t be overstated. Onshape clearly knows that the people paying for this (free unless you want public docs, then $1500/year. details) are using it as a critical element in their professional workflow. Support is crazy responsive. Just a few comments on that:

Sharing

Working simultaneously with other contributors has been great. The experience with viewers has certainly been better than the git/GitHub/edrawings, but not as good as I’ve hoped. I suspect familiarity and the breaking down of initial barriers such as improper permission settings will help.

Featurescript

Featurescript is the language Onshape uses to write it’s own features. They open it up so that users can write their own first-class features for use in the model tree.

Admittedly this is a pretty nerdy element, but it did let me create a measurement feature that helped me workaround that isn’t there yet.

Folders

Not a huge deal, but in the short time I’ve had access to it I’ve gotten used to keeping data sheets for components in the same Onshape folders as the CAD itself. Feels neat

Semantic cleanliness

Working in Onshape I get the feeling that there are a lot of CAD software engineers who were crazy excited to build something new. There are a bunch of examples of this but I think the extrude dialog is the best one.

Extrusion semantics

The Bad

Lag

Most of the time there is no issue. However sometimes it takes a few seconds for dialog boxes to close, which is awful. On balance it’s OK, but I’d love to see improvements on this.

The merge issue

Mentioned above. It was bad, but ultimately painless in my case and the support response was incredible. YMMV.

FEA

There are a few FEA tools on the Onshape store. I’m sure they have some capability, but the one I tried had an issue importing my master and so I jumped ship and used SimulationXpress on my SolidWorks seat for a basic FEA.

I’ll try out the options again when I have more time, but for now I’m jumping back into SolidWorks.

Bezier Curves

SolidWorks and Creo both have Bezier curves (SW calls them “Style Splines”, where Creo refers to them as having a “control polygon”).

Onshape doesn’t. It has has vanilla B-splines, which are fine, but less controllable.

Solidworks Bezier curves

Bezier curves (aka Style Splines) in SolidWorks.

The annoying

These are things that aren’t really a big deal, but I wish were better.

There are a few elements that I am sure I will have an opinion on, but haven’t put in enough time to make even a preliminary judgment.

The TBD

BOM

To date our development BOM has been managed in spreadsheets and we haven’t swayed much from that. I’m very interested in checking out some of the options in the Onshape store, including OpenBOM and an app that pipes to google sheets (where our dev BOM currently lives)

Release strategy

In relation to the BOM above, the ability to keep track of which part is released when, what version of the master is being piped to a given part, etc. is a critical ingredient of sanity during production release. This certainly is possible with Onshape, but I will have more detailed thoughts later.

Sharing/Viewing

Similar to the release strategy, I think this will be better discussed after we’ve gone through some more cycles.

FEA and Rendering

There are a handful of apps in the OnShape store that might be good. Will have to check them out.

Large databases

Our database is relatively small (we make wearables, not space shuttles), so it’s possible that Onshape may become unwieldy for large projects. I don’t think I’ll be addressing this any time soon, but I want to call it out lest someone from Boeing advocates a switch.

My team currently uses Microsoft Surface Book with a Performance Base i7, 512GB SSD, 16GB RAM, NVIDIA GeForce GTX 965M 2GB GDDR5. These have a detachable display with an integrated graphics card in the tablet section, and a higher performance graphics card in the the base (keyboard) section.

You can set various programs to default to use either graphics card. In the example below I set Firefox to use the performance graphics card and Chrome to use the integrated graphics.

The performance (as measured by cad.onshape.com/check) is nearly an order of magnitude using the higher performing graphics card. This makes a world of difference in graphic responsiveness (though saving features can still seem laggy on a slow WiFi connection)

onshape firefox vs chrome

Clearly Onshape isn’t without it’s warts, but it’s excellent data management & sharing features, adequate geometric ability, crisp feel, and open approach (feature script!) makes it a great fit for the kind of work we do.