I am not sure if this post adds any value to the discussion, but I coincidentally just experienced an internal error in step compress while using mainline Klipper. Note that this was not while printing - I am (extremely slowly) putting together my Voron 2.4 and am currently testing the electronics and the WIP wiring.
I am using Duet 3 Mini 5+ and was in the process of experimenting with Orbiter 2, trying to establish it’s steady-state operating temperature. To do this, I initially issued the following command G1 E120 F6
, but then decided I needed the feed to last even longer. So I then issued G1 E120 F0.6
. This did not have the desired outcome leading to a shutdown. Here is an excerpt from the log, with full log attached below:
stepcompress o=16 i=0 c=2 a=0: Invalid sequence
stepcompress o=16 i=0 c=2 a=0: Invalid sequence
stepcompress o=16 i=0 c=2 a=0: Invalid sequence
stepcompress o=16 i=0 c=2 a=0: Invalid sequence
stepcompress o=16 i=0 c=2 a=0: Invalid sequence
Exception in flush_handler
Traceback (most recent call last):
File "/home/pi/klipper/klippy/toolhead.py", line 392, in _flush_handler
self.flush_step_generation()
File "/home/pi/klipper/klippy/toolhead.py", line 337, in flush_step_generation
self.move_queue.flush()
File "/home/pi/klipper/klippy/toolhead.py", line 175, in flush
self.toolhead._process_moves(queue[:flush_count])
File "/home/pi/klipper/klippy/toolhead.py", line 333, in _process_moves
self._update_move_time(next_move_time)
File "/home/pi/klipper/klippy/toolhead.py", line 286, in _update_move_time
sg(sg_flush_time)
File "/home/pi/klipper/klippy/stepper.py", line 226, in generate_steps
raise error("Internal error in stepcompress")
error: Internal error in stepcompress
Transition to shutdown state: Exception in flush_handler
klippy.zip (48.7 KB)
I realize that I requested a ludicrously slow feed rate over a ludicrously long extrusion length and this will likely never happen in a real print situation, but I thought it might be worthwhile reporting this internal fault nonetheless.
EDIT1: Even more interesting is that issuing numerous sequences of FIRMWARE_RESTART
, RESTART
or klipper service stop
and klipper service start
following this fault is not successful and results in mcu 'mcu': Unable to connect
errors. A full power cycle or (very strangely) a Raspberry Pi reboot is required to re-establish communication with the mcu. This would suggest that something “breaks” on the host.
EDIT2: My above suggestion that this is host side only is incorrect. Based on some additional experimenting the mcu 'mcu': Unable to connect
errors are related to host-mcu interaction. In some cases sequences of FIRMWARE_RESTART
and Pi reboot seem to be ineffective and a full power cycle appears to be the only way to restore function. At this point I’m just chasing my tail so I will stop.
Peter.