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
Initial support for the Průša MK2 Multiplexer #6938
Initial support for the Průša MK2 Multiplexer #6938
Conversation
3f98f00
to
79185a5
Compare
4f9c475
to
1d1565b
Compare
2936eac
to
aa01955
Compare
b13c189
to
2cf5d72
Compare
2cf5d72
to
5b11b33
Compare
if (tmp_extruder >= E_STEPPERS) | ||
return invalid_extruder_error(tmp_extruder); | ||
|
||
select_multiplexed_stepper(tmp_extruder); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been looking at this for M701/M702, and it seems to me that the call to select_multiplexed_stepper
really belongs in the Planner
class. Several of the methods in the Planner
class take the extruder index as an argument, which I would think is currently broken since select_multiplexed_stepper
is not incorporated into those methods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been looking at this some more, and I don't think Planner
is the correct place to call select_multiplexed_stepper
. I originally thought this because Planner
currently enables any inactive extruder steppers.
Planner::_buffer_line
places the commanded movements into a circular buffer. These commands are then processed in Stepper::isr
. Enabling the extruders steppers in Planner
works because it's not an issue to enable the steppers early (i.e. when they are queued as opposed to actually processed in Stepper
). However, select_multiplexed_stepper
can only be called immediately proceeding the first command destined for the newly selected stepper, otherwise step commands generated by Stepper::isr
will be sent to wrong stepper while the buffer is processed to the point where the change was intended. Stepper::isr
already knows which stepper the command being processed is destined for (via current_block->active_extruder
, which is currently used for dual X carriage). As such, it should be straight forward to call select_multiplexed_stepper
on a change to current_block->active_extruder
in Stepper::isr
. With this change, I don't believe it would be necessary to call select_multiplexed_stepper
in any other location in Marlin.
We should probably also add a sanity check to ensure that MIXING_EXTRUDER
and MK2_MULTIPLEXER
are not both enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably also add a sanity check to ensure that MIXING_EXTRUDER and MK2_MULTIPLEXER are not both enabled.
Thinking about this some more, MIXING_EXTRUDER
probably would work with MK2_MULTIPLEXER
so long as select_multiplexed_stepper
is a relatively quick operation since the steps are actually sent out to each stepper one at a time in Stepper
.
disable_e_steppers(); | ||
WRITE(E_MUX0_PIN, TEST(e, 0) ? HIGH : LOW); | ||
WRITE(E_MUX1_PIN, TEST(e, 1) ? HIGH : LOW); | ||
WRITE(E_MUX2_PIN, TEST(e, 2) ? HIGH : LOW); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should probably only write to E_MUX1_PIN
and E_MUX2_PIN
if they are defined.
@@ -472,8 +472,14 @@ | |||
#endif | |||
#else | |||
#define E_STEP_WRITE(v) E0_STEP_WRITE(v) | |||
#define NORM_E_DIR() E0_DIR_WRITE(!INVERT_E0_DIR) | |||
#define REV_E_DIR() E0_DIR_WRITE(INVERT_E0_DIR) | |||
#if ENABLED(MK2_MULTIPLEXER) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how this will ever work. The previous pre-processor checks will ensure that EXTRUDERS
is 1, but SanityCheck.h requires that EXTRUDERS
be greater than 1. It seems like there should be a section immediately before or after the SWITCHING_EXTRUDER
section in this block that defines these macros depending on the number of extruders, which all use the E0_XXXXX
macros and invert the even-numbered steppers. Could potentially configure the multiplexer as part of E_STEP_WRITE
here as well.
*/ | ||
#ifdef SNMM | ||
#error "SNMM is now MK2_MULTIPLEXER. Please update your configuration." | ||
#elif ENABLED(MK2_MULTIPLEXER) && DISABLED(ADVANCED_PAUSE_FEATURE) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why ADVANCED_PAUSE_FEATURE
is required for MK2_MULTIPLEXER
. The multiplexer allows for expansion of extruder steppers, but they don't necessarily have to be in a Bowden configuration as used in the MK2. There's no reason why someone couldn't use the multiplexer on a direct-feed printer to allow for multiple extruders to be driven from a single driver.
I'm new to Marlin development as I'm trying to get a Průša MK2 Multiplexer working on my delta printer. As soon as I increase the number of extruders to > 1 the stepper switch control is working fine, but extrusion is not. Looks like the extruder stepper is disabled before switching and then remains disabled. To have to set EXTRUDERS > 1 in combination with MK2_MULTIPLEXER felt kind of wrong to me from the begining. As there is only one active working extruder at any moment in time, EXTRUDERS 1 would be the correct setting from my point of view. After digging deeper into Marlin sources I was wondering if it wouldn't make sense to integrate the MK2_MULTIPLEXER and SWITCHING_EXTRUDER options. Both have a similar setup with one logical extruder stepper driving multiple materials, the one difference being the multiplexing mechanism (servo vs. stepper switcher). I'm willing to get my hands dirty making the MK2 Multiplexer work with Marlin. Someone with more experience in Marlin development pointing me in the right direction beforehand would be highly appreciated. |
@revilor The |
Based on work in the Prusa-Firmware fork, this feature augments
SINGLENOZZLE
by adding code to switch a multiplexer on tool-change. The full implementation requires additions to the LCD and implementing a standardized function to eject filament that will work in all cases. For now, assuming that this feature will requireM600
.