A Proposal for a Compact Gcode format: .COMPG

The issue of Gcode size has come up recently, so I want to discuss standard ways to reduce gcode size, and I have a proposal for a standard format for Compact Gcode.

I invite your comments.

This was prompted by the following:

Quote
frankvdh
Gcode files are huge, so transferring them to the printer's SDcard over the wire isn't practical.

Before I get to a more compact format, here are some ways I reduce Gcode size now, while preserving full gcode compatibility:

1. Use Relative E-values instead of absolute. This is a common setting in slicers, and most firmware supports it. The extra gcode to initialize/zero the extruder is eliminated, and the E values also use less digits.
2. When post-processing: Remove insignificant digits. For instance this printing command "G1 X-85.53112 Y26.02232 E2.07905" can be shortened to "G1 X-85.531 Y26.022 E2.079", for a 13% savings. Any decimal values below the printer's steps per mm are useless.
3. Strip all comments
4. Strip unused commands (like tool commands when there is only one extruder).
5. Strip redundant feedrates - the controller remembers the last feedrate specified - so the feed rate only needs to be specified when it changes.
6. Use integer for feedrates - for instance F2760.000 only needs to be F2760
7. Remove any redundant decimal amounts like ".000"
8. Remove ending decimal digits that are 0 in all X, Y, Z, E, F codes.
9. Remove 0 length moves, or moves/extrudes less than the printer's steps per mm.
10. Use options in the slicer to reduce the resolution to what the printer can actually print. (In Slic3r: Print settings - Advanced - Resolution, S3D has mesh reduction, etc).
11. Reduce the complexity of the STL when exporting from a CAD program using options in the CAD program.
12. Reduce the amount of support required by changing the orientation. Meshmixer can analyse a complex model and find an angle with the least support required.
13. Increase the spacing between support/support density (if appropriate).
14. Reduce the number of perimeters or infill density (if appropriate).

I make a compact copy of the gcode that is sent to my printer (from my post-processor), while keeping the original for reference. This is done while the printer is heating, so no time is wasted.
Items 10-14 above also reduce file size and printing time considerably.

DC42 had a good suggestion of using compression. This would be good for firmware/controllers that can uncompress it while both streaming or reading/writing SD.
However I don't think the 8-bit controllers will be able to keep up, so I have been thinking of an alternative.


Also, I just want to state a couple things I hold true:

• Gcode actually does what it needs to do quite well in an easy to understand way: move the tool in X, Y, Z, at defined speed, with (optional) defined acceleration, defined extrusion amount, etc.
• Gcode indicates the exact things a controller needs to know to do what it does well - handle generating acceleration profiles and generate the steps to keep your printer purring along.
• A gcode file for 3D printing is very machine specific - it has been tailored by the exact specifications you have given your slicer that are specific to your machine, and preferences, and not mine! The tool path, speeds, and extrusion rates all reflect this. This is why we do not share gcode, and it would be impractical to convert a given gcode file to work on another machine unless the two machines are nearly identical.
• I do not think gcode needs to be replaced, and I am not proposing to do so, only a standard means of compacting it.

If you disagree with the above, by all means please speak up - I'd love to know why, pm me.

And there are a couple of things I'd like to leave for other discussions:

• It's not the gcode format's fault that some slicers do not implement a features someone wants - Gcode is flexible enough and extendable.
• It's not the gcode format's fault that STL files do not implement the color encoding desired for multi-color printing. That's not related at all to this - gcode can represent the color mixing amount, or tool/extruder.

So, I want to discuss possible ways of encoding and compacting the content of gcode for transfer to a 3-D printer.

Requirements:

• The compacted gcode should be very east to un-compacted back to the original gcode exactly (easier to implement).
• The controller's firmware should need minimal modification in order to consume this compacted gcode (minimal code complexity).
• Decoding this format should require very minimal resources in the controller, and may require even easier than standard gcode.
• The format is simple enough that it would be trivial to make a post-processor generate it, if the slicer does not have the capability.
• The format should be compatible with both streaming and printing from SD.

Other Considerations:

• Modified/updated firmware would be required to use it (but compacted gcode is optional so this does not affect unmodified printers).
• The compact gcode will not be readable without a viewer/converter (although one would be trivial to create - the same compactor program could uncompact it)
• A format like this should be adopted as a standard, with full input, so that it can be eventually supported by all slicers and firmware (but not mandatory), and well planned out, so that new versions would be rare.
• The community must really want it or it won't go anywhere.
• The primary "doers" (that would be the slicer and firmware developers) must be convinced that it is a good idea, worthy of their time.
• Communications protocols used would need to be able to handle binary data.

The Compacted Gcode Format / COMPG

As described here this format would be perhaps 50% smaller than the original example, your mileage may vary.

• Each command starts with a one character Command Type Code
• Each command has a fixed set of parameters according to it's Command Type Code
• Each parameter (value) has a fixed length, either 2 or 4 digits encoded as follows:
• Each decimal number is encoded to 4 bytes (example: for X, Y, Z, and E values)
• Each integer is encoded to 2 bytes (feed rates)
• So each Command Type has it's own defined fixed length.
• There is no end of line character between commands (not needed)
• Comments are not included by default.
• Gcode that is not part of the Compact Gcode standard could still be included in the file, perhaps with a prefix like "!", and would have an end of line character after. So in this way it is not necessary to define a Command Type for all gcode codes, just the few that are used constantly.
  /list]
  
  Example Extrude Command:
  Exxxxyyyyeeee - where E indicates an Extrusion Segment Type, xxxx, yyyy placeholders for the fixed 4-byte encoded X and Y coordinates, and eeee is the encoded Extrusion amount.
  
  Example Move Command
  Mxxxxyyyyff - where M indicates a Move Segment Type, and ff indicates the 2-byte encoded feed-rate (just 2-bytes allows a value up to 32767) .
  
  Variations (like using a Z coordinate) would be accommodated by using a different Command Type code - so that all command types always maintain their own fixed number of parameters, parameter order, and fixed length.
  
  I think this will actually make decoding commands in the firmware much easier and faster, as the amount of parsing is drastically reduced. (Yes, some firmware is very good at it already).
  
  Perhaps this has already been considered or implemented, I dunno... Thanks for getting this far.
  
  If you are a firmware or slicer developer, do you think this is worth doing?
  
  

  ---

  My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
  Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

Most of your 1-14 stuff is already implemented into most slic3rs

easiest(useable for 8bit) way would be switching to binary fromat, skeinforge has an implementation (broken?) , Repetier has also an implementation, afaik just Marlin doesn`t have, thats why most other slic3rs do not support it.
there was also another implementation of it proposed - sanguino3g

your "compg" (never user a format with more thatn 3 letter ) proposal could then also be applied to a binary format

Chri

Edited 1 time(s). Last edit at 09/17/2016 04:03AM by Chri.

---

[chrisu02.wordpress.com] Quadmax Intel Delid Tools

Chri, thank you for your reply.

Quote
Chri
Most of your 1-14 stuff is already implemented into most slic3rs

Yes, that is exactly what I was getting at there. That is what people could do now, without resorting to a different format - to make their own gcode smaller. After all - when analyzing the need for a new thing, you need to know if it's possible to already do it with existing methods, otherwise why bother? Unfortunately even with those methods gcode can still be very large, and so I propose this format - one that turns out to be much easier to parse, fully reversible, backward/forward compatible for unusual or new standard gcodes, and very simple to implement.

Quote
Chri
your "compg" (never user a format with more thatn 3 letter )

Do you not like the "'.gcode" extension then? ( I really does not matter to me what extension is used, it just can't duplicate an already used extension.)

Quote
Chri
easiest(useable for 8bit) way would be switching to binary fromat, skeinforge has an implementation (broken?) , Repetier has also an implementation, afaik just Marlin doesn`t have, thats why most other slic3rs do not support it.
there was also another implementation of it proposed - sanguino3g

Thanks for siting that info. All of these fragmented and incompatible implementations call out for a standard, and one that is very easy to implement, and reversible. The sanguino3g (and the others) are more of a communications protocol - this is not one - just a more compact format for the data, with fixed length, fixed format codes. The advantage is that many existing communications protocols could be used with COMPG (or COG, or whatever), while transferring about 50% lest data, and storing less data on SD, and in flash and RAM on the controller.

Quote
Chri
proposal could then also be applied to a binary format

Sure, you could use a different all-binary format.
Whatever works best, as long as it is easy to implement, low overhead in the controller, reversible back to gcode, can store gcode that is unfamilliar with it, easier to parse than unprocessed gcode, and saves a similar amount or more in file size.
These are things I think are critical to wide adoption.

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

I have given compression some thought on the past, and came to the realization that 80-95% of a 3d printer gcode file are sequences of successive moves on XYE only, e.g.:

G1 X10 Y5 E7

This means all you need for great compression is to add a way to say "2000 flat moves follow", and send all x, y and E coordinates as raw numbers (non ascii encoded). Using relative 16 bit signed integers for each field would allow 32k size-increments (e.g. 0.01mm increments to 320.00mm) per move and take just 6 bytes. 2000 moves would take 12kB...

Anything else could be passed as regular gcode and still have little impact on file size. Changing as little as possible could also encourage adoption.

Other that that, I really don't think gcodes are huge, it is the 10kB/s serial that is damn slow... If we kill the serial then USB or WiFi or SPI could transport 2-10MB/s, so a "huge" 60MB gcode would take 6-30 seconds. My heaters are not that fast.

Quote

6.Use integer for feedrates - for instance F2760.000 only needs to be F2760

I totally agree with the need for compression.
The F2760 for example could be F27 for me, because I don't use the third digit. Only the controller needs to know, it has to multiply 27 by 100 as fixed value.
Removing all spaces between the commands/variables should be easy to parse too.

I hope someone comes up with a post-processor we can modify for our own ideas. This will initiate a huge number of proposals that could than be melted into one.

Edited 1 time(s). Last edit at 09/18/2016 03:36AM by o_lampe.

Thanks for the feedback.

I like using less digits. I will ponder the idea to see how it might affect resolution for both moves and extruded amounts.

I analysed a Slic3r generated 64MB gcode file I had (for a full size storm trooper helmet, with support), and over 99.99% of the commands were one of the following 5 types:

Layer Change               2,186   0.1  %
Retract/Unretract         80,315   3.4
Moves with Feedrate      153,667   6.6
Extrudes with Feedrate   159,375   6.8
Normal Extrudes        1,947,381  83.1    (Just X, Y and E)
                       --------- ------ 
Total Commands         2,343,068 100.0%

My only reservation with bundling same-type commands, is easily and correctly parsing the next command - since the numeric data is not ASCII it could give a false positive for the next command type.
It would save 2.9% in the above example - 1.83 MB.

Quote
My only reservation with bundling same-type commands, is easily and correctly parsing the next command - since the numeric data is not ASCII it could give a false positive for the next command type. It would save 2.9% in the above example - 1.83 MB.

Instead of always using a same "blank" to seperate the single numbers/lines of x/y/z you may can use other predefined letters so this way the space`s would become a double feature ?
Removing all "blanks" shrinked the filesize of a file by about 10% (just tried it out)
Chri

EDIT: Maybe also remove all "enter" commands, as we know that every G oder M code is the beginning of a new line.

Edited 1 time(s). Last edit at 09/20/2016 01:22AM by Chri.

---

[chrisu02.wordpress.com] Quadmax Intel Delid Tools

Yes, those both are part of it.
No cr/lf ln between codes, no spaces. And floating point stored in 4 digits. As mentioned, it can be made even smaller using 1 digit for feed rate (and multiply by 100).

A bunch of normal extrudes would look like the following as they would be strung together, for between 54% and 62% savings (note: x, y, e shown here would be non human readable).

And this shows some possible additions: R for retract, Z for z move, U for un-retract, F for extrude with feedrate, and an example embedded standard gcode:

ExxxxyyyyeeeeExxxxyyyyeeeeExxxxyyyyeeeeExxxxyyyyeeeeExxxxyyyyeeeeRZzzzzMxxxxyyyyfU!M104 S190
FxxxxyyyyeeeefExxxxyyyyeeeeExxxxyyyyeeeeExxxxyyyyeeee ... etc

So above are 5 regular Extrude segments, then a hardware Retract, then a Z move, then a x/y Move with feedrate, then a hardware Unretract, then a standard gcode example to set a temperature (prefixed with !, ends with cr/lf)
On the next line: an extrude with Feedrate, then 3 regular Extrudes.

It should be simple to make a compactor / un-compactor in Python, as there are several gcode parsers already done in it, and this is far simpler.

Edited 1 time(s). Last edit at 09/20/2016 03:30AM by Paul Wanamaker.

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

do we need yet another file format... why not just use gzip and make the file .gcodez or something similar.

Edited 1 time(s). Last edit at 09/20/2016 03:54AM by Dust.

Quote
Dust
do we need yet another file format... why not just use gzip and make the file .gcodez or something similar.

A smaller gcode itself would also help when printing via USB, just zipping the file wouldn`t.

Chri

Edited 1 time(s). Last edit at 09/22/2016 03:48AM by Chri.

---

[chrisu02.wordpress.com] Quadmax Intel Delid Tools

I agree with Paul's suggestions #1 to #8. As for the rest, the real problem is that low cost reprap controller hardware has been stuck in a rut for several years, using obsolete 8-bit processors that cost more than twice as much as their modern and much more capable 32-bit counterparts. The Duet and Duet WiFi have proved that you can get good upload speeds (i.e. nearly 1Mbyte/sec) using the existing gcode format. The work involved in designing a low cost 32-bit board that costs less than Arduino/RAMPS/Pololu to mass produce would almost certainly be less than the work needed on at least 6 firmwares and at least 4 slicers to support a new gcode format.

I often try to help people who are having printing issues with particular gcode files, and the fact that gcode is human-readable is a big help.

One area where slicers could perhaps do better is to recognise when a slice through an STL model describes an arc of a circle, and to generate G2/G3 commands in such cases. This would not only shrink the gcode, it would also make performance much less dependent on the maximum jerk setting in the firmware.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Would it be a problem for the "planner" to deal with gcode without spaces and CR/LF? How would it be able to fill the buffer without splitting commands in half?

Quote
o_lampe
Would it be a problem for the "planner" to deal with gcode without spaces and CR/LF? How would it be able to fill the buffer without splitting commands in half?

RepRapFirmware accepts gcode commands without spaces between the parameters, except that you do need a space before an E parameter. This is because the standard library functions for parsing floating point numbers accept scientific notation. So for example "G1X1.1Y2.4 E1.3" is OK, but "G1X1.1Y2.4E1.3" would be treated the same as "G1 X1 Y24" and the trailing .3 would be ignored. If there is definitely no requirement for parsing scientific notation, then a dedicated parsing function could be used instead.

I haven't looked at how other firmwares parse gcode commands.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
I agree with Paul's suggestions #1 to #8. As for the rest, the real problem is that low cost reprap controller hardware has been stuck in a rut for several years, using obsolete 8-bit processors that cost more than twice as much as their modern and much more capable 32-bit counterparts. (...)

Thank you for the reality check.
As a software developer for over 20 years, and seeing the hoops that the 8 bit firmware needs to do in order to get steps out (poorly), and the inability for developers to add features due to memory and timing issues - it has always boggled my mind that people would go through the extra work to continue flogging the dead 8-bit horse. Um.. oops, I guess I was hitting it with this idea! I was hoping a pre-parsed, fixed length, more compact format would help in the long run, but I do see it is not the real answer. It would be like staying with the original IBM PC and trying to improve the floppy driver, when quad core is available for far less.

Quote
dc42
The work involved in designing a low cost 32-bit board that costs less than Arduino/RAMPS/Pololu to mass produce would almost certainly be less than the work needed on at least 6 firmwares and at least 4 slicers to support a new gcode format.

I think you are right. The investment in time should be made in the move to inexpensive 32-bit, and so I withdraw the proposal.


What in your opinion is the answer to comparable-cost 32-bit boards?

Since a 32-bit chip is not inherently more complex to put on a board, I've always thought that the slow pace of adoption of 32 bit was the time and cost of developing the firmware for a new architecture. I look at how long it's taking Smoothie to write the firmware for the Smoothie 2 (which I would buy despite the higher cost because I see the value). Chinese clones follow soon after, but often without the quality, and still cost more than 8-bit.
However, in my opinion, the development of a really cheap or more powerful Smoothieboard or Due would is still the wrong approach. Yes, still wrong - this will not harness the efficiency of scale, software, peripherals, and effort that exists cheaply elsewhere.

I think the way forward is a cheaper, better, faster way, that includes a real operating system:
- Use a Raspberry Pi 3 (1.2GHz quad core), and a PI hat, that has a small Cortex microcontroller on it to output the actual step pulses. Similar to this one, except DO NOT use an Arduino on the PI Hat! Uggh!
- Perhaps use a modified Octoprint as the front end.
- Use the already tested and elegant offloading method: Klipper.
- There would be no interfacing to peripherals with the stepper hat, so it's firmware would be very minimal. (If the PI Zero was easy to get then I would suggest that for the microcontroller on the hat - just plug it on!)

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

Quote
Paul Wanamaker
As a software developer for over 20 years, and seeing the hoops that the 8 bit firmware needs to do in order to get steps out (poorly), and the inability for developers to add features due to memory and timing issues - it has always boggled my mind that people would go through the extra work to continue flogging the dead 8-bit horse.

This 8-bit horse isn't dead for the simple reason that it works well. These small chips demand to write efficient code, which happens to be an advantage on faster chips, too. Distinction of 8-bit and 32-bit is just a compiler flag and achievable maximum speed.

Effectively you ask for opportunities to bloat the code. For which advantage? 16 MHz are enough to run commodity printers like the i3; any extra computing speed won't make the printer print any faster. Limitations are already on the mechanical side, not computing performance.

Quote
Paul Wanamaker
I think the way forward is a cheaper, better, faster way, that includes a real operating system:
- Use a Raspberry Pi 3 (1.2GHz quad core), and a PI hat, that has a small Cortex microcontroller on it to output the actual step pulses.

Yes, good idea. Connect them by serial or SPI and you're set. Works with an Arduino as well as with simple 32-bitters like Gen7-ARM. All the eye-candy on the Pi, realtime stuff on the dedicated board. Can be done now.

Quote
Paul Wanamaker
If the PI Zero was easy to get then I would suggest that for the microcontroller on the hat - just plug it on!

Wrong way. A Pi pretty much requires an operating system, which would be a step backwards. If you program this thing bare-bones, it has way to much useless stuff on the board, e.g. display stuff.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

One snag with dropping extended precision from your COMPG format...

... One day, printers will be using that resolution. Indeed, a few experimental lab printers can already exceed it.

Are you sure it is a good idea to limit the future for a more convenient present? I disagree with that thinking. The present shapes the future.

Quote
Paul Wanamaker
...
What in your opinion is the answer to comparable-cost 32-bit boards?

Since a 32-bit chip is not inherently more complex to put on a board, I've always thought that the slow pace of adoption of 32 bit was the time and cost of developing the firmware for a new architecture. I look at how long it's taking Smoothie to write the firmware for the Smoothie 2 (which I would buy despite the higher cost because I see the value). Chinese clones follow soon after, but often without the quality, and still cost more than 8-bit.

I think there are several reasons why there are no 32-bit boards of comparable cost to Arduino/RAMPS/stepsticks:

- The better 32-bit boards are manufactured to high quality standards, using good components, and tested thoroughly. Duets are manufactured in the UK, not in China. As a result, the in-service failure rate is very low. Whereas the in-service failure rate for cheap Arduino/RAMPS/stepstick parts is much higher.

- Development of good hardware and firmware costs money, so does ongoing support, and the developers of Duet and Smoothieboard need to recoup that.

- Most 32-bit boards have features that provide extra value, such as a network interface. Duet WiFi also has high-current 256x microstepping drivers, power monitoring, and measures to protect the board against common wiring mistakes. These features provide good benefits, but cost money. Arduino/RAMPS doesn't even have an adequate 5V regulator for anyone wanting to use a graphical LCD.

Quote
Paul Wanamaker
However, in my opinion, the development of a really cheap or more powerful Smoothieboard or Due would is still the wrong approach. Yes, still wrong - this will not harness the efficiency of scale, software, peripherals, and effort that exists cheaply elsewhere.

I think the way forward is a cheaper, better, faster way, that includes a real operating system:
- Use a Raspberry Pi 3 (1.2GHz quad core), and a PI hat, that has a small Cortex microcontroller on it to output the actual step pulses. Similar to this one, except DO NOT use an Arduino on the PI Hat! Uggh!
- Perhaps use a modified Octoprint as the front end.
- Use the already tested and elegant offloading method: Klipper.
- There would be no interfacing to peripherals with the stepper hat, so it's firmware would be very minimal. (If the PI Zero was easy to get then I would suggest that for the microcontroller on the hat - just plug it on!)

For now, I disagree. Your Pi-hat suggestion is IMO a good solution for those wanting additional functionality such as a webcam or slicing on the machine. But for an average user, it complicates the system configuration and use unduly, for example there is a shutdown procedure to follow instead of just turning the power switch off. An ARM Cortex M3 processor is entirely adequate to do all the motion planning and step generation - including segmentation-free delta movement - and provide a good web interface. This has been proved by the Duet. A pi-addon providing good stepper drivers, a decent 5V regulator, ADCs and the other features you need to drive a 3D printer and made to good quality standards would save less than the cost of the processor and the network socket - and you still need to add the Pi, and a WiFi adaptor if you want WiFi.

Edited 1 time(s). Last edit at 10/20/2016 03:59AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks for bearing with me as I think through this, and for your thoughts.

I do agree with you on all your first points. This is proven by the care taken with the Duet, and the integration with the display, and WIFI are excellent from what I have heard (and faster upload speeds, and I'm sure many other features). Also the support and continued development are critical. None of those things would exist without the time taken to carefully see to them, and solve the problems along the way. I have often wished for some of those features on my controller - only every time I use it.

Thank you for taking time to clarify the 2nd part. I am still pondering it, and so I will ponder a bit here. Yes, there would still be a great deal of time needed to properly develop the hardware and software, even on top of a PI. Certainly a controller that is specifically made just for 3D printing will have a better focus on what we need than a general purpose controller.

There are many in this community however that are willing to put up with the crap troubles that you get with an 8-bit knockoff - just because it is cheap. (Made by people that did not design the original, have had no hand in developing or maintaining the firmware, and so do not innovate in any way except on making it cheaper yet, with virtual slave labor, with lower quality, and with less support). Some will swear that is fine, and I'm sure it is, for some. Not for me. Having had both Chinese hardware (name withheld) and now a 32 bit controller, I certainly have no desire for the former. I can only shudder when I look back at the needless troubles and waste of time, more than the money.

So I've had an adjustment in my thinking over time, that quality is very worth investing in, and the controller and it's firmware - the heart of the machine - can not/should not be the cheapest part.

Perhaps part of my struggle is that I see that the problems that I still have to this day with my 32-bit controller (fairly minor, tho annoying they may be) would never have been a problem had the controller been made on top of a Pi: I'd have good fast communications via both Ethernet and USB (and WIFI), good fast web interface, a very nice display, and rock solid SD card support. Other than that it works fine...

So I guess what I really want is --- what you already provide. Hmmm...

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

Quote
Paul Wanamaker
...
Perhaps part of my struggle is that I see that the problems that I still have to this day with my 32-bit controller (fairly minor, tho annoying they may be) would never have been a problem had the controller been made on top of a Pi: I'd have good fast communications via both Ethernet and USB (and WIFI), good fast web interface, a very nice display, and rock solid SD card support. Other than that it works fine...

So I guess what I really want is --- what you already provide. Hmmm...

Yes, it sounds to me that you need a Duet or a Duet WiFi and a PanelDue.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].