"Line Number is not Last Line Number+1" right after Controller Connect

[mj1911]

Desktop

• OS: Windows 7 x64
• Slic3r Version: 3.1.0 and later, latest being Slic3r-master.2019.07.21.2351.66af505d.64bit-PR.zip

3D Printer

• Brand: Creality
• Model: Ender-3
• Firmware: The latest few versions of Marlin-Bugfix 1.1.x on a stock Creality Meltzi (Sanguino) board with ATmega1284P microcontroller. Changing the firmware is rather involved as there is no room for a bootloader (it must be recompiled and flashed using a programmer.)

Describe the Bug Something about this Marlin firmware makes it impossible to use 3.1.0 or any later dev build of Slic3r as a printing host, and always gives the title errors upon connect. Cura however, has no problem printing over USB to it. It seems others have gotten this line number error (in the middle of a print due to flaky USB connection) but my issue isn't a loss of data - it simply flakes out upon connect, preventing any printing at all. I'd rather use Slic3r and do not like being forced into using Cura, so hope we can troubleshoot and squash this.

To Reproduce Steps to reproduce the behavior:

1. Connect Printer USB and power it on.
2. Click on Controller tab in Slic3r.
3. Click connect button.
4. Wait (about 5 minutes for all error lines to appear.)

Output.txt is a full capture of the controller log, at which point it stops reporting the error but still is unresponsive. The controller tab does show updating nozzle and bed temps, so is communicating. However the manual control does not work to move the axes or adjust temps and of course it cannot print anything.

More Data At one time, Slic3r 3.1.0 did work with this printer, along with Cura 4.0. I updated the printer's firmware to (a now older) Marlin 1.1.x bugfix and heavily customized it, and both hosts still worked fine. Then I rebuilt a newer bugfix firmware and changed much less on it, and now Slic3r exhibits these line number errors on connect, making hosted printing impossible. The Marlin bugfix firmware is a single rolling-release version, so I cannot revert to a previous one. Tried two more since then with the same results.

Issuing a M110 N0 resets the line number count to 0, but they just continue (now as line 0) and no longer increment.

The COM port appears fine in Windows. Port settings are default, but adjustments have been tried with zero improvement.

I did copy most of the Start and End g-code from Cura, so these look like the following. I think this isn't relevant however, as the issue happens on connect, not on job start:

What I Think is Going On Either Slic3r is receiving unexpected data from the printer firmware, the printer is not sending the expected data, and/or timing issues leading to a line number mis-match. There are serial buffer sizes in the firmware; perhaps these are expected to be a certain size. But I'm not sure it's the correct 'fix' to require specific firmware settings for compatibility (and there are a lot of firmware settings.) Alas, because the latest firmwares were less modified than the first one, I really doubt it is something I specifically changed, and this issue should be more common among the less-ambitious.

[lordofhyphens]

The printer firmware expects a different line number if it hard resets and nothing I've done seems to work save resetting the printer; I've tried.

[mj1911]

Noticed three interesting things:

1. Whenever the serial USB is connected, the printer does at least one hard reset, sometimes two or three. By "hard reset" I mean the Ender-3 logo is displayed, followed by the Marlin logo, then the normal screen.
2. Whenever the "connect" button is pressed in Slic3r controller, the printer also does a hard reset, only once, every time.
3. The initial spam of data from the printer to the PC seems to occur after the Ender3 logo, but before the Marlin logo.

This had me thinking, perhaps both of these logos are somehow interfering with Slic3r's "initialization," whereas Cura does not reset the printer, so does not experience the printer from a boot?

So I went into the firmware build and disabled both boot logos (and enabled serial buffers) and uploaded it. Now it boots much quicker (no logo screens) and Slic3r seems to be working! It gives ONE "line is not last line+1" but then doesn't seem to report this again. Here is the serial log after trying a few manual moves and home:

echo: External Reset Marlin bugfix-1.1.x echo: Last Updated: 2018-07-31 | Author: (thisiskeithb, Ender-3) echo:Compiled: Aug 18 2019 echo: Free Memory: 10445 PlannerBufferBytes: 1488 echo:EEPROM version mismatch (EEPROM=? Marlin=V55) echo:Hardcoded Default Settings Loaded Error:Line Number is not Last Line Number+1, Last Line: 0 echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0`

This one message is a little concerning, but I just successfully printed something in Slic3r for the first time in months. So it seems that timing of the boot screens can cause this. Reset defaults and the one message is still there. I'll keep chipping away at this and see if anything changes.

[Jedrusia]

Friend. I have identical problem. Please write how You resolved problem (in detail please). My issue problem: https://github.com/slic3r/Slic3r/issues/4854#issuecomment-524019719

[Jedrusia]

@mj1911

can you attache or tesxt presend the start and stop gcode for Your Ender-3 printer ? Thanks

[mj1911]

Hi Jedrusia. The start and stop gcode were simply copied from Cura and changed slightly. I suggest you do that as a new version of Cura was just released and they probably have updated it.

My problem (and perhaps yours also) seems to be that, when the connect button is pressed, Slic3r is expecting to hear a response from the printer within a certain amount of time. If anything slows the printer down (such as a spurious reboot, incorrect serial port settings, extra logo screen upon start-up, etc.), a "line number" can be skipped and results in these messages and a terminal connection. I'm sure this explanation is not 100% inclusive of all reasons for this error.

My specific problem was due to me updating the stock Ender 3 firmware with the latest Marlin bugfix firmware. The default settings for this Marlin firmware had the Marlin logo enabled only. There are settings to display the Ender 3 logo, so I enabled that (figured it would replace the Marlin logo, but it did not, it created a second logo.) When Slic3r attempted to connect to this new printer firmware, it forced the printer to reset, then waited for the printer to respond. But the printer could not respond in time because the extra logo screen took too long. My solution was to disable these boot logos in the printer firmware. Likely just disabling one of them would have been sufficient. I hope that is helpful but again, there can be many reasons for this error.

[7eggert]

You can send commands without line numbers to set the next-expected line number: M110 N$nextline (without line number in front)

Also you could buffer the last n lines and resend the last lines in case of a few lost lines (and not a printer reset). I've programmed something like that but there is still a bug in my code. If I'll have time I shall publish it. I'm already using it to print gcode from the command line.

[alranel]

I fixed this now. It works with the latest Marlin. I'm not sure about how robust the fix is.

[zenodallavalle]

I just finished to assembly my Geetech i3 b plus which came with Marlin 1.0.5 and I wanted to connect with slic3r. I encountered the same problem described at the beginning. So I upgraded to Marlin 2.0.9.3, but the problem was still there. I also changed baud rate to 152000 without solving the problem. Commands sent from other programs over serial works fine, just slic3r is not working properly. I've noticed that command is finally executed but the latency between command and execution is variable and it's very long (in some cases over 1 minute). Cannot understand if problem is to consider solved by turning off boot screen or should be solved in other ways.

Using Mac OS X 12.3.1 on M1-Pro Macbook machine.