Internal error when using variables SET_GCODE_VARIABLE command

[EquilibriaW]

I get the "internal error" error leading the M112 shutdown and syntax error in klippy.log when I issue the "SET_GCODE_VARIABLE MACRO=TRV VARIABLE=test_cycle VALUE={printer["gcode_macro TRV"].test_cycle+1}" command.

I also get "internal error" when issuing commands like "SET_GCODE_VARIABLE MACRO=TRV VARIABLE=test_cycle VALUE={printer.toolhead.position.x}

I used to be able to include printer attributes, as well as calculations, after "VALUE=". And the commands above used to work.

Did the syntax change? No sure what mistake I'm making. Thanks.
klippy.log

[FHeilmann]

From what I can gleon from your log file is that you tried to enter the command you mentioned into your gcode terminal.

you can't use jinja syntax in the gcode terminal. Jinja syntax can only be used in the config file.

[KevinOConnor]

As noted, it's not valid to use templates from the command line. However, I agree Klipper should not have raised an "internal error" in this case.

-Kevin

[cmidgley]

I find this internal error occurs whenever you set a value that isn't a single number, such as setting a string (in a template):

SET_GCODE_VARIABLE MACRO=TEST VARIABLE=myvar VALUE="testing"

I have also found, similar but perhaps a different issue (let me know if I should create a new issue) is that you can't use value types other than numbers, such as lists or strings. These don't always cause internal errors, as usually they are caught as syntax errors first (unlike the simple example above, which passes syntax but then does an internal error). For example,

SET_GCODE_VARIABLE MACRO=TEST VARIABLE=myvar VALUE=[1, 2, 3]

In my case, I wish to be able to have a variable that is a list (used as a stack to save states and pop them off later), so it would be more like this:

[gcode_macro test]
variable_stack: [1, 2, 3]
gcode:
   SET_GCODE_VARIABLE MACRO=test VARIABLE=stack VALUE={stack}

The above generates an error, as it doesn't want to parse a value of '[1, 2, 3]' for VALUE. Same issue if trying to use a string.

[pedrolamas]

@cmidgley I just stumbled on the same problem as you, and as it seems a bit unrelated with this ticket, I've opened a separate one here: #4816

[cmidgley]

The issue with using complex data types in variables has been resolved, see #4816. The fact that an internal error occurs remains an open issue, but when using the correct syntax the issue goes away.