-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor extruder steppers and extruder_stepper #5143
Conversation
very interested in this and willing to test |
I've got an IDEX and have been following e.g. #4464 . As a newbie to klipper (and 3d printers), this might be a really silly question/suggestion ... but I wonder if a single Again, apologies if I've missed something obvious. |
this? https://www.klipper3d.org/Config_Reference.html?h=sync#extruder_stepper |
Kevin, Suggestion: Why not remove the Heater, temp sensor, and Fan sub-elements from the Extruder and reference the generic "stand-alone" modules that are in Klipper? ie: add a "Tool_x" module that calls out a Heater, Temp Sensor, Cooling Fan, Tool Fan, and Extruder modules that reference/call the generic objects or list of generic objects? You could possibly extend the "Tool_x" module to include things like spindle and coolant pumps expanding the use of Klipper into milling or other maker hobbies. |
As currently set up, my printer has six bowden "extruders" that feed into a single direct-drive "extruder_stepper" at the hotend. Below is a quick diagram, where "Ex_" represents an Extruder printer object and "ES" represents an Extruder_Stepper printer object under the current code:
Currently, each of my Extruders has a shared heater because I only have a single hotend. Also, the Extruder_Stepper always has to be synced to the currently active Extruder because they work in tandem in a sort of push-pull arrangement. This works fine for my purposes. If I'm understanding correctly, if this PR is merged, then I would need to reconfigure my setup so that I have only one Extruder, and six Extruder_Steppers, like so:
Then I would not need a shared heater because I only have one Extruder. And instead of switching between six Extruders and then making sure the single Extruder_Stepper is synced to the appropriate active Extruder, I would only ever have one active Extruder and would simply change which of the six Extruder_Steppers is synced to it. Is this correct? If so, I can foresee problems arising from the fact that an Extruder_Stepper does not move on its own, but only in sync with an Extruder:
|
Yes. The proposal in this branch is to consider an
It should be possible to disassociate the extruder stepper from the extruder motion queue:
I'm not sure what you are reporting. I don't see why it wouldn't work. I'd envision the user would supply macros like the following:
Am I missing something? |
ef8c580
to
7a3b54f
Compare
wouldn't this break the opportunity to run separate extruders in a mixing config? or maybe constantly synced but with the capability to alter the proportion "steps/mm" of the two? |
As I understand it, an Extruder_Stepper cannot move alone. It can only move in sync with an Extruder. So in your example macros, if the user issues In a basic 2-in-1-out configuration, the user needs two steppers to be able to move independently of one another. And with a mixing hotend like @Black6spdZ is talking about, the user needs multiple steppers to move independently of one another simultaneously. |
No - this PR explicitly adds the ability to disassociate an extruder stepper motor from the extruder motion queue. The example -Kevin |
Ah, that's helpful. I may have been making incorrect assumptions based on the current implementation. If I'm following, then under this PR, an Extruder will simply be a default association of a heater, a motion queue, and an extruder_stepper. Setting the active "Extruder" simply activates these three associated objects, one of which is a defined Extruder_Stepper. From there, the user can change these independent objects. With respect to the Extruder_Stepper, the user could "unsync" the current one and "sync" a different one instead (so as to use a 2-in-1-out hotend). Or sync an additional Extruder_Stepper to the already active one (as in my push-pull configuration, or an IDEX printer). If that's right, I like it! One thought though: Wouldn't it make more sense to sync the Extruder_Stepper to a movement queue object, rather than an Extruder object? I think that's what had me confused. In your example macro, the line Maybe the command JOIN_STEPPER_TO_QUEUE or something along those lines could make the intent/usage clearer? |
I agree the SYNC_STEPPER_TO_EXTRUDER command is a bit confusing. I reused the existing command so as not to break any existing users. However, it does seem that it's probably better to remove SYNC_STEPPER_TO_EXTRUDER and introduce a new command (eg, -Kevin |
hmm, this looks promising.. but I am still at a loss how to alter the extruder's motion as a set percentage of it's original "rotation_distance" calc. There is legecy set_extruder_step_distance but it's value is inversely proportional and would be exponentially large to attempts say a 1% extrusion rate |
Hi @KevinOConnor, I was testing this PR and #4464 together with @Tircown on a Cartesian idex printer. We observed the following unexpected behavior:
|
7a3b54f
to
b304968
Compare
Thanks for testing. Unfortunately there was a typo in the pressure advance code. I'm not sure how it managed to pass the regression test cases. I've corrected it (hopefully) and rebased this branch. -Kevin |
I'm not really sure what you're reporting. If you've got a printer you'd like to test, can you provide a description of it, your current config, and your test attempts with this branch? It may be possible to configure a mixing extruder with this branch using the SET_EXTRUDER_STEP_DISTANCE command on extruder_stepper and extruder objects. I don't have mixing extruder hardware though, so can't test it. -Kevin |
Hi @KevinOConnor
the "plucking" of the extruder was seen as the X Y changes |
Store the pressure_advance value in "struct extruder_stepper" instead of in the trapq's "struct move". This makes it possible for multiple stepper motors to have different pressure advance values while still using the same trapq. Signed-off-by: Kevin O'Connor <[email protected]>
…lass Move the stepper handling (including pressure advance handling) to a new class. Signed-off-by: Kevin O'Connor <[email protected]>
Refactor the extruder_stepper support so that it uses the ExtruderStepper class defined in extruder.py. Support the SYNC_STEPPER_TO_EXTRUDER command on steppers defined in either extruder_stepper or extruder config sections. Signed-off-by: Kevin O'Connor <[email protected]>
Support SYNC_STEPPER_TO_EXTRUDER commands with an EXTRUDER parameter set to an empty string. Signed-off-by: Kevin O'Connor <[email protected]>
b304968
to
02d5f97
Compare
Thanks. I went ahead and merged this PR, but without the deprecation of the shared_heater. I'll plan to make a separate PR that deprecates shared_heater and SYNC_STEPPER_TO_EXTRUDER. -Kevin |
FYI, PR #5210 has the updates to deprecate -Kevin |
This PR reworks the extruder stepper logic to make it more flexible. In particular, it is now possible to use the SYNC_STEPPER_TO_EXTRUDER command on either an
extruder
object or anextruder_stepper
object. It is also now possible to call SET_PRESSURE_ADVANCE and SET_EXTRUDER_STEP_DISTANCE onextruder_stepper
objects.This may facilitate synchronizing of multiple extruders on idex printers (such that one can print multiple objects simultaneously). As in #4489.
This may facilitate support for mixing extruders (as in #3920, #4082, #4566).
This PR also deprecates the
shared_heater
support in extruder config sections. It is thought that one can now obtain the same support by usingextruder_stepper
config sections.I do not have a good way to test this code. Feedback and testers would be appreciated.
-Kevin