Data Driven Features

FeatureScript is one of the defining features of Onshape that make it stand out from the rest of the CAD industry. Unlike macros, Onshape custom features are fully parametric. Updating upstream features in the tree ripple down through the rest of the design. This ensures that custom features seamlessly integrate into design workflows.

An opportunity this opens up is for data-driven features. Features driven by calculations rather than human input. In traditional desktop CAD, driving a design through data using something like a macro was possible - but potentially laborious. The real struggle comes from changes to the data. If something changes in a macro based process, typically it requires starting again from the beginning. FeatureScript doesn't have this issue. 

I recently came across this video from youtuber Engineezy, who was trying to create a mechanism that could write letters. The mechanism uses two cams to drive a linkage that draws a specific path. The shape of the path defines the profile of the two cams. Not something easy to design. His solution was to painstakingly measure sample points, and use a spread sheet to calculate the cam profile. It might be an acceptable process once, but any changes or expansion of scope can quickly add up. 

But there's a better way! A FeatureScript can do all of the path sampling, calculations, and cam profile generation in a single step. Being fully parametric, the feature can also be configured, or have the target sketch swapped out in an instant. The simplicity in generation gives us the power to tweak and make changes to the design without causing hours of work to vanish. We could easily change the mechanism sizing or shape, positions of cams, or modify our target path.

In the image below, I am showing how the feature can map the "E" shape to the endpoint of the arms. That endpoint then maps to a polar coordinate around the cam shaft to generate the cam profile.

The below video isn't even sped up. Changing out the shape, recalculating the sample points, configuring the model, or changing any other driving parameter - results in instantaneous output.

You must be asking, is there a catch? Was this weeks of effort to automate a few hours of tedium? The opposite, this sample feature took less than 2 hours. I wouldn't consider it production ready in that time frame, but it was enough for a proof of concept. I'd expect the manual workflow to take almost the same amount of time for the first case, but every subsequent case digs a deeper hole into loss productivity. Code is great at repetitive calculation, humans are not.

When I hear "We're too busy to automate" - my response is that a lack of automation is why you're busy.