[Bug] SDCARD_LOOP_END not respected at end of file

General Discussion
1

Basic Information:

Printer Model: Ender 3
MCU / Printerboard: Creality melzi-ish 1.1.8
Host / SBC: Radxa Zero 3e Selfhost
klippy.log (too big, stats lines removed) klippy-nostats.log (1.8 MB)

Describe your issue:

Given G-CODE that contains an SDCARD_LOOP_END as the last line of the file, the printer completes the loop once, and ends.

If a command is added after the SDCARD_LOOP_END, it functions as expected.

Expectation: SDCARD_LOOP_END should function as documented, even when it is the last line in the file.

Example:

G21 ; Metric
G90 ; Absolute

G28 ; Home all

G0 Z150 ; Get Z out of the way

M190 S60 ; Heat plate
G0 Y210 ; Present plate
BEEP
M0 MSG="Insert Payload"

SDCARD_LOOP_BEGIN COUNT=0
G0 Y150
G0 Y50
SDCARD_LOOP_END

Functional Example

; [same as prior]
SDCARD_LOOP_BEGIN COUNT=0
G0 Y150
G0 Y50
SDCARD_LOOP_END
M400
2

@Laikulo ,

  1. You can compress your klippy.log to a zip file if itā€™s too big.
  2. Iā€™ve seen a similar issue, where the last command in a G-code file isnā€™t executed. The solution is to add an empty line at the end of the file.
1 Like
3

Did a few test runs, and found that the last line does not appear to be parsed if it does not have an EOL (either dos or unix style)

For example, this file leaves the display at ā€œThis line has an EOLā€

ohmega% cat testing.gcode 
M117 Testing Gcode Bounds
M117 This line has an EOL
M117 This line has no EOL%
ohmega% xxd testing.gcode 
00000000: 4d31 3137 2054 6573 7469 6e67 2047 636f  M117 Testing Gco
00000010: 6465 2042 6f75 6e64 730a 4d31 3137 2054  de Bounds.M117 T
00000020: 6869 7320 6c69 6e65 2068 6173 2061 6e20  his line has an 
00000030: 454f 4c0a 4d31 3137 2054 6869 7320 6c69  EOL.M117 This li
00000040: 6e65 2068 6173 206e 6f20 454f 4c         ne has no EOL

Peeking at ISO NC, it does state that all blocks must end with the end of block character (and that the program should start with the same). However, klipper doesnā€™t support other mandatory parts of ISO NC, so I am unsure if this is intended behavior.

I wrote this particular NC prog by hand in fluiddā€™s editor (backed by moonraker).

If klipper takes the stance that this is invalid NC, then this is either a moonraker or fluidd bug, and klipperā€™s gcode docs should be updated to include a note that end of blocks are required.
If klipper intended to be tolerant of this, an adjustment in virtual_sdcardā€™s work_handler in the EOF case to dump out partial_input into lines, and terminate on the next time around.

Either way, it might be nice to throw a warning if EOF is found when partial_input is not empty.

4

For what itā€™s worth, Iā€™ve raised a PR to be tolerant of missing EOLs at the end of files.

It does have the fun side effect of showing 101% on the display at the end of a file with no terminal newline.