Klipper: MANY unsupported Gcodes?

[mordhau5]

Hi there,

I've been experiencing some troubles with the most recent build of Klipper. Mainly that my prints have wildly inconsistent results, like as if the x-axis is being scaled at random which presents similar to layer-shift, but it is definitely not shifted. I recently noticed just how many commands that I had both in my starting G-Code and the output of the slicer were not properly getting picked up by klipper, and wondered if they might be causing these poor results. M117 for example is just console-write, however it doesn't recognize it and I can find no recent record saying it's an unsupported G-Code. Any help would be greatly appreciated! More info promptly on request.

Below is a smattering of the klipper console during a print:

03:57:57 Unknown command:"M201"
03:57:57 Unknown command:"M203"
03:57:57 Unknown command:"M117"
03:57:57 Unknown command:"M75"
03:57:57 Unknown command:"M117"
03:57:57 Unknown command:"M117"
03:58:33 Unknown command:"M117"
03:58:37 Unknown command:"M117"
03:58:37 Unknown command:"G29"
03:58:37 Unknown command:"M117"
03:58:45 Unknown command:"M420"
03:58:45 Unknown command:"M117"
03:59:03 Unknown command:"M117"
03:59:03 Unknown command:"M205"
03:59:20 Unknown command:"M108"
03:59:28 Must home axis first: 129.220 84.330 9.023 [139.720]
04:00:21 Unknown command:"M201"
04:00:21 Unknown command:"M203"
04:00:21 Unknown command:"M117"
04:00:21 Unknown command:"M75"
04:00:21 Unknown command:"M117"
04:00:21 Unknown command:"M117"
04:00:34 Unknown command:"M117"
04:00:38 Unknown command:"M117"
04:00:38 Unknown command:"G29"
04:00:38 Unknown command:"M117"
04:00:46 Unknown command:"M420"
04:00:46 Unknown command:"M117"
04:01:04 Unknown command:"M117"
04:01:04 Unknown command:"M205"
04:13:57 Unknown command:"M205"

Config file: config.txt

EDIT: Start_gcode macro is a WIP and not currently being called by my slicer

[klipper-gitissuebot]

Hi @mordhau5,

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.

[mordhau5]

uhh, well I did attach it. Maybe the bot doesn't like the filename?
Klipper-config.txt

[jakep82]

You need to post a log file. What you've attached is only your config.

[mordhau5]

Ahhh, thank you. An oversight on my part. Attached.
klippy.log
klippy1.log

[ld3300]

If I had to guess I would suggest it is the bed mesh. If you are on latest the bed mesh information you have in there isn't going to work very well and may cause unexpected behavior. Check out the changes in Config changes and in the example extras file

Also all compatible G-codes are listed here: [Klipper supported G-Codes](https://github.com/KevinOConnor/klipper/blob/master/docs/G-Codes.m

Most of those are awkward codes that are not well defined across firmwares. You could implement M117 and a gcode macro and output its parameters to M118. Your slicer should let you remove at least a couple of those commands from your slicing.

[pienjo]

As a general rule-of-thumb: Most G-codes and M-codes are not recognized, with the exception of the few mentioned on https://github.com/KevinOConnor/klipper/blob/master/docs/G-Codes.md.

A breakdown of the commands in your report:

• M117 is recognized by Klipper, but only if a display is configured.
• G29 initiates an automated bed level - this is probably part of the start-up code of your slicer. BED_MESH_CALIBRATE does almost the same thing - you could either create a macro replacing G29 with BED_MESH_CALIBRATE or create a macro that does all of the print initialisation in one fell swoop
• M75 restarts the print timer shown on the display - Klipper doesn't offer control of the print timer, but it's not going to have any influence on the print result.
• M205 is a can of worms: It can mean a lot, depending on what G-code flavor your slicer is generating.
• M420 probably sets the bed mesh fade (the distance in Z over which the information about the bed levelling is spread). This is a configuration option in Klipper; it doesn't allow setting this from G-code. That said, I doubt it'll have the effect you're describing.
• M201 and M203 set the max. acceleration and feedrate per axis (including E). Klipper has something similar, but not per-axis, so it's not going to be easy to simulate this with a G-code macro. Maybe best left ignored.

I'm a bit puzzled by "03:59:28 Must home axis first: 129.220 84.330 9.023 [139.720]", that almost sounds like the print job doesn't start with G28 (as it probably should)

[mordhau5]

Thank you both for your replies. When I get home from work I will grab my starting and ending gcode from my slicer and post it here. I know for sure it kicks off with a G28 before any other movement. It seems like I can probably rule out several of those unkown GCodes as unimportant and not the cause of my scaling issues.

I am curious about M205 and M108 (which was not mentioned, and seems to be for turning off the heater), hopefully my slicer start/end routine will shed light on those. Also curious why my bedmesh would be causing unexpected behavior as it was generated from the bed_mesh_calibrate routine while on the latest build.

EDIT: I will also try to remove all the unwanted/not-needed gcodes from the routines and give the calibration cube another print and report results.

[test3210-d]

You can create macro for g code
For example my implementation g29

[gcode_macro G29]
gcode:
BED_MESH_CALIBRATE METHOD=automatic
G1 X0 Y0 Z5 F8000
SET_PRESSURE_ADVANCE ADVANCE=0.097250

Example m900 - it have a parameters

[gcode_macro M900]
gcode: SET_PRESSURE_ADVANCE ADVANCE={K}

[Hywelmartin]

Use another gcode flavor... smoothie... reprap/sprinter... I don't understand why Marlin-flavor is recommended...??

[DeviousPenguin]

Use another gcode flavor... smoothie... reprap/sprinter... I don't understand why Marlin-flavor is recommended...??

I can't speak for anyone else, but I would guess that it is because Marlin is most common current firmware for 3d printers, so I imagine it was chosen as it has the best compatablilty with slicers, and many people are familiar with Marlin/

[darrellenns]

M108 is used to cancel a wait for heater temperature (M109 or M190) and continue executing gcode. As far as I can see, klipper has no equivalent to this. Some way of doing this would be helpful, as right now I believe the only way to get out of a heater wait is with an e-stop.

[mordhau5]

It seems like the G-Codes were possibly the cause as I've eliminated all unsupported or unnecessary gcodes from my start/end code, and am now getting more consistent results. Unfortunately, the issue has now devolved into a consistent full on layer shift which I'm sure is either a tuning or hardware issue, which as much as I'd like help with, probably doesn't belong in a klipper git issue.

[test3210-d]

try add to config ALL possible commands for tmc2130. Add it with default settings. I have similar problem with tmc2108

[jakep82]

The default settings are the defaults. Adding them to the config doesn't change them unless you use values other than the defaults. Unless you have read the Trinamic data sheet and understand what those values do, I would suggest leaving the defaults and search for other issues.

Looking at the logs you posted I notice that you're using different run currents for your X and Y axis. Perhaps that's an issue.

[mordhau5]

Ah...it's stealthchop. Could have sworn I tried a print before without it on, but I just completed a print with stealthchop threshold set to 0 and there was no layer shift where there was previously shifting in the exact same spot every time. Going to see if I can use the datasheet and the findings from this issue to come up with a compromise that lets me keep it on

EDIT: also, I have since evened out the currents between steppers, but before turning stealthchop off. Been playing around with currents all day to see what I can do.

[jakep82]

Increase your run current and reduce your acceleration. I don't know what type of printer you have, but 3000 is pretty high for most cartesian printers, especially if you have a large bed slinger and/or heavy direct extruder.

[mordhau5]

I have since done both of these and I'm working on an Ender 5, I'm also no longer opting to control acceleration from the slicer's gcode output. Here's my latest config for reference.
Klipper-config.txt

EDIT: it's an ender 5, modded to have direct drive*

[mordhau5]

Thanks for all the info/input guys, I'm closing this thread. The scaling issues have been solved by taking a closer look at supported Gcodes and paring down my starting and ending scripts, and the layer shift was solved by doing some configuration of my TMC2130 drivers as mentioned in this thread: https://github.com/KevinOConnor/klipper/issues/1363#issuecomment-492355285