Unknown command:"E0.0985"

My custom built 3D printer, IDEX, run on 2 MKS monster 8 with fluiddpi and Klipper keeps pausing. It says Unknown command:“E0.0985”. Here is the gcode where it stopped:



Please help! Thank you very much.

Hardware:
Raspberry Pi 4b+
MKS monster 8
Custom built IDEX

Software:
Klipper: v0.11.0-65-gbca2671e
Mainsail v2.4.1
Moonraker v0.7.1-806-ga154c5f

Are you sure the error message refers to the gcode line you marked?

And please, always share the klippy.log.

Maybe in this case the gcode file too. You may have to zip it.

This must be something different as G1 is a normal movement G-Code with extrusion.
And all the other lines are somehow equal.

Are you sure it is the marked line as the following 1 is missing in the complaint.
Did you search the GCode file for that particular E0.0985? Did you check it as well for special/non-ASCII characters not being displayed by default?

The klippy.log does not contain this message, there is no error at all in that log.

Unknown command means that there is a command that can’t be parsed by klipper.

So this E0.0985 has to be at the very beginning of a gcode line to cause an Unknown Command

E0.0985 can’t be found at the beginning of a line in the provided gcode file.

And you say this error always and only happens with this certain gcode file?

1 Like

In addition the provided gcode file is crippled / invalid, so nothing to get from there

The printer paused many times but I just caught Unkown command E0.0985 once. I think there must be some lagging in signal transfer from the pi to the MKS board. The printer sends G1 X Y, and transmission is then interrupted, so the Klipper doesn’t understand command E0.0985 which is supposed to be sent in normal extrusion move G1 X Y E. On this E0.0985 pause event, the first time I hit resume it shown Unkown command E0.0985 again. And the second time I hit resume, it return printing while ignoring E0.0985. That’s weird.
Today, the pause command auto poped up right after homing for no reason (photo below)

Is that possible that the MKS board is overloaded with complex gcode like a bottleneck or something similar, then it triggerd pause command?
And beside filament sensor, what else can trigger pause command?

Without a gcode file and the corresponding klippy.log showing the issue no further diagnose is possible. If too big upload somewhere, e.g. google drive etc.

This is the Klipper screen log
KlipperScreen.log (1.3 MB)

KlipperScreen log is not relevant here. But it shows that your KlipperScreen setup is severely messed up.

With such a mess already in the KlipperScreen, I would recommend to start over. Reprovision a new SD card and systematically go through the entire setup.

The action is either “user” initiated or via command/macro.
Maybe your screen experiences some kind of ghost clicks where the pause button is located?

Due to the design of Klipper the MKS won’t be overloaded as the SBC processes the gcode.
And if you do not run insane speeds with more insane acceleration and high microsteps and stuff like that the MKS board won’t be overloaded.
But thanks for that board model, maybe it will fit into my IDEX rebuild of my Anycubic i3 Mega…

As @Sineos wrote just restart from scratch with a basic configuration and test it with this.
Give up unnecessary macros for now and if possible only change/improve your config step by step.

As far as I remember you Y axis had some odd rotation distance values so check that as well.

Thank you for all of your ideas. I will change the cable from pi to the MKS and remove the Klipper screen to eliminate all the possible ghost click and see how it works. My printer is big and has heavy print head so the speed is limited to 100, acceleration 400mm/s2, that’s insanely slow. Maybe I’ll set up the screen later. Thank you

What type of steppers and drivers are you using and what is your motor power supply voltage?

I wonder if you’re getting power surges/dips when movement starts.

Changing the cable between the Pi and the MKS will have zero effect on this problem. Gcode is processed entirely on the Pi and converted to basic step and direction information that is transmitted to the MCU in a compressed format.

1 Like

Look at your KlipperScreen log: It contains tons of weird errors that point to a completely messed up installation (really wonder how to reproduce such, even if I wanted to).

If the rest of your installation is in a similar shape, you are beating a dead horse that will not come back to life by changing a cable.

And as @jakep_82 pointed out: Completely unrelated to your issues.

I have the same problem that only comes up when resuming printing. Have you solved it now?

I dare to say that you likely do not have the same issue.
Open a new post and provide the relevant information according to the template.