Reprap Direct Drive Firmware

I thought I see what sort of support this idea has.
Sorry this is a long post. If its too long, please feel free to TL;DR and move to the next thread.

Observations:
- there are currently a number of people in the process of designing different 32bit ARM single board printer controllers
- there are a huge number of people already with Arduino-based 3d printer controller boards who will be reluctant to throw them away unless they need to
- there are also quite a number of people experimenting with interfacing cheap, microPC boards (such as the Raspberry Pi) to interface to existing Arduino-based controllers.
- so there are many different software & firmware projects being developed concurrently to support all these different hardware permutations (e.g., new ARM firmwares, Repetier-Server on Pi, etc)
- currently all standardization across different platforms is done at the G-code level (although there are slight differences in implementations most of the slicers and host programs can handle these differences).
- the Arduino is fine for running motors and interfacing I/O, however,
- the Arduino controllers are being pushed to their processing limits at the G-code level and might even be a limiting factor for the introduction of more complicated motion planning or co-ordinate remapping features (such as to support auto bed levelling)
- it is difficult to port the Arduino current firmwares because their are so tied to the real-time register organisation of the target platform
- yet, the majority of the complexity & smarts in driving the system is not associated with the direct real time components.
- many of the Linux kernels available are not proper real-time operating systems, and the ones which are are then less compatible or general purpose.

Proposal:
It seems to me that there would be some merit in defining a common command protocol for interfacing at a lower level than the G-code.

The goals of this "direct drive" protocol would be to:
- to provide a common interface for the control of tool-heads, extruders, temperature controls & GPIO of a 3D printer.
- to encapsulate all real-time requirements and specific platform i/o idiosyncrasies.
- to minimise the processing which needs to be done in the real-time component.
- to have a simple interface which can be extended easily for different systems within the same framework (e.g., to address inputs or outputs specific to the printer)
- to minimize the configuration needed to be stored by the direct drive component (runtime configuration would be provided by the layer above)
- to separate protocol framing from transport framing to allow efficient use of anything from direct memory mapped interfaces (e.g., on a single CPU) or master/slave protocols such as SPI/I2C or plain vanilla RX/TX.

Benefits:
The benefits I see would be:
- ARM printer controller designers would be able to easily get direct-drive supporting firmwares to compile on their system (because there are little or no CPU architecture specific components).
- Firmware designers can get their firmware to run on more printer platforms easily (on platforms which implement a direct drive interface).
- The large number of people with Arduino controllers already can cheaply upgrade using a Raspberry Pi or ARM platform without throwing away their controller (just by uploading a direct drive interface firmware). [Increasing initial critical mass.]
- Even within single chip ARM controller boards, the implementation of all real-time components in a separate library then frees the designers to use higher level languages (Java, Ruby, C#) to implement the higher layers without concern for performance.
- Hopefully resulting in a less fragmented community with everyone tuning the firmware just for their board (that's been the one blessing of the Arduino)

Implementation:
So what would the direct drive protocol look like?
- I think that a binary, extensible command protocol would be appropriate. Transport framing would be a layer on top of this so that multiple commands can be sent in the same transport frame.
- From a motion drive point of view I was thinking that sequences of trapezoid speed curves should be sufficient, that is, where each motion block has a (pre-calculated) initial acceleration, maximum speed, and final deceleration (to a junction speed) with all x/yz/e movement being specified directly in steps (i.e., all motion planning is done outside of the direct drive component). In comparison to today's firmwares this would be like having just the Marlin/Sprinter stepper.cpp code components being implemented by the Arduino and all higher G-code & planner.cpp functions implemented off-board.
I think you would also want homing to be supported natively (possibly simply through movement flags).
PID & bang-bang algorithms would be implemented for extruder and hotbed control.
It should be possible to set/read temperature, set/read state and GPIO pins through a standard "virtual register" mechanism (as is common for machine-to-machine interfaces).
Aborting queued motion commands should possible (with the ability to determine the point at which queue was flushed).

What are people thoughts on this? Is this a good direction? Would developers adopt it?
Do you think that the RepRap community could actually agree on such a common protocol? Or would everyone just end up implementing their own thing?
I imagine it would need buy in from at least a core number of platforms and at least one solid firmware effort (more would follow if successful). [Having said that much could be initially borrowed from the current Arduino-based firmwares for both the generic motion planning side and the real-time components (Arduino-specific anyway).]
Does a trapezoid speed function give sufficient flexibility in motion control for future needs?

Edited 4 time(s). Last edit at 03/05/2013 08:05AM by buildrob.

Quote

Do you think that the RepRap community could actually agree on such a common protocol?

No, I don't think so. They can't even agree on a common G-code protocol. Also, as you wrote, porting a G-code parser is simple, so an additional layer doesn't give you much. You'd have to have a parser for your protocol anyways.

Nonetheless, the usual way to get something like this rolling it to write an implementation and prove this implementation works better than the competition.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I don't think that the current FDM approach to desktop 3D printing is where this technology is going to go. at the moment FDM printers are really just a different kind of CNC machine and so the whole G-code thing follows from that. but likely the move will be to take these printers, as "tools" (in the context of a CNC or lathe being a tool) and make them more like "appliances" (in the context of laser printers or coffee makers, geared to the consumer). that is if the hype translates into a market translates into some significant money to R&D a 3D printing appliance. so for now, the "tool" paradigm mostly works for the 3D printer context (especially FDM printers).

This is good for now. Either desktop 3D printing will move to the "appliance" stage at which point it will be taken out of the Open Source world and become commercialized, or it will be relegated as a technological fad in the media and we'll all still be pumping out molten plastic and modifying G-code firmware. at that point, it might be worth re-addressing your ideas.

Or, perhaps your idea is part of the path to commercializing a 3D printing appliance, just remove all the notions of Open Source from it? you could wrap that up in a business plan and look for venture capital.

I think what we are doing now with FDM 3D printing is pretty cool but ultimately this will either become a consumer appliance, and we'll simply look back in fondness at what we've done as the foundation of the consumer future of this technology, or we'll keep hacking Marlin and the like.

That's my take.

---

[www.printrbottalk.com] Printrbot Forum and Wiki

buildrob Wrote:
> Proposal:
> It seems to me that there would be some merit in
> defining a common command protocol for interfacing
> at a lower level than the G-code.

I have done some thinking about this. Initially it seemed crazy to me to send ASCII data from a 3GHz CPU with 2GB of RAM to be processed by a 8 bit CPU with 4K RAM, which is also doing real time control at the same time. It seems obvious that as much number crunching as possible should be done on the PC side, and the printer controller act as a fairly dumb but real time controller.

On the other hand, Gcode is a fairly well understood language, and is implemented everywhere, with perhaps the notable exceptions of Repetier protocol and whatever it is that Makerbot use.

So ignoring the problem of legacy compatibility for the moment, how much can we save by using a "direct" protocol?

If you directly inject movement blocks into the stepper queue, you still have to transfer a set of data which is similar in nature to the Gcode line, i.e. a command number plus several axis values. e.g typical Gcode G1 XYE, which if encoded as a byte + 3 x 32 bit comes to at least 12 bytes. That is about half the ASCII encoding, say around 25 bytes, so that seems like a good win.

With some application specific compression that can probably be reduced further, at the expense of more complexity and extra processing on the printer side. The disadvantage for me is that we lose the general purpose nature of the Gcode.

I did consider a general purpose compression scheme, but they all seem to require many KB of RAM for effective decompression, even a simple Huffman scheme.

Peter Brier did some analysis and proposal for an application specific binary protocol [wiki.ultimaker.com]. Repetier also uses an application specific protocol. For various reasons I find those protocols inadequate.

I wrote a note on a more general purpose binary Gcode protocol (which I now realise I have not published anywhere [1]).

So I think there is technical merit in the idea and worth exploring. How to get people to take it up is another thing. I think Traumflug is right, you (we) need to go ahead and do it and show it works, then maybe it will get interest. The drawback is that it requires changes to both firmware and host software, and there is a lot of inertia to change. The preferred solution seems to be "faster comms", which seems like a cop out, but if that works and needs no legacy software changes then why not.

It's also worth noting that the ASCII Gcode we currently send has a lot of scope for size reduction. e.g. remove spaces, trailing zeros, axis words that don't change value. According to GCode standard the "G1" does not need repeating since it is a modal command, it should become the default command (but I don't think any firmwares support that). Gcode I have looked at can get a 50% reduction just from that.

Other aspects of the ASCII "Gcode protocol" which I believe can be improved are in error handling, flow control and "out of band" control. I wrote some notes on that somewhere as well... The current error handling doesn't even work properly in a lot of cases, as I accidentally found out.

[1] ETA: I have put my note on the Wiki [reprap.org]

Edited 2 time(s). Last edit at 03/05/2013 06:05PM by bobc.

I think this

"From a motion drive point of view I was thinking that sequences of trapezoid speed curves should be sufficient, that is, where each motion block has a (pre-calculated) initial acceleration, maximum speed, and final deceleration (to a junction speed) with all x/yz/e movement being specified directly in steps"

is short sighted, while it is sufficient for motion control of linear bots it's insufficient for none linear systems like the delta bots, you'd have to break down the none linear motions on the host into linear segments much like the front end of the firmware already does, the difference being trying to pass that much larger set of data over USB would almost certainly result in pauses.
Instead I'd suggest a set of constants for cubic curves preferably rational, or possibly higher order, it wouldn't allow you to deal with every possible geometry, but it would let you approximate the motion with less segments.
Although I'm still in two minds how best to deal with this.

Edited 1 time(s). Last edit at 03/05/2013 06:30PM by Polygonhell.

@plexus Perhaps a better question would be, assuming we did do a reasonable job of defining a common interface and a couple of implementations were done, would firmware designers be likely to be interested adopt it?

@bobc I don't think the Arduino comms bandwidth is the main issue here - it is mainly a CPU overhead issue for advanced features or high speeds. So I don't think that simply using a binary encoded G code mechanism would be a sufficient return. It should be noted that I'm not saying we should stop using G-code (thereby breaking compatibility with all existing slicing tools), its just that the processing of the G-code and would occur outside of the minimal real-time component.

@Polygonhell Sorry my language was perhaps misleading. The data would not describe movement in a x/y/z co-ordinate space but rather speed curves for different motor axes. As such it would not matter whether it was a polar, delta or cartesian bot. [Edit: Scrub that - the co-ordination of the movement needs to be very tightly coupled and polar/delta bots would have non-linear movement relationships but I'm sure there are ways of representing this. It may we be that you have separate movement representions from the different cartestion/polar/delta bot types.]

Edited 4 time(s). Last edit at 03/05/2013 07:48PM by buildrob.

buildrob Wrote:
-------------------------------------------------------
> @bobc I don't think the Arduino comms bandwidth is
> the main issue here - it is mainly a CPU overhead
> issue for advanced features or high speeds. So I
> don't think that simply using a binary encoded G
> code mechanism would be a sufficient return. It
> should be noted that I'm not saying we should stop
> using G-code (thereby breaking compatibility with
> all existing slicing tools), its just that the
> processing of the G-code and would occur outside
> of the minimal real-time component.

Comms bandwidth certainly is a potential issue. You haven't put any numbers on what data you want to transfer, so it's hard to tell if it actually is an issue. If you are precalculating speed profiles to send to the controller, you need to guarantee that is sent in a timely fashion. You will need to create a much more robust and efficient comms protocol, which is not trivial in a small footprint.

What you say here seems to conflict with what you said before, so I guess I just don't understand what you are trying to do. While the proposal is largely theoretical, it seems like what you hope to gain on the roundabouts will be lost on the swings, as my wise old team leader used to say.

Considering all the previous (abortive) attempts to improve the processing split between host and printer controller, the Gcode interface remains popular. Partly that is legacy, but it also suggests to me that it may be the appropriate solution, even if it seems theoretically inferior to more "advanced" alternatives.

bobc Wrote:
-------------------------------------------------------
> buildrob Wrote:
> --------------------------------------------------
> -----
> > @bobc I don't think the Arduino comms bandwidth
> is
> > the main issue here - it is mainly a CPU
> overhead
> > issue for advanced features or high speeds. So
> I
> > don't think that simply using a binary encoded
> G
> > code mechanism would be a sufficient return. It
> > should be noted that I'm not saying we should
> stop
> > using G-code (thereby breaking compatibility
> with
> > all existing slicing tools), its just that the
> > processing of the G-code and would occur
> outside
> > of the minimal real-time component.
>
> Comms bandwidth certainly is a potential issue.
> You haven't put any numbers on what data you want
> to transfer, so it's hard to tell if it actually
> is an issue. If you are precalculating speed
> profiles to send to the controller, you need to
> guarantee that is sent in a timely fashion. You
> will need to create a much more robust and
> efficient comms protocol, which is not trivial in
> a small footprint.
>
> What you say here seems to conflict with what you
> said before, so I guess I just don't understand
> what you are trying to do. While the proposal is
> largely theoretical, it seems like what you hope
> to gain on the roundabouts will be lost on the
> swings, as my wise old team leader used to say.
>
> Considering all the previous (abortive) attempts
> to improve the processing split between host and
> printer controller, the Gcode interface remains
> popular. Partly that is legacy, but it also
> suggests to me that it may be the appropriate
> solution, even if it seems theoretically inferior
> to more "advanced" alternatives.

I'd buy that for a dollar!

---

[www.printrbottalk.com] Printrbot Forum and Wiki