Extruder Motor on 2nd Hot End Turns wrong way, initially

I see the same issue on my machine... Investigating...

 

Ok I tried with the RCBugFix branch of Marlin, same issue...

 

As far as I can tell this must be a Marlin issue... The problem is not only when you send gcodes manually with OctoPrint but also if you only heat up the nozzle and do a move axis from the menu...

All I found on the Github Marlin repo was this comment on an issue:
https://github.com/MarlinFirmware/Marlin/issues/3083#issuecomment-195152067

Think we gotta file a new issue describing our problem. Maybe with an excerpt of our Configuration.h that we have E0 inverted and E1 is not inverted. Maybe the issue is connected to that...

Who will do it?

 

It's a firmware bug. We get it too. Add some code to the startup script that runs 0.1mm one way then the same the other direction. It's a bit of a hack but it should fix things for now.

 

Cool you can confirm too. Nonetheless it is still in the RCBugFix branch and I do not find any issue in the repo just that one comment.

So who will post an issue or are you keen enough to figure out where the problem is and start a pull request?

 

Ok this didn't let me sleep so I did some research.

I think I know why but I do not know how to fix yet.

To summarize the issue:
On a fresh init of the firmware the direction of the second extruder is wrong. This can be fixed by executing a a GCODE command with a negative extrusion value on the second extruder. Then the direction is fixed.
So the problem must be within the initialization of the steppers and something happens when we execute a negative step to fix that initialization error.

The point where the steppers are initialized is in steppers.cpp.
There is the function "st_init()" which is run when the worker thread for the steppers is initialized for the first time.
And there is the function "set_stepper_direction()" which sets the directions of the steppers.
The whole steppers thing is organized that there is that background thread watching the plan and taking blocks from the plan sending the command to the steppers. That's what I understand now.
So the way it works in easy words is that on start st_init() and set_stepper_direction() is called then the thread is started and waiting for commands in the plan.
When commands arrive in the plan the stepper three take a so called block from the plan. That block includes direction bits, one bit for each axis X, Y, Z and E and if the differ from what the previous loop had set_stepper_direction() is called again!
The problem is that on init there is no block in the plan, therefore there are no direction bits. For this to work the variable taking the direction bit from the block in the normal loop is initialized with { 1, 1, 1, 1 }. That means every axis has a normal direction on init.

So if we now start an extrusion with a positive value then the directions bits are the same so the set_stepper_direction() is not executed.
But if we change the direction that function is executed and setting now the right value for the second extruder.

I hope this was understandable... I am searching for a fix...

 

I found a quick and dirty fix!
It is as I tried to describe in my previous post...
The problem is the init sequence...
If you go to "stepper.cpp" lines 567 ff:

Code:

  if (current_block->direction_bits != out_bits) {
    out_bits = current_block->direction_bits;
    set_stepper_direction();
  }

If you now just comment the condition the direction bits are read every time even if they do not change but this is important for the very first time after initialisation because initialisation is not fully complete because the way it is implemented the direction init relies on that a current_block with and acitve_extruder exists which is not the case upon init. So the direction for every extruder is set to the same dir as the first extruder.
So if we now do the direction setting every time it is run when the first command for extruder 2 comes in too and then the direction are set the right way!
New code looks like this:

Code:

  //if (current_block->direction_bits != out_bits) {
    out_bits = current_block->direction_bits;
    set_stepper_direction();
  //}

And viola right after string up the direction of extruder 2 is right without moving it one time in the opposite direction...

So now that I understood what's happening I will file an issue to discuss with the debs of Marlin because I do not fully understand why that condition is there and what it will cause if I just deactivate it... Maybe a more sophisticated solution is necessary...

 

I opened an issue on the Github Marlin repo for this: https://github.com/MarlinFirmware/Marlin/issues/3144

Now I can finally go to sleep 2:30am here but I will have a good sleep

 

I have to correct that what I said a bit. The way Marlin works with multiple E axis is that most functions only have an implementation for four (4) axis X, Y, Z, and E. If there are multiple extruders it is accomplished by the active_extruder setting of the current_block. So on init of the stepper interrupt loop Marlin does not tell that loop that there are multiple extruders and set the direction just to the direction of the first extruder. When then the first command come for the second or third or fourth extruder and they have a different direction from the first one set but the direction you want to turn is positive the condition to load the correct direction is not triggered.
This causes the issue...

 

I'm glad you experienced this too and have found the issue / fix, I thought I was going mad at first.

 

I was too anxious so I did some more work and replaced my issue with a pull request:
https://github.com/MarlinFirmware/Marlin/pull/3161

 

My PR got merged into the RCBugFix branch... next RC it will be in!