daid
commented
11 years ago I'm not seeing something wrong in the log. The code is designed so it can receive multiple messages in a FIFO buffer and process those.
I think your patch just counters this design in a bad way. I'm not sure what software you use to send GCode to the Creatr. But Cura has extensive logging and error case catching in it's GCode sender. And the only case that I see where communications go wrong on an Ultimaker with Cura is when the USB connection itself craps out.
DavidH137
nophead
ODDepot
thinkyhead
michielha
ErikZalm
github-actions[bot]
I have not been able to create a large print using this Marlin code without the printer just stopping in mid-print. The computer does not hang but the print job is ruined.
I patched the code (described after the debugging) and would love to better understand why this fix would solve the stopping problem. (it serialized get_command processing with end of process_command completing).
I did some debugging, as described below and found:
The following was found to be a common problem when the printing stopped. These characters (or a variation of them) were in the log:
&$?ok ?ok ok LLNM$?ok
I had seen some of the “ok” messages before but most of the time I did not see the “ok” message, so I inserted some code that caught every stop in mid-print and every stop had the “ok” message. To debug do the following:
in module Marlin_main.cpp insert the following and reload the firmware:
void process_commands() { unsigned long codenum; //throw away variable char *starpos = NULL; // insert debug code above above char statement SERIAL_ECHO_START; SERIAL_ECHOPGM(“Command: “); SERIAL_ECHO(cmdbuffer[bufindr]); SERIAL_ECHO(” Last N: “); SERIAL_ECHOLNPGM(“”); // end debug code
This will result in messages in the log just before the stop like:
20:21:11.302 : N814 G1 X29.251 Y1.984 E2563.721 64 20:21:11.305 : echo:Command:N813 G1 X156.142 Y128.875 E2552.526 125813″ 20:21:16.652 : N815 G1 X30.036 Y1.985 E2563.77 127 20:21:16.684 : echo:Command:N814 G1 X29.251 Y1.984 E2563.721 64814″ ok 20:21:16.688 : echo:Command:N815 G1 X30.036 Y1.985 E2563.77 *127815″
18:26:08.799 : echo:Command:N311 G1 X23.858 Y200.94 E135.052 74311″ 18:26:08.828 : N313 G1 X51.72 Y228.016 E137.5592 115 18:26:09.713 : echo:Command:N312 G1 X23.858 Y200.154 E135.1011 6631&$?ok 18:26:09.717 : echo:Command:N313 G1 X51.72 Y228.016 E137.5592 115313″
16:44:52.400 : N1196 G1 X32.757 Y1.459 E5.05497 74 16:44:52.510 : echo:Command:N1195 G1 X23.333 Y10.882 E4.47453 122LLNM$?ok 16:44:52.514 : echo:Command:N1196 G1 X32.757 Y1.459 E5.05497 741196″ 16:45:41.100 : N1197 M105 57 16:45:41.106 : echo:Command:N1197 M105 571197″ 16:45:41.114 : echo:Exit M105 16:45:41.115 : N1198 G1 X33.58 Y1.459 E5.09082 113 16:45:41.126 : echo:Command:N1198 G1 X33.58 Y1.459 E5.09082 *1131198″
You will notice that the order of the echo of the commands is not aligned with the normal log of the command. I found this to be the key to solving the problem. I found that the Marlin code has a problem with how the buffer is handled to ensure each line of gcode is executed before the next line of gcode is sent to the printer.
I came up with a fix for this as described below.
The objective of this patch is to cause the Marlin code to process one command at a time, and to not proceed with processing another command until the previous command has completed. I’m not sure why this works as the Arduino board should only process code in sequence (I think), but it worked for me. I suspect it fixes an error in the way the buffer is filled with commands to print that causes an “ok” garbled message to be sent to the printer which causes the code to halt.
In Marlin_main.cpp after the #includes put the following statement:
boolean tnext = 0;
Same module add a line in void setup() after the first { (left bracket) as shown below
void setup() { tnext=0;
Same module add the following after the first { in void get_command()
while (tnext != 0) { delay(1); }
This causes the get_command to loop until the previous command has been processed.
In the same module void process_commands() do the following:
After the first { enter the following line:
tnext = -1;
Before EVERY “return;” and before EVERY “break;” enter a line with:
tnext=0;
If you miss one “tnext=0″ the code will not be set to allow the loop in get_command() to end.
In the same module, in void ClearToSend() add the following just before the } (ending bracket)
tnext=0;