Bonus video
The trickiest part was separating everything from cutting mat. Adding few more layers of tape, so that blade cuts only top layers helped.
Open the video in youtube if embedded version keeps buffering.
CAD
Hardware was design using FreeCad 0.20 , no assembly workbenches. With most of the parts being axis aligned and no complex swinging motion using a hierarchy of parts/transformation was sufficient.
Firmware choice
Controller board is using Marlin firmware and g-code. Why Marlin and g-code not some other firmware and hpgl or gpgl?
Due to the popularity of 3d printers there is wide variety controller boards for them available. Chose Marlin mainly because it supports wide range of controller boards and is actively maintained. G-code usage is mostly result of that. One thing that's slightly less convenient compared to others is that configuration is mostly done using compile time macros.
Klipper would check many of the same boxes as Marlin. For now chose against it, because having the controller board+RPi seemed like slightly larger complexity and at the time of source parts getting a Raspbery Pi was a problematic. Also with Klipper architecture it seemed somewhat wasteful to have more feature rich controller board, since with clipper some of it would be shifted to the RPi (or the alternative SBC).
RepRap firmware also seems nice, but the developers are focusing mainly focusing on their own high end Duet3d boards. While the support for some other boards in theory exists, they are not listed in the official reprap firmware website. Compatible boards link leads directly to Duet3d product page. I wasn't quite ready to buy in the ecosystem of their boards or running it on a board with unofficial support. I appreciate that some people where able to make a company around an open source project, even when any community contributions are almost non existing (more so than typical open source project)
Original Grbl project at this point seems more or less dead. But there a couple of promising forks each with slightly different goals and target hardware in mind.
Thinking about all this led me into the rabbit hole of looking into what CNC and 3d printer firmware are out there and what is still being maintained. After cloning few dozen firmware repositories I managed to create this. I don't promise that it is accurate or exhaustive, especially early reprap project firmware history in 2008-2010 was somewhat messy. Due to small size it's hard to distinguish what's a new version, unique fork, or insignificant manufacturers modifications. Mach3 included only because it's early versions where supposedly derived from the same government funded public domain project that LinuxCNC also used.
(Click to make bigger)
Marlin
Marlin is the firmware running on controller board. It is primarily targeted for 3d printers, but like most such projects it has some functionality for other kind of CNC devices.
For the most part didn't have to do too much customization. Just disabled unused 3d printer functionality and configured 2 servos. Had to make some patches to fix compilation with only 2 axis enabled (no Z axis). Might be interesting too look into whether some of the spindle/laser code could be reused for the tool activation (lifting/raising), but for now I am just using M280 gcode directly.
- Fix compilation without z #24858 , thanks thinkyhead for cleaning up and extending the changes
- (not upstreamed yet) more no Z compilation fixes when backlash compensation feature is enabled
- (potential future changes) Would be nice to dynamically change servo wait time based on movement angle. Currently waiting for servo movements takes significant portion of time. Reduce wait time when servo moves just enough to barely lift above paper, would help.
InkCut
Inkcut is the software taking in SVG and converting to something that a plotter or vinyl cutter can understand (hpgl, gpgl or gcode) . It can be used either as standalone software or an inkscape plugin. But the plugin barely does anything, it mostly just opens the current svg in the standalone inkcut program thus saving you one or two clicks.
Inkcut required a bit more work to get in state where I am happy to use it.
- make gcode output more configurable #348 . Allow configuring decimal places (required for metric machines using coordinates in millimeters) . Allow customizing gcode for lifting/lowering pen. Allow overriding startup sequences.
- minor UI number fix #350
- Fix some curve segments not being outputted #353
- #356 Improve path order optimization: use faster data structure for the greedy shortest path approach, add hilbert curve and Z curve path orders.
- #359 #364 Improve device creation/copying. Helps for having different presets for pen / drag knife.
- Run the unit tests on every commit using GHA (previously used Travis wasn't properly working anymore)
- (not upstreamed yet) #362 Filter improvements: new filter for joining lines and removing short gaps, new filter for removing short lines, repeat filter (useful cutting thicker material), more predictable filter order, fix blade offset curves for angles that aren't 90°.
- (potential future changes) handling of scale/output units needs to improved. Currently it happens too early in the processing pipeline making it difficulty to correctly handle units in some parts of code.
gcode sender
At the moment I am using pronterface for sending gcode to device. In theory could do it directly from Inkcut, but I don't fully trust it yet.
Useful Inkcsape extensions
- Hatch fill There is also builtin hatch effect called "rough hatch", but I like this one better for tidy/non rough hatching.
- Remove empty groups -> does what it says. Often the output from other software exporting SVG or PDF is very messy. Cleaning up empty groups makes it a bit easier editing such files before sending to plotter.
- Remove duplicate lines
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.