3D Printing Software

Roger Cheng

FormLabs Form 1+ OpenFL API Connection

I had a longshot idea to revive the galvanometer control of a broken FormLabs Form 1+ resin laser 3D printer. It didn’t work and galvanometer remains broken. Because the printer also had a broken resin tray tilt motor and other smaller problems, I wasn’t trying to get it to print again. What I had in mind was to repurpose the optical core into a laser light show machine.

This was made possible because FormLabs opened up the Form 1/1+ for experimentation after they stopped supporting the hardware. Since they are no longer responsible if anything goes wrong, they freed the hardware for people to mess around with. This consisted of a special build of the PreForm software, which will flash a special (final?) edition of firmware. This firmware is willing to talk to a PC beyond accepting print jobs from PreForm. To make this communication easier, they released a Python library. All of these were posted on a GitHub repository under their “OpenFL” umbrella.

I really appreciate the fact FormLabs did this, exposing an API to control hardware independently of PreForm print jobs make it possible to do things completely outside the realm of printing. One of their examples turn the Z-axis stepper motor into a single-channel MIDI instrument making buzzy electromechanical music. The API also allows control of laser power and galvanometer position, which lead to my idea of turning the printer into a laser light show machine.

But first, I had to get it up and running. The first problem is that, as a seven-year-old Python library, it was written for Python 2 which is now discontinued. To create a backwards compatible Python environment, I used Miniconda to create a Python 2 environment called “openfl”

conda create --name openfl python=2

Following instructions in OpenFL repository I setup and installed Python dependencies. It allowed me to load OpenFL library but I immediately ran into an error.

Python 2.7.18 |Anaconda, Inc.| (default, Apr 23 2020, 17:26:54) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from OpenFL import Printer as P
>>> p = P.Printer()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "OpenFL\Printer.py", line 62, in __init__
    self.dev = usb.core.find(idVendor=self.VID, idProduct=self.PID)
  File "C:\Users\me\miniconda3\envs\openfl\lib\site-packages\usb\core.py", line 1297, in find
    raise NoBackendError('No backend available')
usb.core.NoBackendError: No backend available
>>>

This “No backend available” error came from pyusb library, complaining about a missing dependency outside of Python: we need a compatible USB driver installed. Solving this error required the following chain of events:

  1. Read up on PyUSB at https://pyusb.github.io/pyusb/
  2. Which point me to LibUSB at https://libusb.info/
  3. Which pointed me to its Wiki for running on Windows at https://github.com/libusb/libusb/wiki/Windows#How_to_use_libusb_on_Windows
  4. Which recommended the Zadig utility at https://zadig.akeo.ie/

Zadig offered several options for USB drivers, I tried them in the order recommended by LibUSB.

  1. WinUSB (v6.1.7600.16385): nope, still got “No backend available” error
  2. libusb-win32 (v1.2.6.0): looks good!
Python 2.7.18 |Anaconda, Inc.| (default, Apr 23 2020, 17:26:54) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from OpenFL import Printer as P
>>> p = P.Printer()
>>> p.state()
<State.MACHINE_READY_TO_PRINT: 3>
>>>

I’m in! Now to poke around and see what I can do with the laser.

Roger Cheng

Onshape is Free For Makers, But They’re Less Eager To Say So Now

onshape_logo_mediumWhen I first discovered Onshape over two years ago, it was a novelty to see a capable CAD system run completely within my web browser. The technologies that made Onshape possible were still evolving at the time: on the client-side, web browsers had immature WebGL implementation that sometimes didn’t work, or worked unacceptably slowly. And on the server side, Onshape is an active participant in evolving AWS to work for them.

Now WebGL is a mature part of every popular web browser, including those at the heart of inexpensive Chromebooks. I’m old enough that the phrase “CAD Workstation” conjured up computer systems that cost as much as a car. With Onshape, a Chromebook can be a CAD workstation! Not a great one to be sure, but more than enough for curious learners to get started. (This page has more details on Onshape performance.)

This is why, when I started Sawppy the Rover, I switched from Fusion 360 to Onshape. Because I wanted Sawppy to be accessible to everyone, not just those who have a computer capable of Fusion 360. And I have continued to do so, not realizing another aspect of Onshape evolution had occurred.

This came up on my radar because of my super simple wire straightener project. I’ve shared simple tools before, but this one caught more attention than most thanks to a referral from Twitter (and another). I was surprised to see feedback in the theme of “I don’t have an Onshape account” and was surprised people felt it was a barrier.

When I first started using Onshape, their sign-on screen would direct people to a page where people could sign up for an account. On this screen, a free plan for makers and hobbyists was prominently displayed.

That has been removed, hence the confusion.

The free plan still exists, but it’s no longer on their “CAD Pricing” table and not mentioned in their “How to Compare Onshape Plans” guide. From the FAQ I inferred that it’s not even possible to sign up for a free plan directly, one would have to start a trial for the Professional plan, decline to pay, and be downgraded to the free plan. (I can’t test this hypothesis myself since I already have an established account on the free plan.)

I personally find this disappointing, but I’m not surprised. Onshape is a business and businesses have to be profitable or they’ll disappear. I’m a little afraid this might mean they’re working to phase out the free plan, but even in that case I hope they offer a subscription tier that’s priced reasonably for hobbyists on tight budgets.

Roger Cheng

Onshape In-Context Modeling For Phoebe’s Second Chassis

Digitally laying out major components of a project in 3D space is something I’ve done for many projects, from my FreeNAS Box, to Luggable PC, to Sawppy the Rover. Doing it again for to figure out a more compact layout for Phoebe’s second chassis wasn’t a big deal in itself. However, this time the exercise will have a much more direct impact, thanks to a relatively new feature in Onshape.

For my past exercises, once I had decided upon a layout I would take measurements of relative position and dimensions of spaces between them. I would then copy those numbers to new drawings and build parts from those drawings. This workflow is functional but feels silly. The layout information is in the computer, why can’t I use them back in the drawings for components?

I’m not sure what the answer is, but whatever they may be, they are no longer relevant: modern CAD software now offer the ability to take assemblies of parts and use information from the assembly in drawings. They go by various names. SolidWorks documentation refers to this as top-down design. Onshape calls their version in-context modeling. Whatever the name, it’s a system that allowed me to reverse my design process. In the first chassis, I built a simple plate and bolt parts on it as I went. Now with the help of in-context modeling, I’ve arranged all the components in a game of 3D puzzle before creating a chassis to deliver that arrangement.

Using in-context modeling, I don’t have to copy & paste dimensions and risk introducing errors in the process. I also have the option to move parts around my layout and have all design dimensions update automatically. That last part doesn’t work quite as well as advertised, though I’m not sure what’s fundamental problem and what are just minor bugs they’ll fix later. But it works well enough today for me to believe in-context modeling will have a role in all my future projects.

In Context Editing 2

(Cross-posted to Hackaday.io)

Roger Cheng

Phoebe’s Component Layout Is A 3D Jigsaw Puzzle

Phoebe’s first chassis was just a rough draft to get first hand exposure trying to get all the parts my TurtleBot variant needed to talk and work with each other. What that exposure taught me is I need to improve packaging space efficiency and create a much more compact robot. Only then could I satisfy the competing requirements of increasing ground clearance and lowering LIDAR sensor height.

To work on this puzzle in three dimensions, I started by holding parts up against each other. But I quickly ran out of hands to track all their related positions so I moved on to do it digitally. First I created 3D representations of the major parts. They didn’t have to be very detailed, just enough for me to block out the space they’ll need. Then they were all imported into a single Onshape assembly so I could explore how to fit them together.

In Context Editing

I turned the caster forward, as if the robot was travelling backwards, because that position represents the maximum amount of space it needs. My battery is the heaviest single component, so for best balance it needs to be mounted somewhere between the drive wheels and the caster. Relative to the first draft chassis, the battery was rotated to allow more ground clearance, but that also pushed the caster a little further back than before.

In the first chassis, electronic components like the Roboclaw motor controller and Raspberry Pi 3 were sandwiched above the motors and below the LIDAR. They’ve been moved to the front in order to lower LIDAR height. The lowest point of the LIDAR module – its spinning motor – was dropped in between wheel drive motors. This required turning the LIDAR 180 degrees – what used to be “front” is now “back” – but we should be able to describe that frame of reference by updating its corresponding ROS component transform.

(Cross-posted to Hackaday.io)

Roger Cheng

Using OctoPi To Avoid Monoprice Maker Select (Wanhao Duplicator i3) Usability Issues

The Monoprice Maker Select 3D printer is a re-branded Wanhao Duplicator i3. Which is itself part of a lineage of 3D printers that can trace their ancestry to the Prusa i3. Josef Prusa invented an effective design that has seen wide adoption, including manufacturers who are very inventive at cutting cost. Now a serviceable 3D printer can be purchased for iPad money. Or even Chromebook money if buying used/refurbished.

That’s not to say everything is great. There are some definite trade-offs made to hit this price point, and the customer sitting in these cheap seats has to sacrifice some nice features of more polished printers.

One infuriating usability problem is the microSD card slot. It is on the side of the control box whose sheet metal enclosure has an over sized slot to make sure manufacturing tolerance issues won’t end up covering the card slot. Great for cheap manufacturing, but it also means is there’s plenty of room for a card to enter the sheet metal opening and miss the microSD slot entirely. If the user fingers release the card, thinking it was in the slot, the card drops into the enclosure and the user has to open the enclosure to retrieve the card.

Another usability issue is the control panel. First, the LCD is a primitive dot matrix display with very limited viewing angle. Second, it doesn’t always respond even when tactile feedback was returned by its control knob. It’s not clear if this is a problem in the knob (tactile feedback without electrical connection) or if it’s a software issue, but it is annoying either way.

One way to avoid both usability issues is to control the printer using OctoPi, the prebuilt image to run OctoPrint on a Raspberry Pi. The web-based interface eliminates the need to deal with the knob and LCD UI. And OctoPi’s G-Code upload/management functionality means never having to use that microSD slot.

Personally, I didn’t feel OctoPi delivered a lot of value for my Monoprice Maker Ultimate (Wanhao Duplicator i6) because the Ultimate had a well placed memory card slot for full SD cards and a decent control panel. In the case of the Maker Select, though, an OctoPi has saved a lot of aggravation.
OctoPiUI

Roger Cheng

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.

 

Roger Cheng

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

 

 

 

Roger Cheng

Fusion 360 Foundational Concepts Tutorial

foundational-concepts-iconI went back into Autodesk’s Fusion 360 learning resources for a refresher and to set myself up to learn the Fusion 360 CAM modules. The last time I went through the tutorials, I had skipped the CAM functionality because I had no machine tools and were not likely to get time on anybody else’s machinery. Now that I might be able to access Tux-Lab fabrication machinery, I wanted to make sure I won’t break the machine from doing anything stupid in Fusion 360.

Before I got to CAM, though, the “Foundational Concepts” section caught my attention. I either didn’t see it the last time or it made no impression on me at the time. I went through the set of short videos and they were surprisingly informative. Most tutorials for Fusion 360 (and most other software packages in general) are happy to tell users how to accomplish their tasks. This is a slightly different twist – the foundation concepts talk about why Fusion 360 is the way it is. About how they tried to restructure a CAD package for the cloud-based future, about how they restructured the workflow to take advantage of today’s level of computation power at our fingertips, so on and so forth.

I come from a software engineering background and I’m all too aware of the fact that the end user typically has no idea what the software developer had intended as they built the piece of software. It can be argued that the end user doesn’t need to know anything about the intent if the software is sufficiently well-designed. But for something complex like a CAD package, I believe there is value in learning the motivation behind the design.

And even if the user doesn’t need to know, sometimes the user is curious and wants to know. I appreciate the Fusion 360 user education team for putting this information out there available for those who want to know.

Roger Cheng

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.
Roger Cheng

OpenSCAD for Motion Visualization

Now that I’ve climbed the initial learning curve for OpenSCAD, it’s time to start working towards my goal for doing this: I want to visualize arbitrary motion between components as a rough draft to see how things move in virtual space.

This is not an unique capability in CAD packages. Both Fusion 360 and Onshape have ability to define object hierarchies and visualize their motion. However, they are both focused on the assemblies that have been mechanically defined in CAD. If I wanted to visualize a  hinge-like motion between two objects, I first need to build that hinge in CAD or the software would “helpfully” tell me I’m trying to perform an impossible motion in my design.

In contrast, OpenSCAD does not care. I can place a rotate() operation anywhere I want and it won’t care if there’s no hinge in the design. It is happy to let me rotate about an arbitrary point in 3D space with no hardware around it. This makes OpenSCAD ideal for trying out how wild ideas would (or would not) work in virtual space, before getting down to the nitty-gritty about how to build the mechanisms to implement those wild ideas.

This means some cool-looking ideas would turn out to be impossible to implement, but that’s OK. I wanted something with a lot more freedom than I can get in the CAD packages that limit what I can do for (in their view) my own protection.

But that’s still in the future. For now I’m still climbing the learning curve of moving objects around in OpenSCAD in a way that ties into the built-in animation capability and generating animated GIF to illustrate concepts.

As a learning exercise, I’ve re-implemented the motion of the Luggable PC hinge. Thanks to OpenSCAD flexibility, I didn’t have to spend time building the hinge before I move it!

lug3

Roger Cheng

Hello OpenSCAD! You remind me of an old friend…

HelloOpenSCADOpenSCAD is a very popular 3D modeling tool in the 3D printing community. Many of the projects available to print on Thingiverse were generated from OpenSCAD. This is most obvious when authors uploaded their .scad files for sharing with the community, but also visible as a core pillar of the “customizable things” section. The customization capability is made possible by variables the author made adjustable in OpenSCAD.

I started designing for 3D printing with the GUI CAD tools, Onshape and Fusion360, so the text-based approach of OpenSCAD seemed strange and foreign at first glance. The official OpenSCAD web site documentation pointed to several tutorials. Not knowing the comparative advantage of one versus another, I just clicked on the first in the list How to use OpenSCAD. It linked to several other tutorials, the most notable one being Know only 10 things to be dangerous in OpenSCAD as having the most compact words-to-content ratio.

I had initially approached it as “Boy it’s going to be hard to completely change my thinking” but as I got along in the tutorial I realized things didn’t feel as foreign as I thought it might be. Digging through musty memories, I realized I had encountered this type of 3D modeling (CSG or Constructive Solid Geometry) before many years ago in the form of POV-Ray. Back in the days when a 20-megahertz 386 was a pretty speedy CPU, and the floating point processor wasn’t a standard part of every PC. I had to upgrade my computer with the purchase of a 387 math co-processor in order to render my POV-Ray projects at a reasonable speed.

Editing CSG files for rendering in POV-Ray was my first exposure to 3D computer graphics, and I chose it because it was free. I couldn’t afford GUI graphics software (the flagship at the time was Autodesk 3D Studio) so I started with the basics and I learned a lot that way. In time, I might appreciate the straightforward simplicity of OpenSCAD in the same way.

Roger Cheng

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.

Roger Cheng

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.

Roger Cheng

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.

Roger Cheng

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.

Roger Cheng

Udemy: Product Design in Autodesk Fusion 360

udemylogoTalking with some people at the Hackaday meet taught me that there are some real fans of Autodesk Fusion 360. It was already on my to-do list to evaluate the software, but the enthusiasm pushed it to the foreground.

The first frustration is learning the software. All the resources I found are in the form of tutorial videos. I personally prefer information in written text format, but I’ll watch the videos if I have no alternatives. The videos on Autodesk’s own site is built using a Flash-based video system. I avoid Flash when I can, so as an alternative I chose the udemy.com course titled Product Design in Autodesk Fusion 360 from idea to prototype.

The quality of the course was uneven: different sections in the course were recorded by different instructors each with their own style. Fortunately, the introductory and starting sections about content creation were pretty good, teaching me Fusion 360 basics and then how to create a design. (Sections 1 through 3)

Where these sections fell short was teaching me how to fix problems. That is, beyond hitting Control+Z immediately after a mistake. I know I’ll change my mind on certain design decisions and need to adjust the file later. The class didn’t spend much time over the editing tools and I felt this gap would prove to be a hindrance to my productivity.

Section 4: Rendering, animation, and drawings were very perfunctory and barely enough to get me started. If I actually want to make use of these features, I’ll need to find additional education before I can be proficient.

Section 5: Computer Aided manufacturing(CAM) assumed the student is already familiar with machining and wanted an overview on how to use their existing knowledge inside the Fusion 360 UI. If the student didn’t already know CAM, the section would make no sense.

I think I picked up enough basics for me to start poking around on my own to fill in gaps in my knowledge, so it worked well enough as a brief overview. I’m just a bit disappointed because my expectations were higher.

Roger Cheng

Simplify3D

simplify3d_logo_rUp until this point I used Cura 2.x, which met all of my STL to G-code slicing needs. But the caliper battery tray project demanded more.

I needed to print supports for the battery tray project components because the shape could not be laid flat on the print bed. Cura, like all decent slicer software, could generate supports. However, the Cura-generated supports are a take-it-or-leave-it affair: There is no way to edit the support structure. This is a problem when the structure ends up in an inconvenient place that is dimensional critical and difficult to clean up. Such was the case for one of the fastener holes.

After a few failed attempts due to inconveniently located support structures, I looked for a solution online. The common answer seems to be to leave Cura behind and switch to Simplify3D, so I did. I immediately dove into the part that motivated the purchase: editing supports.

s3dsupports
When tearing your hair out, the Manual Placement feature alone makes it worth the $150 price.

I was very happy to see it worked as advertised! I was able to add and remove supports as needed to make sure I got support where I needed, and avoided supports where the shape is critical and I couldn’t afford to have support material in there.

Another benefit of Simplify3D is the G-code visualization component. Cura had rudimentary visualization but I was never happy with it. My workaround had been to upload the .gcode file to http://gcode.ws for visualization, but going to yet another web site was a huge hassle in my workflow.

Sadly, Simplify3D was not all win. The print rafts generated by Cura worked out much better for my printer than the rafts generated by Simplify3D. Fiddling with raft parameters were to no avail: Cura rafts were much more helpful and peeled off cleaner than those from Simplify3D.

You win some, you lose some, such is the story of an evolving field like 3D printing.

Roger Cheng

Geometry Fun with Onshape Loft

300x170Further exploring Onshape’s geometry tools, I started playing with the loft command. This command allows me to select two 2D shapes and Onshape will calculate a volume that spans the two shapes.

It is fairly limited in what it can extrapolate, the shapes need to be fairly similar for this to work. Circle to oval? OK. Circle to polygon? Problems.

I’m sure the feature is only designed to handle things like generate an adapter part to mate one shape to another. It’s not for artistic things. That is more in the domain of a 3D sculpting tool and not CAD.

Still, there’s some room for entertainment, especially since these lofted volumes can then be fed into the boolean operations tool. The picture above is one such result. The exterior of the shape is a square lofted with an identical square that has been rotated 45 degrees. The interior is a very similar operation, but the squares were rotated in the opposite direction. Subtracting one from the other results in the cut-out shape above. The corner of the inner square, rising in an opposite direction, cuts the edge of the outer square.

Not that this is functional or useful in any way, but it is a fun exploration of three dimensional geometries.

loft

Roger Cheng

3D Printed Planetary Gear

Planetary Gear ToyAfter getting the 3D printer settings dialed in, successfully printing small test objects, I decided to tackle a real project. Move beyond printing static shapes and make a multi-part machine.

In hindsight, that was too big of a step, but I didn’t know until I tried it.

The project of choice was to make a simple planetary gear toy. Such objects are in no short supply on Thingiverse, of course, with a huge spectrum of size and complexity. But I wanted to practice making my own end-to-end.

Why planetary gear? Because of all the basic mechanical machines out there, I was never able to build a planetary gear in LEGO. There was never a LEGO Technic inside-out gear for the annular ring in a planetary gear set.

The first obstacle was actually a surprise – I couldn’t find the gear tool in Onshape. I had expected the basic involute gear to be somewhere in the standard toolbox and found nothing in the documentation.

A search on Onshape forums determined that I was not blind – the feature is absent from the basic set. It was, however, available as a “custom feature” published as a public document by an Onshape staffer. Onshape has its own internal programming language called FeatureScript and a spur gear generator was available as a demo of the language. I’ll have to look at FeatureScript in more depth later, but for now I have my gear tool.

The first print didn’t work, as expected. The parts didn’t fit together at all. This is the point where I had to face the fact consumer 3D printers are still far short of professional machining tools in terms of precision. In my specific case, the extruded plastic “squished out” sideways so every dimension along the horizontal (X&Y) axis are too big.

I assumed this wasn’t a new problem so started researching. Eventually I found that some slicer software have the ability to compensate for this particular trait of FDM printers. Cura called theirs the “Horizontal Expansion” parameter. Unfortunately, I had to abandon the Cura 15.04.2 I had been using and restart with Cura 2.1.2 in order to gain that capability.

With some tweaking of the horizontal expansion parameter, I got my printed planetary gear to mesh and turn like I wanted. At least I found success! But that still took way more time and effort than I had originally bargained for.

Moral of the story: Building small scale precision machinery is beyond easy reach of consumer 3D printers. I might come back to this again, but in the immediate future, I’ll stick with simpler shapes and build 3D printing experience that way.

In the meantime, my project is a public document on Onshape. Search for its title “Planetary Gear Toy.”

planetaryruler

Roger Cheng

Onshape Notes

onshape_logo_mediumWhen getting started with 3D printing, it’s easy enough to pull some nifty things from sites like Thingiverse and print them out. But I quickly got bored of that – the reason I got a 3D printer is to turn ideas in my head into reality, not somebody else’s ideas.

There are lots of options to create digital 3D objects, the one I started with is Onshape. It is a completely web-based CAD system with the ambition to take on the big professional engineering CAD systems. I chose it mainly because it ties into another of my interests: learning how web-based applications are replacing traditional desktop applications. CAD has been one of the cornerstones of expensive desktop machines crunching numbers as professional engineering workstations. Can Onshape (& peers) transform that world? I don’t know, but I want to see how well it works (or, potentially, not) first hand while having fun.

Fortunately they’re very friendly to hobbyists like myself:

  1. Their subscription plan has a free tier specifically for hobbyists and makers. The storage space is limited and you can only keep a few things private. So the scale and complexity of free projects are restricted, but all Onshape functionality is identical. This was important because a few other CAD solutions restrict functionality at the lower cost tiers… functionality such as export to STL. If I can’t export to 3D print, that would defeat the point of the exercise.
  2. There is an extensive self-training resources section. A free service isn’t much good if I have to fork out a fortune to learn how to use it. With Onshape, I don’t have to.
  3. There is an online community around the tool. Onshape is new and still has quirks and idiosyncrasies. (Well, to be fair, all software do.) With the help of other like minded people on the forums, I don’t have to reinvent the wheel and solve all problems by myself.

After spending a few days in the training section, I was able to create simple things in Onshape. As I started getting fancier, I started running into problems that need digging into the documentation and/or the online forums. As I learn more about Onshape I’m increasingly impressed with what they’ve done and what they’re planning to do.

It’s a fun and functional tool. Highly recommended.