Overview: Fusion 360 vs. Onshape Scripting

My fascination with gears led me to the scripting mechanism in both Fusion 360 and Onshape. Both CAD packages offer only minimal gear generation capabilities, and not even built-in to the main software: Spur gear generation was given in the form of an external add-in. This meant they are ideal introductory entry points to examine the different design philosophies.

The Onshape team invented their own scripting language called FeatureScript. It has some superficial similarities with C-style languages which helps a software developer get up and running more quickly on the new language. The code libraries are designed specifically around designing parts within a Onshape feature studio.

In contrast, Autodesk did not try to invent a new language. Instead, they decided to support multiple existing languages and let the user choose the one that best suits their purpose. C++ or Python. (Fusion 360 used to also support JavaScript, but support has been deprecated.)

Readability: Because FeatureScript was designed specifically for its task, the code is much more direct and readable. All API are designed to fit with FeatureScript because that’s the only language supported. Fusion 360 C++/Python code must call into the Autodesk library code which had to be adapted to be usable across languages. Advantage: Onshape.

Performance: C++ can be compiled to native code and executed on the local computer. For small tasks, this will be the fastest possible option. Python code running locally wouldn’t be quite as fast, but unlike FeatureScript, it does not have to deal with network latency. Advantage: Fusion 360

Security: FeatureScript executes in a secure sandbox on Onshape server, and thus limited in risk for exploitation by bad actors. In contrast, a native C++ binary can easily host hostile code. Python is slightly better in this regard, but it’s not clear how much effort (if any) Fusion 360 puts into running Python securely. Advantage: Onshape

Development: Like the rest of Onshape, all work with FeatureScript takes place within the user’s web browser window. If the developer does not like the Onshape FeatureScript editor, they are unfortunately stuck. In contrast, Fusion 360 presents many options. C++ development takes place on a platform-appropriate IDE (Visual Studio for Windows, Xcode for MacOS) and for Python the Spyder IDE is provided. Advantage: Fusion 360

Evolution: FeatureScript is owned by Onshape and any future evolution is fully under Onshape control. Since all FeatureScript written by users are stored on Onshape servers, they can validate any future changes for compatibility. In contrast, Autodesk owns neither C++ nor Python and could not direct future evolution. And since Autodesk does not host the plug-in code, they have no visibility on breaks in compatibility. Lastly, as history has shown, Autodesk can choose to abandon a language (JavaScript) and all the users on it. Advantage: Onshape

Capability: FeatureScript is constrained to feature creation in a parts studio. Autodesk API is currently roughly similar, focused on the model designer portion of Fusion 360, but they are starting to branch out. As of this writing they’ve just started rolling out some basic scripting capabilities for the CAM module and stated intention to do more. Advantage: Fusion 360


Python LogoFor the immediate future, I intend to focus on Fusion 360 scripting via Python. I’ve wanted to become more proficient in Python, and this would be a good way to look at Python through a lens entirely different from writing Qt code on a Raspberry Pi. I also have ambition to write Fusion 360 plug-in that leverages external libraries to provide novel services, and that’s not possible when stuck inside the FeatureScript sandbox. I will just have to keep a careful eye on the Python library imports in an effort to keep the security risks under control.

 

Fusion 360 and Onshape: Spur Gears via Scripts

I’ve been learning Onshape and Fusion 360 as they are two of the cloud-based CAD solutions with a subscription tier that’s free for me. They each have their strengths and weaknesses and it’s always interesting to compare and contrast between them.

One item they share that I found surprising is that neither of them has built-in capability to add gears into the mechanical design. I’ve always thought of gears as a critical part of any nontrivial machinery. So I had expected to find a significant section of the CAD package to be devoted to creating various types of gears for different applications, simulating and analyzing their suitability to the task, but there was nothing.

For basic projects, a simple spur gear would suffice. Thankfully, both companies have heard the user requests and made simple spur gear creation available as an add-in created with their own respective scripting mechanism.

Extending Onshape requires learning to write code in their custom language FeatureScript. A member of the Onshape team used it to create the spur gear script and made it available in the public documents library. One downside of this approach is the fact that (1) Onshape users needs to make a copy of a public document before they could use it for their own purposes, and (2) all documents created with the free subscription tier of Onshape are public. These two factors combined means many, many copies of the spur gear script in the public documents library. Correction: Custom FeatureScript can be added to the toolbar without making a copy. Thanks [FS] for the comment!

OnShape Spur Gear

Fusion 360 did not declare their own scripting language. They expose their extension API to two languages: C++ for the high-performance native code crowd, and the Python interpreted scripting language for the less performance-focused audience. They used to also support JavaScript, but as of July 2017 they have moved that into maintenance mode due to lack of usage.

The spur gear script is part of the sample script library installed alongside Fusion 360, so I didn’t have to find a separate download nor was copying of public document necessary. They presented it in both C++ and Python format. I found the Python version in the “Scripts and Add-ins” menu and clicked “Run”.

F360 Script Addin

Onshape and Fusion 360’s spur gear scripts present their gear parameters in slightly different formats, but both should suffice for simple projects. If I want to do something more complex, I will have to dive into coding my own extension script.

I’ve wanted to learn more about what is and isn’t possible in an extension script anyway, so… challenge accepted!

F360 Spur Gear

 

 

 

Fusion 360 vs. Onshape: Raspberry Pi

raspberry-pi-logoAnd now for something completely silly: let’s look at how our two competing hobbyist-friendly CAD offerings fare on the hobbyist-friendly single-board computer, the Raspberry Pi.

(Spoiler: both failed.)

Raspberry Pi

I have on hand the Raspberry Pi 3 Model B. Featuring a far more powerful CPU than the original Pi which finally made the platform usable for basic computing tasks.

When the Raspberry Pi foundation updated its Raspbian operating system with PIXEL, they switched the default web browser from Epiphany to Chromium, the open-source fork of Google’s Chrome browser. Bringing in a mainstream HTML engine resulted in far superior compatibility with a wider range of web sites, supporting many of the latest web standards, including WebGL which is what we’ll be playing with today.

Autodesk Fusion 360

Fusion 360 is a native desktop application compiled for Windows and MacOS, so we obviously couldn’t run that on the Pi. However, there is a web component: Fusion 360 projects can be shared on the Autodesk 360 collaboration service. From there, the CAD model can be viewed in a web browser via WebGL on non-Windows/MacOS platforms.

While such files can be viewed on a desktop machine running Ubuntu and Chromium, a Raspberry Pi 3 running Chromium is not up to the task. Only about half of the menu bar and navigation controls are rendered correctly, and in the area of the screen where the actual model data should be, we get only a few nonsensical rectangles.

Onshape

Before this experiment I had occasionally worked on my Onshape projects on my desktop running Ubuntu and Chromium, so I had thought the web-based Onshape would have an advantage in Raspberry Pi Chromium. It did, just not usefully so.

In contrast to A360’s partial menu UI rendering, all of Onshape’s menu UI elements rendered correctly. Unfortunately, the actual CAD model is absent in the Raspberry Pi Chromium environment as well. We get the “Loading…” circle and it was never replaced by the CAD model.

Conclusion

Sorry, everyone, you can’t build a web-based CAD workstation with a $35 Raspberry Pi 3.

You can, however, use these WebGL sites as a stress test of the Raspberry Pi. I had three different ways of powering my Pi and this experiment proved enlightening.

  1. A Belkin-branded 12V to 5V USB power adapter: This one delivered good steady voltage at light load, but when the workload spiked to 100% the voltage dropped low enough for the Pi to brown out and reset.
  2. A cheap Harbor Freight 12V to 5V USB adapter: This one never delivered good voltage. Even at light load, the Pi would occasionally flash the low-voltage warning icon, but never low enough to trigger a reboot. When the workload spiked to 100%, the voltage is still poor but also never dropped enough to trigger a reset. Hurray for consistent mediocrity!
  3. An wall outlet AC to 5V DC power unit (specifically advertised to support the Raspberry Pi) worked as advertised – no low-voltage warnings and no resets.

Fusion 360 vs. Onshape: Multiple Views

Advantage: Onshape.

When working on a CAD project, the majority of my time is spent focused on a single view of my subject. But when it comes to align parts into an assembly, it is very useful to have multiple views, and this is where Fusion 360 falls behind Onshape.

Fusion 360 can toggle between the standard single-view mode and a quad-view mode. In quad-view mode, the window starts with four equal-sized views and the user can adjust the relative sizes within the window.

F360MultiView

This is a bare-bones baseline level of functionality. I can work with it, but I’m not happy with it. Onshape does it better.

Onshape takes advantage of the fact it runs in a browser. You can have multiple browser windows open on the same Onshape project, and each window can be a different view. Onshape infrastructure keeps all the windows in sync – any change made in one view is immediately reflected in all the others. Want four views? Open four windows. Want 6 views? (top/bottom/left/right/front/back) Open six windows.

And since these Onshape views are all separate windows, they can be placed on different monitors to build a great multi-monitor workspace. Fusion 360 is limited to a single window. Trying to use Fusion 360 across multiple monitors means manually scaling the application window across them. Toolbars get cut in half, resolution doesn’t match, problems left and right. It is not ideal.

What about opening multiple instances of Fusion 360, one for each monitor? It turns out that doesn’t work because the instances are unaware of each other. Change made in one instance is not reflected in the others until the user hits “Save” in one instance and “Reload” in all the other open instances.

The obvious conclusion is that Fusion 360 works best on a single high-resolution display instead of multiple screens. Sadly this is also false. As mentioned in my first Fusion 360 vs. Onshape comparison, Fusion 360 does not scale to high-resolution displays (4K, Retina, etc.) whereas Onshape takes advantage of the fact browser makers have long since handled the problem of scaling for high resolution.

Since the time of my first comparison Autodesk knowledge base published a workaround for running Fusion 360 on high-resolution displays. With these workarounds, Fusion 360 now runs poorly at 4K, which I guess is an improvement over not running at all.

With more multi-view options, including multi-monitor, plus superior support for high-resolution displays, Onshape handily wins this comparison, and they know it.

Fusion 360 vs Onshape, Round 2

fusion-360-logo31After using Autodesk Fusion 360 for a few weeks on the Luggable PC project, I’m getting more comfortable with it. Here are some thoughts and updates on a few items I mentioned in the “Round 1” post:

Constraints: Onshape has very good constraint notification and management. I know exactly when dimensions are fully constrained, and when things are over-constrained, I can see where the conflicts are. In the current default configuration for Autodesk Fusion 360, none of that is available.

However, if one goes into the Preferences menu and go to the feature preview section, there’s an option to turn on the work-in-progress support for constraint notification. This feature, while far from parity with Onshape’s excellent design, goes a long way to easing the pain.

A360 Preview

The complaint about over-constrained situation still applies: an error box is still all we get without any further details. But at least we get a color change to notify us when a feature is fully constrained, even if it isn’t completely reliable yet. Sometimes a feature’s color changes even though it hasn’t been fully constrained, and sometimes a color doesn’t change even when fully constrained. I am still occasionally surprised by how features would move unexpectedly later on in the workflow. Still, it is far better than nothing.

Advantage: Still Onshape, but by a much thinner margin.


Share Design PublicSharing: I was unhappy with the complex access control system, making it difficult to just share a design to everybody. But they have since added (or I just noticed) an option on every design in the project navigation tab: “Share Public Link”. It will generate a link to share publicly. This one is actually a step above Onshape, where I can choose whether the sharing link is a snapshot or a live link to the current state. Choose whether the design itself is downloadable.

And best of all, the design is visible without creating an Autodesk account. Unlike Onshape, where people have to have an Onshape account to access public documents.

Advantage: Fusion 360 takes the lead from Onshape because no account creation is required.


Offline: And now, a sour note. Since Fusion 360 is a native application, with an option to “Work Offline”, I had fully expected it to continue functioning when my internet connection failed. Unfortunately this was not the case! It appears that one needs to be online to enable offline work. I guess they need to download some information before the application can function offline. This make sense when the scenario is to prepare in the office before taking a computer on the road. But when the internet connection is unexpectedly severed, such preparation stage is not possible and things grind to a halt.

Advantage: Nobody. Inopportune network outage renders both useless.

Sheet Metal as Sign of Competition

onshape-sheetmetal-image02
Onshape sheet metal visualization

I’m personally comparing use of Onshape vs. Autodesk Fusion 360, seeing which one I prefer to use for my own projects. As I wrote earlier, each of them offer something I would miss if I started using the other exclusively.

In a close competition, everybody would learn from everybody else and the most important user features will propagate through all the offerings in the market. I wasn’t sure if the people behind Onshape and Autodesk Fusion 360 saw each other as competitors, but now I’m fairly confident that they do and are keeping an eye on each other.

The proof: Sheet metal.

a360-sheetmetal-shiftec
Autodesk Fusion 360 sheet metal preview

Onshape just unfolded their sheet metal feature. (“unfolded” their joke, not mine…) Autodesk said theirs is in a closed invite-only technology preview coming soon to all users. Such a similar feature introduced within a few weeks of each other might merely be a coincidence, but I doubt it. It certainly looks and sounds like they’re working to reach parity with each other’s features.

Additional proof: Constraints

Last time I wrote about the fact Onshape does a great job with constraints, letting the user know exactly where they stand in a way that Fusion 360 does not. At the time I didn’t know Fusion 360 has constraint visualization available as a “preview feature” that is turned off by default.

It is a good step forward for Fusion 360. As of the current preview, Onshape still holds a significant advantage in user friendliness, but the mere presence of the preview assured me that it’s on Autodesk radar and they’ll keep working away at it.

I like the progress I see so far. Competition making everybody better, and consumers win.

Fusion 360 vs. Onshape, Round 1

fusion-360-logo31Since completing the Udemy overview of Autodesk Fusion 360 a few days ago, I’ve started working on a project to get hands-on experience. Here are the items which made the strongest impressions after my first few days:

Advantage: Autodesk Fusion 360

UI Responsiveness: As an application executing locally, it is vastly more responsive to my actions than Onshape executing across the internet.

Integrated Assembly: In Onshape, parts are created in Parts Studios tabs and put together in a separate Assembly tabs. Parts need to have designated “mate connector” added to their designs before the assembly can occur. I never got the hang of this system. In contrast, every Design window in Fusion 360 can import parts from other designs without special entities like mate connectors.

Advantage: Onshape

Constraints: Onshape is really good about informing the user of constraints. Sketch entities are blue when they are under-constrained. When they are properly constrained, they turn black. When they are over-constrained, the conflicting constraints are all highlighted in red.

In contrast, Fusion 360 makes no distinction between under and properly constrained. My only indication an entity was under-constrained is long after the fact, when it would move unexpectedly in response to a change elsewhere. When over-constrained, a dialog box tells you the latest action causes over-constraining, but it doesn’t show you the conflicts so you’d have to go hunting for conflicting constraints yourself. This is a lot of lost time and a huge drain on productivity.

After a week of Fusion 360, this is the Onshape feature I miss the most.

UI scaling: Browser makers have lots of practice dealing with variable sized content on variable sized screens. Running Onshape in a browser window at 4K resolution was painless. In contrast, Fusion 360 scales poorly on a 4K screen, leaving many UI elements tiny and difficult to use.

Other Notes:

Sharing: Onshape free tier users are not allowed private documents, so every file is automatically shared with the world. Fusion 360 was designed for a world with designers and customers and clients, so it has a bunch of tools to manage access and permissions. In all that complication, they seemed to have forgotten to include a simple “share with the whole world” option.

Updates: Both of them update frequently. While it is easier to pick up an update in Onshape (refresh the browser) the Fusion 360 auto-update has been fairly seamless so far.