Klipper: Printer fails on DUMP_TMC with wrong syntax

[bigsubgit]

Hello everyone,
I noticed that sending a DUMP_TMC command during a job, without specify stepper, or specifying a wrong stepper name, causes the printer failing.
In my opinion it only must reports that I send a wrong command, do not error the printer.

klippy.log

[robustini]

Same problem with my printers, and I think it's a bug, or at least something that shouldn't happen.
No unintentional command should be able to stop printing and shutdown Klipper.
If the stepper is misrepresented Klipper should simply return a message like that, without stop printing.

[robustini]

If there is a logical reason for this behavior I would be curious to know what it is... :P

[bigsubgit]

The same problem with the SET_TMC_CURRENT command, with wrong syntax and during a printing job.

[bigsubgit]

Hello, not the same thing if the printer is idle. Is it convenient to release the same informations also during a job?

[robustini]

Conceptually I don't understand this thing, but surely @KevinOConnor will have wanted it, that is the abortion of the print in case of wrong command sent by the console.
However, I would be curious to know what is the reason for this choice, also because in the documentation I don't see written anywhere that in case of # wrong commands from the console the printing goes into abort.

[Coffee0297]

all gcode sent that has a syntax error will shut down a print. it seems weird as klipper dont read that comand so it shuld not matter

-Tonny

[robustini]

The commands directed to Klipper, that is those preceded by #, have nothing to do with gcode, therefore they should not stop printing.

[KevinOConnor]

FYI, Klipper does not halt the print - Klipper responds that there is an error which causes OctoPrint to halt the print. If one were printing from virtual_sdcard, for example, then an error in a command from OctoPrint would not cause the print to stop. Unfortunately, when printing from OctoPrint there is no way for Klipper to know which commands were part of the g-code file and which are commands entered from the terminal. Alas, this is one of the many fundamental limitations of g-code.

FWIW, there's been a lot of interest recently in adding http support to Klipper. I suspect that approach is the best way to avoid some of these fundamental limitations of g-code.

-Kevin

[schnello]

The problem in my mind is: Some errors are reported as critical although those are not critical.
Sure a can disable this feature in Octoprint but this is the wrong way, I feel

if i understand it correct:
This will cancel the print:

Send: DUMP_TMC STEPPER=stepper_x1
Recv: !! The value 'stepper_x1' is not valid for STEPPER

so why not without !! (its only an info not an "error")

Send: DUMP_TMC STEPPER=stepper_x1
Recv: The value 'stepper_x1' is not valid for STEPPER

Same for:

Send: DUMP_TMC
Recv: !! Error on 'DUMP_TMC': missing STEPPER

[KevinOConnor]

I'm going to close this issue as a "wont fix". From my perspective, developer time would be better spent on building scalable solutions that avoid the problems of g-code then it would be to spend developer time analysing g-code commands to guess which invalid commands are "real" errors.

-Kevin