Error in stepcompress

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.

I moved this to its own topic, as it isn’t related to stepcompress development.

I can reproduce the issue locally in Klipper “batch mode”. It looks like an integer overflow or numerical stability problem in the iterative solver. It will take some time to track down the root cause.

-Kevin

Thanks very much for moving this Kevin. I wasn’t sure if it justified its own topic when I posted.

FWIW, there is a degree of scatter in the length of time it takes for the error to post from the time the command is issued - sometimes it happens within a second, other times it takes in excess of 20 seconds.

I seem to be discovering some unusual corner cases, hopefully this is a “good thing”. Would you like me to try this with Dmitry’s experimental stepcompress branch?

Thanks again,
Peter.

I suspect the error is in the iterative solver; I don’t think changing anything in stepcompress will change anything.

I can reproduce this locally in batch mode: python ../../klippy/klippy.py -i test.gcode -o output -d dict/samd51p20.dict test.cfg
With a test.gcode of:

M83
G1 E-120 F60
M83
G1 E120 F600
M83
G1 E-120 F600
M83
G1 E120 F60
M83
G1 E-120 F0.6

It is the last line of the test.gcode that results in the error.

-Kevin

Thank you. To your point, I can confirm that the stepcompress branch exhibits the same error.