Additional extruders might go in the wrong direction under certain circumstances

[Alex9779]

I recently got my new E3D BigBox Dual which runs on Marlin.
While setting it up and discussing in the forums some other people, including the staff of E3D, and me experienced the issue that after the start of the firmware the second extruder rotates in the wrong direction.
The fix proposed was to send an extrusion command with a negative value aka a retraction which rotated the right way and then like magic positive extrusion on the second extruder had the right direction.
I tracked the problem down.
This might also be the solution for #3083.

With certain circumstances I mean that if all extruders have to run the same way all is fine.
The problem only occurs if the direction of an extruder is different from the first extruder.

The problem is how the initialisation of the stepper interrupt works and how the direction setting for the E axis are implemented.
When starting the is no plan. Therefore there are no blocks for the stepper interrupt to read.
On init the "st_init()" function is called which calls "set_stepper_direction()" at its very end.
The direction of the E axis is set with REV_E_DIR() but this relies on the fact that there is a current_block from the planner in memory which has the active_extruder set.
On init this is not the case, there is no current_block. So the conditional statement in REV_E_DIR() falls back and sets the direction to the direction of the first extruder.
When then the very first command pops up in the planner for an extruder and it is positive then condition "if (current_block->direction_bits != out_bits)" on line 567 in stepper.cpp is false and so "set_stepper_direction()" is not executed and the count_direction array is not set to the correct values for the extruder.

So I tested it by commenting the condition in line 576 and the closing bracket for the condition in line 570 of stepper.cpp and it works.

I didn't create a pull request because I just started to dig into Marlin and I am not aware of the real logic behind all this. So I can't tell why that condition is there and what the effects will be if it will not be there.
This is the intention of this issue to discuss the problem because maybe a more sophisticated fix is needed...

[Alex9779]

Ok my description of what happens on init is not 100% correct. Because of how the multiple E axis are implemented on init only one E axis, the first one, can be initialized. So initially the direction of E0 is set.
But the rest is ok...

[Alex9779]

Sorry for bumping but did anyone read this?
As RC4 is approaching and also an official release I really would like to have a discussion about this, if what I did to fix is a possible solution or not...

[Blue-Marlin]

If you want an unqualified answer, continue to moan.
If not, wait until someone digged into the code.

[Alex9779]

I digged in. I think I did it a bit more sophisticated fix based on what is possible with current implementation than what I described here.
So closing this in favour of PR #3161...

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.