Summary of MAKE IT COMPATIBLE
This article critiques a wall-plotter project for using a custom micro-language instead of standard Gcode. While the mechanical design is praised for its ease of installation and stability, the awkward image-generation toolchain limits its compatibility with existing workflows. The author argues that reinventing standards hinders replication and user adoption, suggesting that adhering to widely used protocols like Gcode is better for open-source sharing than creating unique command structures.
Parts used in the Wall Plotter:
- Lightweight geared steppers
- Gondola
- Timing belt
- Arduino libraries
- Spreadsheet tool
- SVG files
I’m probably as guilty as anyone of reinventing the wheel for a subpart of a project. Heck, sometimes I just feel like working on a wheel design. But if that’s the path you choose, you have to think about whether or not it’s important that others can replicate your project. The nice thing about a bog-standard wheel is that everyone has got one.
The case study I have in mind is a wall-plotter project that appeared on Hackaday this week. It’s a really sweet design, and in many ways would be an ideal starter project. I actually need a wall plotter (for reasons) and like a number of the choices made. For instance, having nearly everything, including the lightweight geared steppers on the gondola makes it easy to install and uninstall — you just pin up the timing belt from which it hangs and you’re done. Extra weight on the gondola helps with stability anyway. It’s open source and based on the Arduino libraries, so it should be easy enough to port to whatever microcontroller I have on hand.
But the image-generation toolchain is awkward, involving cutting and pasting into a spreadsheet, which generates a text file in a custom plotting micro-language. Presumably the designer doesn’t know about Gcode, which is essentially the lingua franca of moving machines, or just didn’t feel like implementing it. Where in Gcode, movement commands are like “G1 X100 Y50”, this device expects “draw_line(0,0,100,50)”. They’re essentially equivalent, but incompatible.
I totally understand that the author must have had a good time thinking up the movement commands and writing the spreadsheet that translates SVG files into them. I’ve been there and done that! But if the wall plotter spoke Gcode instead of its own dialect, it would slot instantly into any number of graphics processing workflows, which would make me, the potential user, happier.
When you are looking at reinventing the wheel, think about your audience. If you’re the only person likely to see the project, go ahead and scratch whatever itch you’ve got. You’ll learn more that way. But if you want to share the project with as many people as possible, adhering to the most widely used standards is a good choice for your users, even if it is less fun than dreaming up your own movement language.
Source: MAKE IT COMPATIBLE
- How does the gondola install and uninstall?
You just pin up the timing belt from which it hangs. - Why is extra weight on the gondola beneficial?
Extra weight helps with stability. - What language does the device expect for movement commands?
The device expects a custom plotting micro-language like draw_line(0,0,100,50). - Does the device support Gcode?
No, the designer did not implement Gcode which is the lingua franca of moving machines. - What tool is used to translate SVG files into movement commands?
A spreadsheet is used to generate a text file in the custom plotting micro-language. - Can this project be ported to different microcontrollers?
Yes, it is based on Arduino libraries so it should be easy enough to port to whatever microcontroller you have on hand. - Why might an author choose to reinvent the wheel?
An author might do this if they are the only person likely to see the project or want to scratch their own itch. - What is the best way to make a project easier for other users?
Adhering to the most widely used standards is a good choice for your users even if it is less fun.
