1.6.2: Serial command seq fail due to line nr error

[duisenberg]

Nice to see a xmas update:)

But ... MC 1.6.2 (8094) comes with a serious serial communication issue: Command line number sequence error.

This is how it looks like in Terminal:

After a "Reset Connection" it seemed to work but starting a print it ran the nozzle into bed. Had to revert to 1.6.1.

[didli]

Exact same problem here with same workaround, but with MatterControl 1.6.1 in Linux. The nozzle didn't crash into the bed but it's way off (starting gcodes not working), and there's no extruder or bed temp readings until I reset connection. Reverting back to 1.6.0 seems to works just fine.

[unlimitedbacon]

Another user running into the same problem. See last post. http://forums.matterhackers.com/topic/414/the-printer-stops-printing-when-printing-bridges/11

Also Scott was reporting trouble connecting to a MakeIt Pro-L today. It sounded like it was the same issue. Since so many people are running into this, I think this should be showstopper for the 1.6.2 stable release.

[duisenberg]

To catch up with things ... the issue already is present using 1.6.1 (Windows) but for some reason MC and Marlin manage to negotiate that and stay in sync. See attached serial protocol dump.
print_log.txt

[duisenberg]

Might it be that Marlins M110 is classically simply ignoring its parameters and starts by default with line one expecting N2 to be the next line with a command?

->Communication State: PreparingToPrint
->N1 M110 S1*96
<-ok
->M105
<-ok T:208.1 /195.0 B:45.9 /45.0 @:0 B@:0
->M105
<-ok T:207.3 /195.0 B:45.8 /45.0 @:0 B@:0
->Communication State: Printing
->N2 G21*24 [0.018]

(printer log as taken from 1.6.1 starting a print. )

If so, it should be quite easy to fix the 1.6.2 issue simply by starting with N2 as first line after M110 instead of N1.

[duisenberg]

The issue is related to Marlin, present I guess since May 2016 where M110 has been subject of change.

In order to use Marlin 1.1.0 RC8 with Mattercontrol 1.6.2 Marlin_main.cpp (near line 5658)

/**
 * M110: Set Current Line Number
 */
inline void gcode_M110() {
  if (code_seen('N'))  gcode_N = code_value_long(); 
}

has to be changed to

if (code_seen('N')) { gcode_N = code_value_long(); gcode_LastN = gcode_N; }

Though - there still is an issue with Mattercontrol 1.6.2 using line numbers:

<-ok T:12.2 /0.0 B:13.0 /0.0 @:0 B@:0
->N49 M105*26
<-ok T:12.2 /0.0 B:13.0 /0.0 @:0 B@:0
->N50 M105*18
<-ok T:12.2 /0.0 B:12.9 /0.0 @:0 B@:0
->N51 M105*19
<-ok T:12.2 /0.0 B:12.8 /0.0 @:0 B@:0
->N52 G28*36 
<-echo:busy: processing
<-echo:busy: processing
<-echo:busy: processing
<-echo:busy: processing
->N52 G28*36
<-Error:Line Number is not Last Line Number+1, Last Line: 52
<-Resend: 53
<-ok
<-echo:busy: processing
->N53 M105*17
<-echo:busy: processing
<-echo:busy: processing
<-echo:busy: processing
<-echo:busy: processing
<-echo:busy: processing
->N53 M105*17
<-Error:Line Number is not Last Line Number+1, Last Line: 53
<-Resend: 54
<-ok
->N54 M105*22
<-echo:busy: processing
<-X:129.00 Y:94.00 Z:10.78 E:0.00 Count X: 10320 Y:7520 Z:4312
<-ok
<-ok T:11.7 /0.0 B:12.8 /0.0 @:0 B@:0
<-ok T:11.7 /0.0 B:12.8 /0.0 @:0 B@:0
->N55 M105*23
<-ok T:12.4 /0.0 B:13.3 /0.0 @:0 B@:0
->N56 M114*20

Seems to be the timeout for commands like G28 is a bit low.

[unlimitedbacon]

The latest alpha version (1.6.2.8214) should be fixed to handle this. Can you try it?

[duisenberg]

Printer log snippet is from 1.6.2.8214 which I switched to directly after uploading the patched RC8 to the machine. So it already contains the referenced commit.

The lasting issue seems to come from re-injecting a command while Marlin still is processing it, As shown this happens with G28 (and also with G29 at print start), too in some rare cases within a print - like 5 times for 100k+ commands.

Might be in PrinterConnectionAndCommunication.cs adding a callback for "echo:busy" to increase the timeout waiting for ok and to delay M105 could help to avoid unnecessary resends.

Not sure how #1787 comes in here, but a look into the printer log will help to see what is happening there.

[unlimitedbacon]

Just to clarify, 1.6.2.8214 should have fixed your original issue with the M110 command. Can you verify that it is working now with an unpatched version of Marlin?

I am much less concerned about the issue with G28 taking too long to process. Although the situation is not ideal, there should actually be no negative effect since the printer ignores the extra commands with the same line number. If it is actually causing problems during printing, can you open another issue? I think it is best to have a single thread for each bug.

[duisenberg]

Reuploaded an unpatched Marlin to the machine ... yes, I can positively confirm that 1.6.2.8214 also prints with the unpatched Marlin 1.1.0 RC8.

The premature resend actually does not seem to cause major issues. Agree its best to open a separate issue for that, so this is #1832 by now.