So now that I can auto-level, I fired up eagle, created a simple board,

So now that I can auto-level, I fired up eagle, created a simple board, auto leveled, then sent the auto leveled gcode to the work space.

Somewhat to my surprise, I got complaints back from the grbl controller about ‘bad number format’ for all the comment lines. Once it hits real work, all is well.

The code runs fine if I don’t auto level it, so something in the auto level process is making changes grbl doesn’t like.

The original file is linked below.

As I said, doesn’t impact function, but Thought You Might Like To Know.

Auto-level in ChiliPeppr does add inline comments to each line it modifies so it can show you the original Z and then the new Z, but I have never heard that not being ok for Grbl as that’s a standard format for Gcode. That’s the only thing I can think of maybe being the issue. I suppose it’s always possible to add a toggle switch to the Auto-Level widget that turns that feature off if that solves your problem.

It is unlikely to be a genuine problem with the way that CP creates numbers or comments.

I suspect that the error is actually unhelpfully reported and relates to one of the following

  1. Pushing too much data for the buffer. Solution: make sure that the latest version of sjps is being used

  2. The gcode may contain some commands that cause problems later on. Ie is there are any commands which change the startup blocks or any settings then these should not be sent as part of a streamed programme. The reason is that the atmega328p writes these settings to eeprom and eeprom writes are very slow. Further, in order to ensure data integrity during the write process interrupts are disabled which then cocks up serial comms. Characters are dropped. I cannot validate this against the code being used as the linked file isn’t viewable for some reason. Perhaps the hosting site is down.

  3. Baud rate is too slow. The atmega328p has an inaccurate clock which means streaming at low baud rates causes dropped characters. There are also some reported issues at 115200 but personally I’ve found that ok. Basically at a minimum go higher than 57600 baud. Baud rates are changed pre-compile in config.h

I’d suggest the order of likelihood is 3-2-1 of the above possibilities.