Question: Checksum and line numbers on host when canceling print

[Kaibob2]

I tested lin_advance and like the WIKI says it is recommended to

Ensure your print host software is using line numbers and checksums, this is disabled by default in Simplify3D.

so i enabled it in S3D. Now the problem is: When i start a print everything is working fine. Now i decide to cancel this print and click the "Stop" button in S3D machine control window. The print stops like expected. When i exit the machine control window. Change some parameters in the FFF profile and start a new print the printer behaves weired and tries to continue the previous print. The log file says something like:

Line number not last line number+1 Resend

When i disable line numbers and checksum, after stopping a print and starting a new one it starts with the start script (G28, ....) like expected.

[thinkyhead]

Are you able to tell the means by which S3D is stopping the print? Because, actually, there's no GCode to abort a print. So all a host can do is pause it.

[thinkyhead]

@MarlinFirmware/host-software-team Strange oversight, but apparently there's no GCode to (properly) abort a print from SD card. It can only be aborted through the LCD menu. Is there some reason you can think of why this was never implemented?

[Kaibob2]

This has nothing to do with printing from SD. I'm talking of printing via S3D over USB.

When line numbers are disabled and i stop the print in S3D (see picture below) i suspect that S3D pauses sending Gcode to the printer. When i start a new print a new set of Gcode is created including the start code like G28 and so on. I remove the aborted object from the bed and the print starts. Everything fine

When line numbers are enabled Marlin responds to the new Gcode set with: Line Number is not Last Line Number+1, Last Line: S3D does Resend

The strange thing is, that it doesn't do a G28 which is the first line in the new set, but continues with the print it did before.

I'm not at home right now, i will check exactly what get's sent when by S3D after a stop Button click.

As i'm writing this i start to think that there is nothing that could be done from Marlins side...

[foosel]

Sounds like S3D is not sending an M110 N0 as the first line on print start when you have line numbers and checksums enabled, and doesn't persist the last line number it sent either. No wonder stuff gets out of synch then, Marlin is behaving correctly there. Sounds like a bug in the host component of S3D.

Re cancelling SD prints, I guess that was never implemented because pausing and rewinding the file is a viable workaround. At least that's what OctoPrint is doing when cancelling an sd print.

[thinkyhead]

start to think that there is nothing that could be done from Marlins side

I think you're right on this count. If the host fails to follow the protocols mysterious things may occur.

pausing and rewinding the file is a viable workaround

Interesting, I'd never have thought of that. Admittedly a full "Stop print" is pretty drastic since it invokes a quick-stop of the steppers, so that's a reasonable workaround.

If we were to add a proper Stop SD Print G-Code, it might reasonably be M25 S or M34, and it need not necessarily do a quick-stop, but just finish the current move in the planner and then stop.

[Kaibob2]

In my opinion there is no need for a SD stop print Gcode because whether you are printing from SD and have a Display to start, stop, pause or you print via USB and do start, stop, pause in the host.

Offtopic: A nice feature would be to lift the toolhead a little or at least retract when pause SD is selected via display. Now, when you select SD Pause the hot toolhead melts the print object and, if it stops on a perimeter, it leads to a defective print.

[kakaroto]

Offtopic: A nice feature would be to lift the toolhead a little or at least retract when pause SD is selected via display. Now, when you select SD Pause the hot toolhead melts the print object and, if it stops on a perimeter, it leads to a defective print.

In Cura LE, a Pause will do a retract, lift, and move the toolhead away into a 'park position', I think it would be a good idea to implement it in Marlin for SD printing as well.

@thinkyhead

@MarlinFirmware/host-software-team Strange oversight, but apparently there's no GCode to (properly) abort a print from SD card. It can only be aborted through the LCD menu. Is there some reason you can think of why this was never implemented?

Never thought of having a need for that, If you print from SD, you do it from LCD from start to finish, if you print using USB, you do it from the host from start to finish (just like there's no way to pause/cancel a USB host print using the LCD). I think though that having the possibility of doing it would be good, I just never took it into consideration.

[foosel]

If you print from SD, you do it from LCD from start to finish

Um... No. I print a lot from SD, but starting the print and monitoring it through the host. Including transferring the file to the printer's SD by using a WiFi SD card.

[Kaibob2]

This is what happens when i click the stop button in S3D: The print stops immediately The log shows only M105 responses Then i start a new print with a new set of Gcode: LOG output:

READ: ok T:32.1 /0.0 B:99.7 /100.0 T0:30.9 /0.0 T1:32.1 /0.0 @:0 B@:0 @0:0 @1:0
SENT: M105
READ: ok T:31.9 /0.0 B:99.4 /100.0 T0:30.8 /0.0 T1:31.9 /0.0 @:0 B@:127 @0:0 @1:0
SENT: M110
SENT: N1 G90 *49
SENT: N2 M82 *59
SENT: N3 M106 S0 *68
SENT: N4 M140 S100 *64
READ: ok
READ: Error:Line Number is not Last Line Number+1, Last Line: 2055
READ: Resend: 2056
READ: ok
SENT: N2056 G1 X84.463 Y113.889 E17.2647 *69
READ: ok
SENT: N2057 G1 X84.458 Y113.870 E17.2655 *73
READ: ok

I tried to send a M110 N0 between the stop and start manually. It changed nothing. The print continues with the previous print. Even if i print a different part than before it continues from the line in the new Gcode.

There are only two ways to avoid this: Reset the printer, or diable checksums and line numbers

[thinkyhead]

the stop button in S3D

@KaiBob2 Definitely a bug in S3D. OctoPrint apparently does the "right" thing to work around the lack of a real stop command, because it doesn't have this issue. So if I were you, I would write to the creators of S3D and advise them that they should emulate the technique used there. From what I can gather OctoPrint uses M26 S0 to reset the SD file position.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.