G-code support (blanket/question issue)

[techninja]

This is the blanket g-code support ticket. G-code is a huge thing, not completely standardized, and adjusted on an application basis. It makes sense to support it for software that creates gcode that we want to output movements/operations for.

Before anything is done, some questions need to be answered:

• What would the best feature-set be?
  • All moves, height adjustment.
  • Curves?
  • What are the most common?
• Would it be two way?
• Where would buffering live?
• Would cncserver accept/parse gcode files? or would this be more like an API that takes individual or groups of gcode commands?

Welcome any other ideas/suggestions in the comments!

[goatchurchprime]

I think there's a deeper design question that needs to be raised, which is why the EiBotBoard wasn't based on the GRBL firmware (https://github.com/gnea/grbl/wiki), which depends on about the same level of microcontroller hardware and serial communication, but has the advantages of: (a) not having to invent a new unique command set (GRBL uses G-code), and (b) leveraging its sophisticated acceleration, cornering and speed management with look-ahead.

Speed and acceleration management is really hard to get right, and I have found this technical feature implemented both in the eggbot inkscape plugin (python) and the in the robopaint app (nodejs).

To me this (the development of the speed and acceleration management module(s)) looks like the bottleneck to running the devices as fast as it should be able to go.

I may have this all wrong, but this is what it looks like to me from my understanding of control software. It would be good to know the correct answer.

[EmbeddedMan]

I can partially answer that one - when I started the EBB firmware, I wasn't aware of GRBL, but I was aware of G-code. Since the EBB was only designed (in the beginning) to support simple linear moves with no acceleration, that's all I put in the firmware. I didn't base it on G-code because it would have been overkill for the job at hand. EBB was designed to run EggBot originally, which doesn't need more complex motion control than simple straight non-accelerated moves.

That's not to say that there won't be a G-code capable controller board at some point in the future. I'm not exactly sure what EMSL has planned for future upgrades hardware-wise.

What I will say is that on a different project, which also uses the EBB (and it's simple moves) a very sophisticated acceleration/deceleration and look-ahead planner was implemented in node.js on a RaspberryPi. For that particular project, it was the right way to break up the tasks because it allowed a non-embedded programmer to implement and test all of the higher level motion control code on the Pi without having the limitations of the embedded microcontroller.

[oskay]

The "correct answer" is that things change, and it's very easy to look back at the origins of the EBB in 2009, and figure that if we had picked a different set of feature requirements and backed the right horse (also in an early stage in 2009), that things might have turned out more to your satisfaction.

There wasn't any compelling argument to use G-code back then, and hobbyist-oriented means of generating G-code were much more primitive at the time.

[EmbeddedMan]

I will also add that there's nothing preventing somebody from either porting GRBL to the EBB, or writing a simpler (GRBL does a lot) G-code parser for the EBB. I'm more than happy to help answer technical questions about the EBB for anybody who'd like to give it a go!

[goatchurchprime]

Thanks for the interesting responses; I was worried I would be causing trouble.

I think point of using GRBL is that you can drop it in place sight-unseen and gain its acceleration management features for free without needing to develop them yourselves. It achieves more than I'd have predicted for a 2Kb RAM controller. It looks like the cncserver code could adapt just as well to emit G-code as anything else, but instead of working out its own timing, waits for GRBL to say it's ready for the next block in its buffer.

There is one browser/javascript implementation of the UI drip-feeder at http://chilipeppr.com/grbl (which bridges to the hardware using serial-port-json-server ). Compare this to options like the eggbot implementation of python/INKSCAPE-plug-in or the robopaint electron/node -- and I have no idea how to decide what is the right approach for my project.

I'm coming at this from the direction of having worked with Machinekit on the Beagleboard. MK looks at first like a unified controller, but hidden deep within it is the same basic architecture that you have built -- the BB actually has a realtime co-processor (the PRU) that it loads code onto and uses to generate the accurately timed ticks the stepper-motors require.

Gaining performance from better acceleration management doesn't have to be used just to go faster; it could mean you could make do with smaller and cheaper motors, or maintain tolerance with a longer saggier belt drive.

Anyway, just some food for thought if it helps. The more I learn, the less I seem to get done.

[oskay]

We're always happy to discuss these things. G-code support has been a steady but infrequent support request for quite some time.

The AxiDraw extensions for Inkscape do provide some very basic acceleration control.

(We are also looking at a near-future driver board option that will have a fast processor and motion control firmware that leaves GRBL in the dust. Likely will be an optional add-on at higher cost. Can't say more just yet.)

[goatchurchprime]

Before doing anything more you should get familiar with this surprising approach I discovered only last week: https://medium.freecodecamp.org/how-to-build-a-3-d-printer-using-cnc-controller-in-python-bd3cd5e28516

Basically, the DMA feature on the raspberrypi has ///just/// enough capability to do the job of a realtime coprocessor generating the steppermotor ticks, and he's found a way to feed it with a linked list of timings from python.

This has caused me to reconsider a lot of what I thought was essential.

Personally, I think G-code is an abomination. It's like whatever code-language your cheapo paper-printer takes, which is something no-one is interested in because you just want a printer driver that integrates with your word-processor and you don't care how it works. The fact that it regularly gets exposed to the user is a general failure of the CNC machines and the CAM systems to get properly integrated. (I still don't know why printers don't just all use postscript so that it is never a problem.)

To summarize, end-to-end integration from the design to the result (without the intervening files) is a good thing (and is not achieved in heavy industry with their expensive, unfriendly CAM systems). However, using some standards like G-code (which the user doesn't need to know about) means you can make more of the chain using common components.