impossible to set pressure advance values for extruder_stepper

[dw-0]

Browser:

Chrome

Device:

Desktop PC

Operating System:

Windows

What happened?

Currently it is impossible to safely set pressure advance values for printer configurations where multiple extruders are configured with [extruder_stepper] sections in the printer.cfg. Using Mainsails input field for pressure advance will fail, as it tries to assign those pressure advance values to an extruder, that is not allowed to take pressure advance values.

Even though an extruder stepper might be synced with an extruder, extruder1, extruder2 and so on, it is currently impossible to figure that out which extruder stepper is synced with which extruder. That is due to technical limitations of Klipper, as Klipper (+Moonraker) does not offer a safe way to figure out which extruder stepper is currently the active one.

[extruder] is not allowed to have pressure advance values configured and won't accept any pressure advance values send to it via g-code. Klipper in turn requires the pressure advance to be set via g-code and by specifying the correct extruder stepper name, rather than the extruder name it is synced to.

After joint consultation with @pedrolamas (Fluidd developer) on how to tackle that issue we came to the following conclusion:
We will be unable to allow setting pressure advance values via input fields as long as Klipper offers a suitable solution to the problem above. For the meantime it is probably the safest solution to hide those input values once it's clear that there are [extruder_stepper] defined in the users printer.cfg. We have to wait for Klipper upstream changes to happen. Only then we can re-enable those input fields again.

Also see: fluidd-core/fluidd#681

[jalanjarosz]

Not sure if this info would help with creating a solution. Here is a complete config setup of a multi-stepper extruder using extruder_stepper:

https://klipper.discourse.group/t/x-in-1-out-non-mixing-extruder-config/2387

Pressure Advance is set via the following command:

SET_PRESSURE_ADVANCE ADVANCE=0 EXTRUDER=[tool_name]

[dw-0]

It's not about that we don't know how to set pressure advance for an extruder_stepper, it's about a technical limitation of Klipper which doesn't allow us to figure out which extruder_stepper ( -> [tool_name] ) is currently the active one.

[noahliketheark]

It's not about that we don't know how to set pressure advance for an extruder_stepper, it's about a technical limitation of Klipper which doesn't allow us to figure out which extruder_stepper ( -> [tool_name] ) is currently the active one.

Is the following command new to the latest Klipper release?
printer[printer.toolhead.extruder].target

[dw-0]

Is the following command new to the latest Klipper release?
printer[printer.toolhead.extruder].target

@noahliketheark
Can you explain why you chose this issue to ask the question? I can't make a connection between your question and the actual topic right now.

[noahliketheark]

Is the following command new to the latest Klipper release?
printer[printer.toolhead.extruder].target

@noahliketheark Can you explain why you chose this issue to ask the question? I can't make a connection between your question and the actual topic right now.

The problem with including pressure advance in the GUI for a 2-in-1-out setup is that Klipper doesn't extuder_stepper is the active one as I understand it. If printer[printer.toolhead.extruder].target is a new feature, would this allow the pressure advance UI to work?

[dw-0]

Ah now i understand what you mean. No this is not a newly implemented status object.
printer[printer.toolhead.extruder].target is not even what you think it might be. It would give you the target temperature of the current extruder. So in case of a 2in1 setup, it just references to the thermistor reading of that one hotend you have there.

Even this PR that got merged a while ago won't solve the issue: Klipper3d/klipper@5d9ff75#diff-b6a97c51104b2210c9bf7756cc91af96040dbdee821deace6e736cfbd70325d0
It just solves that PA values could be defined in the config, yet it still doesn't let us destinguish which stepper is currently the active one. We would need more data for that still.