Unable to print large 3d model. stepcompress o=5 i=0 c=21 a=0: Invalid sequence Internal error on command:"G1"

[aredon2-wgu]

klippy.log

I am trying to print a very large model and it has failed 4 times in the same spot with that error

I'm running Klipper on a raspberry pi 3B+ with a modded cr-10 & SKR E3 V2.0
Platform_11hrs.gcode.txt

See Line 2704 in the klippy.log

I also included the gcode I am trying to print, just remove .txt extension.

[bevanweiss]

I'd say it's this bit causing the problem

Stats 2400.4: gcodein=0 mcu: mcu_awake=0.007 mcu_task_avg=0.000014 mcu_task_stddev=0.000034 bytes_write=1049876 bytes_read=815521 bytes_retransmit=9 bytes_invalid=0 send_seq=39996 receive_seq=39996 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=71998036 sd_pos=39586 heater_bed: target=70 temp=70.2 pwm=0.184 sysload=0.13 cputime=184.838 memavail=760804 print_time=2408.038 buffer_time=3.206 print_stall=1 extruder: target=230 temp=229.9 pwm=0.698
Got EOF when reading from device
Stats 2401.4: gcodein=0 mcu: mcu_awake=0.007 mcu_task_avg=0.000014 mcu_task_stddev=0.000034 bytes_write=1049890 bytes_read=815521 bytes_retransmit=39 bytes_invalid=0 send_seq=39997 receive_seq=39996 retransmit_seq=39997 srtt=0.001 rttvar=0.000 rto=0.100 ready_bytes=0 stalled_bytes=15 freq=71998036 sd_pos=39586 heater_bed: target=70 temp=70.2 pwm=0.184 sysload=0.13 cputime=184.878 memavail=760028 print_time=2408.038 buffer_time=2.205 print_stall=1 extruder: target=230 temp=229.9 pwm=0.698
Stats 2402.4: gcodein=0 mcu: mcu_awake=0.007 mcu_task_avg=0.000014 mcu_task_stddev=0.000034 bytes_write=1049890 bytes_read=815521 bytes_retransmit=39 bytes_invalid=0 send_seq=39997 receive_seq=39996 retransmit_seq=39997 srtt=0.001 rttvar=0.000 rto=0.100 ready_bytes=0 stalled_bytes=181 freq=71998036 sd_pos=39586 heater_bed: target=70 temp=70.2 pwm=0.184 sysload=0.13 cputime=184.932 memavail=759732 print_time=2409.288 buffer_time=2.454 print_stall=1 extruder: target=230 temp=229.9 pwm=0.698
Stats 2403.4: gcodein=0 mcu: mcu_awake=0.007 mcu_task_avg=0.000014 mcu_task_stddev=0.000034 bytes_write=1049890 bytes_read=815521 bytes_retransmit=39 bytes_invalid=0 send_seq=39997 receive_seq=39996 retransmit_seq=39997 srtt=0.001 rttvar=0.000 rto=0.100 ready_bytes=0 stalled_bytes=316 freq=71998036 sd_pos=39586 heater_bed: target=70 temp=70.2 pwm=0.184 sysload=0.13 cputime=184.979 memavail=759620 print_time=2410.288 buffer_time=2.453 print_stall=1 extruder: target=230 temp=229.9 pwm=0.698
Stats 2404.4: gcodein=0 mcu: mcu_awake=0.007 mcu_task_avg=0.000014 mcu_task_stddev=0.000034 bytes_write=1049890 bytes_read=815521 bytes_retransmit=39 bytes_invalid=0 send_seq=39997 receive_seq=39996 retransmit_seq=39997 srtt=0.001 rttvar=0.000 rto=0.100 ready_bytes=0 stalled_bytes=448 freq=71998036 sd_pos=39586 heater_bed: target=70 temp=70.2 pwm=0.184 sysload=0.13 cputime=185.012 memavail=759796 print_time=2411.038 buffer_time=2.203 print_stall=1 extruder: target=230 temp=229.9 pwm=0.698
Timeout with MCU 'mcu' (eventtime=2405.400208)
Transition to shutdown state: Lost communication with MCU 'mcu'

Klipper lost comms to the mcu during motion, which is what I suspect then caused the stepcompress code to throw an error since it wasn't getting data it wanted from the mcu.
Unsure why it would keep happening in the same place however. There's nothing weird like the USB cable draped over the Z axis that might be disturbing the USB cable as the print progresses (hence why it would be losing comms at roughly the same place in a large print)

[jalanjarosz]

This is also in the log:

Got EOF when reading from device

Double check that the gcode file on your SBC/PC is complete as well.

[bevanweiss]

This is also in the log:

Got EOF when reading from device

I suspect the EOF is for the USB virtual serial port, EOF is generally reported if the serial port connection is broken.
It's an easy enough check to confirm g-code file can be opened, and matches expected size. But I'd focus on the serial comms dying, that's what the error is most likely from.

[aredon2-wgu]

Thank you for such a quick response to all of you. I really appreciate it.

What else could be causing an "EOF when reading from device" ?

I'm not sure that is the issue, because the way I have the board mounted, the USB cable that connects the raspberry pi to the MCU does not move at all. So it is in the same position. I have been printing all day with the printer just fine. It is only this larger model that fails. And the failure position is around the x/y home position which every day it homes there just fine. I also have all of the wires that go to the hotend strain relieved with cable ties. See the pictures attached. I am using Cura to generate code using Marlin flavor. Is there something I need to change in cura? I sometimes see errors while printing that certain gcode cannot execute, but still prints just fine.

Here is my cura printer setup. Maybe the issue lies here?

Please let me know what information I can provide to help troubleshoot this issue.

[aredon2-wgu]

I am on Cura Version 4.9.1 btw. Could it be because I am not updated in Cura?

[aredon2-wgu]

[bevanweiss]

I am on Cura Version 4.9.1 btw. Could it be because I am not updated in Cura?

No, it's definitely a problem downstream of Cura.
It might be a bug in the Klipper firmware that is causing the mcu to restart/stop responding. It might be worth looking in the linux logs for an USB events around the time things go bad.
Have you found any way to reproduce the issue outside of the big print?
Do smaller prints work fine?

You could try it without filament (if you haven't already), if it still errors at about the same z height, then you could remove a large chunk of the prior gcode and try again (to see if it's position related, or gcode size related).

[aredon2-wgu]

klippy (1).log

I tried SSH into the PI and did sudo update and sudo upgrade but still had the same issue in the same spot of the print.

[aredon2-wgu]

Updated cura and re-sliced the model in a different position and still failed in the exact same spot in the gcode.

What else can I provide to help figure this bug out? I have no idea how to fix this.

[aredon2-wgu]

I confirmed that "Internal error on command:"G1" " happens before the MCU connection loss.

[aredon2-wgu]

I am still having this issue. Are there any updates or things I can check to help troubleshoot?

[aredon2-wgu]

It seems the trouble is when printing objects that are very near the bounds of the print bed volume

[aredon2-wgu]

The model was bigger than the build volume, I somehow bypassed this by accidentally changing the cura printer settings to the wrong size. (bigger than the volume) which allowed me to print an unprintable file.

[bevanweiss]

I would have argued that this is still a valid 'bug' within Klipper.
Klipper's behaviour should have been better.
It shouldn't have allowed the original G1 toolpath to be sent to the MCU because as you mention it was out of bounds for the printer.
And if the MCU did receive a movement request that was outside of valid ranges (for its calculations or valid movement) then it should have triggered a shutdown with a more appropriate report message (so that time wasn't spent looking at other potential issues).

The issue would be for someone else to really investigate this it would to have a much more trivially reproducible example.
So gcode that was only a few lines long ideally, and an associated common printer config that would reproduce it.