Macro controls other than buttons

[tlsomers]

Is your feature request related to a problem?

Printer options such as LED light have an one-off state or range of parameter values (similar to fans). Hence, for some macros the button approach is not the most suitable one, including that no variables can be used.

Describe the solution you'd like:

Allowing macros with parameters to take the form of other controls, most notably toggles (using boolean variables) or sliders (using int/float variables).

Describe alternatives you've considered:

Currently people need to make custom macro buttons for each option, such as TURN_ON_PRINTER and TURN_OFF_PRINTER.

Affected users and/or setups:

Anyone who uses macros that take parameter values could use this, for instance to more easily repeat z-offset adjustments using an input field + button or a way to toggle turning off of cooling down the printer once the current job finishes.

Additional Context:

I'm not sure if it's possible but the ability to see current variable values (when selected) would be nice for checking, such as seeing whether a magprobe is attached or for instance whether you gave QGLd before (so you don't need to redo it)

[pedrolamas]

Moonraker recently started exposing Klipper output_pin entries and gcode_macro via [power] elements, and that will in turn show on Fluidd Devices menu, so that they can be easily toggled on/off!

https://moonraker.readthedocs.io/en/latest/configuration/#klipper-device-configuration

We might look into having other type of controls for macros, but for on/off devices, I recommend using the solution above!

[randellhodges]

I've created a hack to allow creating a slider/toggle:
https://github.com/randellhodges/klipper-plugins#fake_output_pin

It works by creating a fake output pin with a gcode block that is called when the state of the pin changes (or if you have other macros, you can read the value and use it). I also have some code for a "pwm pin" that'll render as a slider, but beyond some simple testing, I haven't used it for anything.

My current use case is a toggle to keep on the heaters when a print is done.

Note: I've been using it a while and it works, but, by definition it is a hack. Use it at your own risk.

Configuration

[fake_output_pin keep_heaters_on]
value: 0
shutdown_value: 0
gcode:
  {% set value = printer['output_pin keep_heaters_on'].value | int %}
  { action_respond_info("KEEP HEATERS ON: %s" % (value == 1)) }

Usage

[gcode_macro PRINT_END]
gcode:

    # Config
    {% set keep_heaters_on = printer['output_pin keep_heaters_on'].value %}

    ... (other stuff)

    {% if keep_heaters_on %}
        {% set temp_t = printer.extruder.target | float %}
        {% set temp_s = printer.configfile.settings.extruder.min_extrude_temp | float %}
        {% set temp_n = [temp_t, temp_s] | min %}
        M104 S{temp_n}
        M106 S128
    {% else %}
        TURN_OFF_HEATERS
        M107
    {% endif %}

[pedrolamas]

@randellhodges just realized that your fake_output_pin is quite similar solution to what I did on the klipper-virtual-pins 😁

[randellhodges]

@randellhodges just realized that your fake_output_pin is quite similar solution to what I did on the klipper-virtual-pins 😁

Looks interesting. Yours looks like less of a hack than mine.

For example, mine actually creates 2 objects, fake_output_pin and output_pin (created behind the scenese), and it is "output_pin" that gets used by fluidd since fluidd doesn't know what a "fake_output_pin" is.

I would try to merging your approach, such that the user defines the output_pin using a virtual_pin like you do (instead of automatically creating one like I do), but as it would still be an overall hack, I'll just leave it be.

Nice to see other workarounds in the wild.