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

Discussion in 'Calibration, Help, and Troubleshooting' started by goose117, Mar 13, 2016.

  1. goose117

    goose117 Member

    Joined:
    Sep 5, 2015
    Messages:
    22
    Likes Received:
    13
    I've been dealing with this all day...

    After a reset, when I execute this:

    M83
    G92 E3
    G1 E10 F200

    The motor turns backwards, until I execute this:

    G1 E-1 F200

    It turns backwards 1mm (as it should). Then when I execute this:

    G1 E10 F200

    It turns forward, as it should.

    Is this a known bug?
     
  2. Paul Seccombe

    Paul Seccombe Well-Known Member

    Joined:
    Oct 22, 2015
    Messages:
    74
    Likes Received:
    27
  3. goose117

    goose117 Member

    Joined:
    Sep 5, 2015
    Messages:
    22
    Likes Received:
    13
    Yea, it's driving me up the wall. It only happened when I did a full reset of the Rumba board as well, some kind of initialization issue. My work around currently has a -0.1 extrusion before the purging to make sure it's going to turn correctly.
     
  4. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    I see the same issue on my machine... Investigating...
     
  5. Springfield-Jack

    Springfield-Jack Well-Known Member

    Joined:
    Dec 20, 2015
    Messages:
    58
    Likes Received:
    4
    Have had similar issues when extruding from OctoPrint! The Gcode is correct but the behavior is reversed?The wipe before printing has started to crash the back wall and the actual wipe maneuver is reversed even after resetting offsets?Very strange!
     
  6. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    Ok I tried with the RCBugFix branch of Marlin, same issue...
     
  7. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    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?
     
  8. Greg Holloway

    Greg Holloway Administrator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    565
    Likes Received:
    397
    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.
     
  9. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    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? :)
     
  10. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    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...
     
    mike01hu likes this.
  11. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    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...
     
    mike01hu likes this.
  12. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    Paul Seccombe likes this.
  13. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    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...
     
    mike01hu and Greg Holloway like this.
  14. PsyVision

    PsyVision Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    798
    Likes Received:
    248
    I'm glad you experienced this too and have found the issue / fix, I thought I was going mad at first.
     
  15. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    PsyVision likes this.
  16. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    My PR got merged into the RCBugFix branch... next RC it will be in!
     
    Hans C., goose117 and PsyVision like this.
  17. goose117

    goose117 Member

    Joined:
    Sep 5, 2015
    Messages:
    22
    Likes Received:
    13
    Great! Looking forward to it. Good bug sleuthing.
     

Share This Page