Internal error on command:"G2"

[mggevaer]

Basic Information:

Printer Model: Voron trident (Rpi Zero 2 w)
MCU / Printerboard: Octopus + BTT EBB36
klippy.log
klippy.log (1.9 MB)

Describe your issue:

I turned on Arc fitting in PrusaSlicer (G2/3 I J), to reduce the size of my gcode files a bit, and this seemed to work fine on a bunch of files, however, I’m getting an error with a specific gcode files, specifically the klipper error looks like this:

move 840: pt=854.226472 mt=0.000345 sv=4.713956 a=-129.302121 sp=(739.592934,-0.000000,0.000000) ar=(1.000000,1.000000,0.000000)
Requested toolhead position at shutdown time 854.126698: (176.7658024588731, 116.44171951165774, 0.32990518317924533)
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
b'stepcompress o=12 i=0 c=3 a=0: Invalid sequence'
Internal error on command:"G2"
Traceback (most recent call last):
  File "/home/printer_white/klipper/klippy/gcode.py", line 211, in _process_commands
    handler(gcmd)
  File "/home/printer_white/klipper/klippy/extras/gcode_arcs.py", line 48, in cmd_G2
    self._cmd_inner(gcmd, True)
  File "/home/printer_white/klipper/klippy/extras/gcode_arcs.py", line 112, in _cmd_inner
    self.gcode_move.cmd_G1(g1_gcmd)
  File "/home/printer_white/klipper/klippy/extras/gcode_move.py", line 143, in cmd_G1
    self.move_with_transform(self.last_position, self.speed)
  File "/home/printer_white/klipper/klippy/extras/bed_mesh.py", line 215, in move
    self.toolhead.move(split_move, speed)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 454, in move
    self.move_queue.add_move(move)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 187, in add_move
    self.flush(lazy=True)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 176, in flush
    self.toolhead._process_moves(queue[:flush_count])
  File "/home/printer_white/klipper/klippy/toolhead.py", line 345, in _process_moves
    self._advance_move_time(next_move_time)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 304, in _advance_move_time
    self._advance_flush_time(flush_time)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 288, in _advance_flush_time
    sg(sg_flush_time)
  File "/home/printer_white/klipper/klippy/stepper.py", line 228, in generate_steps
    raise error("Internal error in stepcompress")
stepper.error: Internal error in stepcompress
Internal error on command:"G2"
virtual_sdcard dispatch
Traceback (most recent call last):
  File "/home/printer_white/klipper/klippy/extras/virtual_sdcard.py", line 264, in work_handler
    self.gcode.run_script(line)
  File "/home/printer_white/klipper/klippy/gcode.py", line 229, in run_script
    self._process_commands(script.split('\n'), need_ack=False)
  File "/home/printer_white/klipper/klippy/gcode.py", line 211, in _process_commands
    handler(gcmd)
  File "/home/printer_white/klipper/klippy/extras/gcode_arcs.py", line 48, in cmd_G2
    self._cmd_inner(gcmd, True)
  File "/home/printer_white/klipper/klippy/extras/gcode_arcs.py", line 112, in _cmd_inner
    self.gcode_move.cmd_G1(g1_gcmd)
  File "/home/printer_white/klipper/klippy/extras/gcode_move.py", line 143, in cmd_G1
    self.move_with_transform(self.last_position, self.speed)
  File "/home/printer_white/klipper/klippy/extras/bed_mesh.py", line 215, in move
    self.toolhead.move(split_move, speed)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 454, in move
    self.move_queue.add_move(move)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 187, in add_move
    self.flush(lazy=True)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 176, in flush
    self.toolhead._process_moves(queue[:flush_count])
  File "/home/printer_white/klipper/klippy/toolhead.py", line 345, in _process_moves
    self._advance_move_time(next_move_time)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 304, in _advance_move_time
    self._advance_flush_time(flush_time)
  File "/home/printer_white/klipper/klippy/toolhead.py", line 288, in _advance_flush_time
    sg(sg_flush_time)
  File "/home/printer_white/klipper/klippy/stepper.py", line 228, in generate_steps
    raise error("Internal error in stepcompress")
stepper.error: Internal error in stepcompress
Exiting SD card print (position 161472)

Does this point to a mistake in my config? Should I open a github issue?

[LifeOfBrian]

Either in addition or related to the above error your have the following as well:

MCU 'toolboard' shutdown: Timer too close

See here:

Timer too close

Background This error typically occurs when the host sends a message to the MCU, scheduling an event at a time that is in the past. Reasons High system load of the host High disk activity of the host Swapping due to low free memory Disk errors / dying SD card Unstable voltage Other hardware hogging the USB bus or other system resources Running in a Virtual Machine USB, UART or CANBUS wiring faults leading to extremely delayed messages ElectroMagnetic Interference (EMI) affecting proper signa…

A side note from @Sineos to the original topic:

General note: Log lines like stepcompress o=4 i=0 c=17 a=0: Invalid sequence often are a consequence of errors / events that happened before. This means they are rather a symptom but not the root cause.

What is connected to your Pi Zero 2?

[EddyMI3D]

Would be interesting to see the parameters of the G2 command.

Do you have some code lines?

[LifeOfBrian]

If I’m reading the log right this should be the recent code:

Y115.309 E.14327
G1 X73.011 Y115.323 E.00269
;WIDTH:0.41646
G1 X72.928 Y115.337 E.0025
;WIDTH:0.38292
G1 X73.098 Y114.687 E.01814
M204 S3000
M204 S5000
G1 X72.902 Y116.075 F24000
M204 S4000
;WIDTH:0.449999
G1 F12000
G1 X75.948 Y113.029 E.13925
G1 X76.05 Y112.901 E.00529
;WIDTH:0.41646
G1 X76.152 Y112.772 E.00488
;WIDTH:0.38292
G3 X76.091 Y112.712 I-.02 J-.04 E.00307
G1 X76.163 Y112.731 E.00201
M204 S3000
M204 S5000
G1 X75.901 Y113.564 F24000
M204 S4000
G1 F12000
G1 X75.83 Y113.545 E.00198
G2 X75.89 Y113.605 I.04 J.02 E.00301
;WIDTH:0.41646
G1 X75.79 Y113.734 E.00484
;WIDTH:0.449999
G1 X75.691 Y113.863 E.00526
G1 X72.735 Y116.819 E.13513
G1 X72.579 Y117.55 E.02416
G1 X75.457 Y114.672 E.13157
G1 X75.555 Y114.543 E.00524
;WIDTH:0.41646
G1 X75.653 Y114.414 E.00481
;WIDTH:0.38292
G3 X75.593 Y114.354 I-.02 J-.04 E.00301
G1 X75.664 Y114.373 E.00198
M204 S3000
M204 S5000
G1 X75.24 Y115.464 F24000
M204 S4000
;WIDTH:0.449999
G1 F12000
G1 X72.723 Y117.982 E.11509
G1 X72.657 Y118.026 E.00256
G1 X72.485 Y117.992 E.00567

[EddyMI3D]

According to this:

Internal error in MCU 'mcu' stepcompress

Internal error in MCU ‘mcu’ stepcompress Background An unforeseen issue in the stepcompress logic has happened. Reasons This is an error that should not happen under normal operating conditions Often this appears in the log as a consequential error of an error that occurred earlier Potential solutions Scroll upwards in the klippy.log from this error. If there is another error then this is likely the source of the issue and should be looked at If there is no upstream error and it is repr…

@koconnor may have a look on this.

[mggevaer]

Connected to the Rpi I have the Octopus board, a BTT EBB36, and also a “Microsoft Modern webcam”, but I have it capped at 1 fps, and 640*360, so very low.
Everything runs over USB.
I can try to run the file again with the webcam disabled if that rules out any MCU timeout issues.
I had been running the webcam at 5fps for some time without issues, and CPU load didn’t look to bad in Mainsail(<15% at all times during printing).

[LifeOfBrian]

If

G2 X75.89 Y113.605 I.04 J.02 E.00301

is the culprit here this is maybe just too tiny for the (step) calculation.

In your printer.cfg you have set:

[gcode_arcs]
resolution: 0.05

The default is 1.0
Maybe you can just for testing purpose set it again to 1.0 and retry your failing gcode after a save and restart.

[Sineos]

As mentioned by @LifeOfBrian the initial error is a “Timer too close”. The rest of the errors are IMHO purely consequential to this and should be disregarded.

Hard to tell if this is related to using arcs or not.

Generally, I do not see any valid reason to use arcs with Klipper:

• A 3D printer is not able to move in a circular motion → An arc always needs to be broken down in discrete steps as movements of X and Y
• This is nice for firmwares that suffer from bottlenecked serial connection bandwidth → Klipper does not
• The arcs IMO come out of a time where CNC have been programmed by hand and today and especially with 3D printers I personally see no real use
• On the contrary, it might even introduce yet another approximation step

[mggevaer]

Did a test with the resolution set to 1.00 and did not see issues. I had the arc value at 0.05 because I think this is what is used by Octoprint arc welder, although I don’t know if that value translates directly to Klipper.
1.00 seems very high, considering I often have arcs with radius 0.5 in my parts. (0.25mm nozzle)

For me the reasons I wanted to use arcs:

• smaller GCode files.
• I felt as if it was a way for the printer to get as close to the arc as allowed by its motion system. (not sure this is the case now)
  But mostly smaller GCode files.

Maybe it makes sense to add a note in the Klipper documentation if it’s not recommended to use arcs(G2/G3)?

[Sineos]

“Timer too close” is an error that is created on the host side.
You are using a pretty weak host (Rpi Zero 2 w) and in combination with quite an extreme resolution, I could imagine that this is causing the issue.

Graphing your log’s content yields:

Which shows a pretty high peak in the hosts bandwidth. For my taste too high and could also be related to the points mentioned above.

@mggevaer

I felt as if it was a way for the printer to get as close to the arc as allowed by its motion system. (not sure this is the case now)

Actually, rather on the contrary. It just adds additional processing steps that all cause a certain form of error / approximation.

The size argument, I really do not understand. With todays hardware and WIFI / LAN transmission speeds, I personally could not care less if the file is 10MB or 50MB.

[mggevaer]

I was under the assumption that there were no downsides to the arc welding (wrongly so apparently), so for me smaller files without any downsides made sense.

Based on what you’re saying it seems like I should go for something like a RPI 4b for my next printer then, since rpi zero 2w has the rpi 3B processor, (clocked maybe slightly lower). Unless I’m really only hitting the limit due to the arc welding, which I won’t use again moving forward based on your comments.

FYI, my printer is in a pretty bad wifi spot, I’m getting upload speeds of 150 kb/s~500kb/s, so it would have made a slight difference to me, e.g. 15 mb vs 22 mb means 46s~14s less upload time.