Unable to parse move - Print stops

[chunter1]

I just got two failed prints which both stopped with the message "Unable to parse move".
The exact message was: "Unable to parse move 'N16462 G1 X140.133 Y159.713 E0.0ok"
Performance graph of both prints until they stoped is shown below.
Printspeed 60mm/s
Retraction speed 80mm/s with pressure advance enable (maybe this is the root cause for the issue?)
UART speed 250kbps
Using octodash
Anybody got an idea?

[klipper-gitissuebot]

Hi @chunter1,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[chunter1]

Please find attached the klipper log file.
I guess the problem started at line 2921.

And here is what the terminal output of octoprint looked like as it transitioned from printing to halt:

Send: N16459 G1 X140.614 Y160.413 E0.006985
Recv: ok
Send: N16460 G1 X140.454 Y160.180 E0.005985
Recv: ok
Send: N16461 G1 X140.293 Y159.946 E0.0057*95
Recv: ok
Send: N16462 G1 X140.133 Y159.713 E0.0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00.......
....A ton of "\x00" following.

klippy.log

[chunter1]

The only line in the original gcode-file (generated by Simplify3D) that at least partly fits the error message "Unable to parse move 'N16462 G1 X140.133 Y159.713 E0.0ok" is the one marked below:
But where is the "N16462 " coming from and why is the "E0.0057" incomplete as well as an "ok" added?
Is there something interfering the serial interface?

......
G1 X140.775 Y160.646 E0.0019
; tool H0.200 W0.292
G1 X140.614 Y160.413 E0.0069
; tool H0.200 W0.250
G1 X140.454 Y160.180 E0.0059
; tool H0.200 W0.240
G1 X140.293 Y159.946 E0.0057
G1 X140.133 Y159.713 E0.0057
G1 X139.972 Y159.479 E0.0057
G1 X139.812 Y159.246 E0.0057
G1 X139.695 Y159.077 E0.0041
G1 E-5.0000 F4800
G1 Z23.500 F1002
G1 X148.342 Y162.870 F12000
G1 Z23.400 F1002
......

[Arksine]

This looks like an issue with Octoprint or Octodash. The log shows that klipper is receiving null bytes with the command N48906 G1 X158.570 Y157. It also received them with command N16462 G1 X140.133 Y159.713 E0.0 (see line 4380). This makes the command invalid. In your original example appears that an "ok" was sent with the command, which would also make the command invalid.

[chunter1]

I changed the retraction speed from 80 down to 60 mm/s and now the same object printed 3 times without any issue.
I suspect that especially pressure advance in conjunction with a too high retraction speed causes the issue.
Does that sound plausible?

[chunter1]

I came across this post here where someone also experienced issues with x00/ insertions:
https://community.octoprint.org/t/error-line-number-is-not-last-line-number-1/11232/18

An upload issue would explain why i got the fails at different heights.
However... why are the 3 uploads with reduced retraction speed successful then?
Hmmm...

[chunter1]

Maybe this issue is related to another issue i just came across.
As above, i scaled down a complex shaped figure so that the printer ran into buffer underrun issues due to lots of short moves.
Maybe the initial issue of this thread is an extreme form of a buffer underrun which in the end only looks like there was a corrupted gcode file?

[KevinOConnor]

I'm going to close this as it does not appear to be a Klipper issue. The provided log indicates the incorrect data was sent to Klipper.

-Kevin