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.
25 thoughts on “Make It Compatible”
“Criticize-that-it-doesn’t-suit-your-needs-and-maybe-someone-will-do-it-for-you-a-day” may be a better forum for this article.
I see the point, but it would certainly be more in the spirit of this DIY based website to actually implement it yourself and share.
I would more expect to see this in the comment sections.
Sorry, I’ve only had one cup of coffee yet, and my positivity is not fully charged.
sometimes its about doing something yourself and not just solving every problem with the #include statement. thats what you do when you actually want to learn something. there is a place for hacker lego though. my last project was something along those lines, when our cable company decided to stop doing cable we needed to switch to streaming, and while i had an htpc box, it was kind of cumbersome to use with the htpc kb/mouse i had, and i needed a separate remote for the tv.
i slapped an ir sensor on a pro micro, and thanks to some unused buttons on the tv remote and an off the shelf ir library i was able to not only have a remote start but implement a crude mouse and various keyboard shortcuts with just the existing tv remote. it was nice not to have to learn the gritty details of ir communication and was able to get it working in a couple days. its been quite the hit. had i gone the other way i probibly would still be working on the damn timings and reading protocol specs.
i think the jellyfish plotter was an example of wanting to learn something. ive done my fair share of those. they rarely culminate in a finished project though, and usually aren’t far from being chucked in a salvage bin if they do.
I think the author makes a valid point, which is not against doing things yourself. It’s about following standards to make things more inter-compatible (it’s in the title). I’ve been guilty of that numerous times, in the high of working on a project, reinventing formats or protocols because I didn’t think to look if I could simply implement a de-facto standard of the industry/community.
In the given example, that could have been writing a custom parser that accepted GCode (or HPGL, as other commenters have pointed out) instead of a new language. It would have probably been about the same amount of effort and the same learning reward (it’s all about parsing strings after all, and GCode, while a bit obscure to read for a human, is pretty simple to parse for a program), but would have made it automatically compatible with a lot of other software and toolchains. This is the kind of thing in FOSS projects that makes the whole greater than the sum of the parts.
I have to disagree with all the negativity some have responded to this article with.
First, he wasn’t just complaining that they didn’t do it his way. He was using it as a teaching moment, pointing out a concept that we should all keep in mind IF we want to see our projects adopted, used and maybe even extended by a wider audience.
It’s something we can all apply to our own projects to make them better. Simply writing and releasing different firmware for this project wouldn’t do that.
Second, this isn’t even a free open-source project where the original maker is giving away their design which is a product of their hard work for free. It’s an Indie GoGo campaign. Sure, they release their software on GitHub but I don’t see any STLs! They want you to buy it from them.
So why not point out a bad decision that makes one not want to buy? If you are the original maker consider it constructive criticism. If not, consider it a product review.
Either way, consider it a lesson in good design.
I would think HPGL would be a bit better fit for this than G-code, as it was designed specifically for pen plotters. Then you get the benefit of a lot of graphics software having direct support for HPGL.
Ditto. If I’m designing the thing, the tooling is going to suit the needs of the thing. Particularly here, I know enough about G-code to skim it or tweak it, but not to write it and certainly not to process it correctly. Maybe I don’t need G-code support myself and maybe any support I might write for it would be broken and incomplete. What I should probably do is wait for someone to happen along who actually cares about G-code (because, again, as the creator, it’s not a priority for me) and, since I shared my source, can write (or have written) an implementation that is good enough for them to use, and hopefully contribute it back.
A DIYer doing a show-and-tell for free has no particular obligation to “think about [their] audience”.
“Gcode, which is essentially the lingua franca of moving machines”
Given that it is a 2D plotter, I could make a better argument for HP-GL than Gcode. (writing as a person that has implemented several dozen little-languages for particular purposes over the years, but chose HP-GL for this type of use case- a cutter in my case-, and Gcode for my CNC lathe, implemented on an MSP430 a year or two before GRBL came stable. One day, I will just replace it with a grbl board)
Agree that compatibility and building on what already exists is the way to go. The problem is that gcode is a very cryptic and undescriptive programming language to put it politely..
Unless you are a gcode geek, it is nearly impossible to know what that means without looking it up, and being an intermittent 3d printer, each time I do a print, I have to look it up again, so I think it would make sense to make a more descriptive language that converts to-from gcode, like a higher level programming language on top of assembler.
say maybe something like
For inspiration as to what such a 3d prining language( language rather than Macros mind) might be like, maybe look at openscad syntax and work from there.
Most standards that have been around for a while have acquired various disgusting warts. But the real problem is that they impair blue sky creative thinking.
When I write code for work, I’m expected to make it compatible, work with well established libraries, think about future proofing, deal with all reasonable corner cases, and document everything. 80% of that is not what I would call fun, unlike solving programming challenges and figure out how to get something to “work”. That’s the difference between a hobby and a job. I used to constantly get stalled on hobby projects because I would spend so much time thinking about that kind of stuff and it suddenly wasn’t “fun” anymore.
Your point isn’t necessarily wrong, and I do try to push myself to clean things up and make reasonable choices, especially since I want the things I build to be useful to others, but whining when someone doesn’t do that is I think in poor taste and will result in a lot less neat things being built and released to the world. Proving something is possible, is the first step. Second passes can be made later or by the community.
I think that first point bears repeating, and is equally true of working in the open. I worked at a well known open source tech company for years, and yet an often repeated axiom we had was “being open is hard”. It was a reminder that as much as we valued having everything we did be open source & in the open, it did make the work significantly harder in many ways.
And of course that always ties in with communication too. Just the narrow scope of communicating what a tech project is can be hard enough to be an entire career path on its own. So every time I see any project (like this, for instance) published in the open, I wonder how many other projects like it exist & never got published publicly. I spent my career in open source, and yet I’ve got countless examples of that myself.
And while I think critiquing is incredibly important (& I agree with both the article’s points & many counter points), it’s another thing that can make it harder to share & publish. Like anything, it’s harder for some people than it is for others. So it should always be done with compassion (which I think this article did do).
And for anyone doing the publishing in the open & having your work critiqued, it helps to remember this: You are not your code. Or more generally: you are not your work. Don’t assume bad faith – people are critiquing a piece of work with the intention of betterment and/or learning. They are not critiquing you.
(Unless you’re being an asshole, then maybe yes you should take that critique onboard personally & do something about it.)
Sometimes you need to reinvent the wheel. It may be a better wheel.
How about writing a preprocessor to run on your PC to translate G codes into the commands accepted by this processor?
Alternately, if the source code is available and written in a reasonably modular fashion, splice your own G code parser in to replace the existing language?
As a friend of mine is fond of saying, “just return the unused portion of the code, and we’ll happily refund the unused portion of the money you paid for it.”
Complaining that someone didn’t spend enough time and effort considering your needs while creating something they gave away for free is formally deprecated by the Open Source philosophy.
But this was an IdieGoGo campaign. They actually are asking for your money.
I agree with Elliot. In fact, when I read about the project here and clicked on the project link to get more details I was immediately disappointed at the cumbersome workflow.
I would not criticise the project, nor do I think Elliot is criticising it. If the project was developed in a vacuum then this result is what I would expect. But these days I expect some degree of compatibility with existing software because the information is out there and easily available. In fact, building a plotter without awareness of G-code or HPGL is hard (and yet, not impossible, it seems). Had it been built with G-code or HPGL support then yes, it is immediately usable with a huge amount of software and utilities.
Having said that, it’s finished, and it works, which is great. I suppose this article (and this comment) is more of a lament.
There’s a difference between criticising and critiquing. The latter is very important, but always needs to be done with compassion. And I think the article achieved that.
I found myself surprisingly annoyed reading this article. Whole point of this place is to celebrate interesting projects and creative solutions – not to trash a project because it didn’t do something the way you would. Take the design and hack a G-code implementation on to it if that is what you want – a better use of your energy than writing an article to point out that someone else’s project did do what you wanted.
I suppose it depends on the intentions of the project. Just because you share it for people to see doesn’t mean that your main goal to design a project specifically for others to replicate.
The creator doesn’t owe us anything. And look how happy the octopus is! No amount of standardised gcode can compete with that!
I feel like if the octopus read the article then it might frown a little bit. It’s ok, octopus. I love you just the way you are.
Maybe Hackaday could organise a “tip jar” via, say, Gitcoin for software projects people want to encourage others to modify? It’s great that hardware can launched here and be sold on Tindie, but where is the equivalent for niche software?
Turtle Graphics or Carol, been around for decades and Turtle Graphics predates G Code.
G Code started with simple Cartesian kinematics and essentially said move this motor X amount and then move that motor Y amount and then move the other motor Z amount. There wasn’t a Cos Sin or Tan in sight.
There’s nothing Cartesian about this build and G Code makes less sense here. The kinematics is one of two intersecting arcs.
Sure, it’s just another protocol layer for the CPU to process but the image has to come from somewhere and that somewhere isn’t the plotter so the image processing computer can do the kinematic conversion to whatever end code weather it be G Code or a Code based on the width of beads on an abacus.
Some of the best concepts come from thinking outside the box. I remember in physics at school we had to calculate an error range like “accurate to 3 decimal places” or “plus or minus 2 degrees”. I did all my maths in bases like base Pi instead of base 10 just so I could specificity results in base PI with an accuracy of “plus or minus 0”. It took a while but my physics teacher accepted that a base doesn’t have to be an integer.
So suck it up as a challenge and use the force!
The kinematics of this plotter are the same as the Maslow CNC machine already covered at Hackaday (https://hackaday.com/2016/10/14/maslow-brings-the-wall-plotter-into-the-woodshop/). Perhaps the folks now supporting the Maslow at Makermade.com (https://makermade.com/collections/all/products/2021-m2-cnc-kit) would like to adapt their software to drive this device as well.
If the device provides a documented control interface surely it’s on you, the whiny ungrateful end-user, to knock out a G-code interpreter to suit your needs if it’s so easy.
How do you make it compatible?
The hardware looks like it is wired for an arduino with a CNC Shield V3, which is pretty standard.
The software is a set of Excel macros to change cut-and-paste SVG geometry into 2-point lines, moves, and bezier curves in a text file, and then an awkward arduino sketch to translate those into the polar-bot step counts. The calibration from arbitrary anchor points to the configuration variables seems awful.
If you carefully stuck the anchors a fixed and level distance apart, and switched the board to something beefier than an Uno, you could run it as a POLARBOT.
You could run grbl directly on that hardware, but you’d need to pre-process the cartesian geometry into Marlin-POLARBOT warped gcode. The code at https://github.com/fumikrobot/source-code/blob/main/fumik_rv9.ino gives few hints at that transformation.
Oops — It is an Arduino Mega with the Uno-sized CNC Shield V3: https://github.com/fumikrobot/NonCodeFiles/blob/main/2.jpg There’s plenty of space for Marlin & POLARGRAPH. And the POLARGRAPH cartesian to polar code in Marlin isn’t nearly as complicated as the Fumik Robot code — https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/module/polargraph.cpp — Marlin is just calculating the hypotenuse between the level anchor points and the point of interest. Adapting it to un-level anchor points would only need a separate `y` for the left and right hand triangles. You could add a `#define Y_MAX_POS_RIGHT_OFFSET 47` and change 2 lines of code to make un-level POLARGRAPH work.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)