I’ve recently started exploring the world of additive machining by buying a Makerbot Cupcake CNC. There’s a lot to learn here but the community is making huge strides quickly. It’s fun to see new tools, techniques, and improvement popping up almost daily. In some cases, you can just ‘print out’ the new part and install it to upgrade your machine. How cool is that?
But after my experience with HeeksCNC, I find using the software an exercise in frustration. So I’m dreaming of a what the HeeksCNC approach would look like. Here’s my preliminary thoughts about that. *disclaimer: I’m still learning this stuff so I might really be off base. You’ve been warned.
Background:
The machine controller software (roughly corresponding to EMC) falls mostly into two camps. ReplicatorG (I love the URL) and RepRap Host Software. Popularity seems to correspond roughly with the Makerbot and RepRap communities respectively. Unlike EMC these tools have features for producing g-code as well.
Replicatorg uses an older version of Skeinforge and RepRap Host Software uses its own internal stuff. The bottom line is that, in theory, with either application, you can load an .stl file and ‘print’ it without relying on anything else. I know a lot less about RRHS but have read that many of its users don’t use the internal tool chain but instead use a stand alone version of Skeinforge to generate g-code and then use RRHS to print. Many RepG users, including me, do the same thing because the version of Skeinforge embedded in RepG is older.
So it would seem that Skeinforge is the 800lb gorilla to generate printable g-code. Here’s how it works.
The application is structured as a collection of python modules that each do a specific task. Each module has it’s own configuration file which has a .csv extension but doesn’t appear to be comma separated. There’s a Tk GUI for configuring the modules and they’re grouped by function. ‘Analyze’ has tools for visualizing the g-code ‘Craft’ has all the modules for producing it.
After launching the application, the user first makes some profile selections. Skeinforge has profiles for cutting, milling, winding, and extrusion. 3D printing is done with extrusion. Each of these profiles corresponds to a directory of configuration files and basically just sets a bunch of default values for each module. After the profile is selected, the user can override anything necessary. Saving the changes does not automatically create a new profile, it changes the existing profile. Yuck.
After selecting or modifying the profile, the user produces g-code by loading an .stl file. The application immediately calls the first module in the chain (Carve) which slices the .stl into layers and generates the g-code for the perimeter. Carve then calls the next module and passes the resulting g-code. This one revises the g-code to fill the interior before calling the next module. If a module has been disabled, it does nothing and just passes the code down the line.
There are modules to account for many different problems that can occur. Comb, for instance, avoids situations where the extruder head would move across open spaces leaving ‘stringers’ behind. Raft produces preliminary layers to adhere the print to the bed. Since the extruder is moving along the toolpath but is depositing material on both sides of it, Stretch handles the problem of bolt holes being smaller than they should be. Jitter makes the step up between layers happen at different places to avoid ‘seams’ . Lash adjusts g-code to account for backlash. Etc.
All this works pretty well and improvements to each module are happening all the time. The structure also allows 3rd party modules to be written and inserted into the chain.
Problems:
Unlike HeeksCNC, there’s no project file anywhere in sight. The .stl defines the ideal object. The g-code has all the instructions to make a specific thing on a specific machine. The configuration files are specific to a profile but the profile isn’t related to a part. There’s nothing like the collection of operations that the CAM operator would select and fine tune. This is a big deal because there’s a HUGE amount of tuning that goes into printing an object. Objects with thin walls need very different print characteristics. Tall objects need a much different raft to hold them in place. Large objects may need a sparser in-fill to speed up the print time and reduce the amount of plastic consumed or might need dense in-fill to be strong.
What would a *great* HeeksCNC Skeinforge integration look like?
1) First, since it’s in HeeksCAD, it would have a project structure to hold all the meta infomation about which object, which machine, which print characteristics were talking about. Kinda get that one for free just cuz it’s HeeksCAD.
2) It would handle the conversion of Heeks objects to .stl transparently in the background. I’d like to design my object, select it and add a print operation. I shouldn’t need to export it to .stl and import it into something else. It should also be smart enough to let me design multiple parts in one file but just ‘print’ one at a time.
3) Printing should respect a related coordinate system. I might need to rotate an object to put a particular face ‘down’ on the bed. I should be able to do this by associating a coordinate system without having to rotate the object in the global. Come to think of it, that would be a nice feature in HeeksCNC for other operations too.
4) A print operation would have a property tree that includes nodes for each skeinforge module. Opening the node would allow the module to be configured, or disabled. Selecting a profile for the top level operation would enable or disable and configure the individual modules according to the profile.
5) All this meta information would be stored in the project and would not overwrite the default profiles.
6) Less important but really nice to have, would be the ability to launch the skeinforge analyze tool Skeinview. This tool color codes the backtrace and allows inspection of the toolpath layer by layer. Very handy to understand exactly what’s happening in the middle of a printed object.