Extruders offset bug

Braccoz

preface:

i stumbled on this bug back when i had single carriage-dual extruder but found a way to work around it by just putting the offset in ext0 rather than ext1, but now with dual-x carriage there's no way around as i will be needing both offsets.

machine: prusa i3 with dual x carriage

firmware: repetier development 19th april 2017

board: ramps 1.4 + external 6th stepper driver

description of the issue:

i'll simplify as much as possible: after switching from an extruder that has an offset, the next move of the newly selected carriage will be increased by the offset of the previously selected carriage.

this is a big deal as it makes carriages crash into eachother and into axis everytime.

steps to reproduce:

have 2 carriages:

ext0 X offset: 0

ext1 X offset: 10000 

1. home X axis with ext0 selected (bug happens regardless of which extruder is selected when homing btw)
   
2. switch to ext1 (the carriage will move 10000 steps to the left)
   
3. switch back to ext0 (right carriage will be parked back, left carriage will stand still as it has 0 offset)
4. move X right 1mm
5. watch as X moves at travel speed 10000 steps (which is the offset of second extruder) + 1mm

this when configured with proper offsets results in disastrous crashes of the carriages as the movement is at travel speed...

ps: for this test i had the machine setup with ext0 as left and ext1 as right, in contrast to the setup i had in my previous homing post, just to clarify

Repetier

Ok, it is no bug just something you do not know.

In Special case of dual x axis, the left position on be dis position 0 for extruders. Offsets are both relative to this point. SO in your example 

E0 offset -1000 

E1 offset 9000

Assuming that no crash occurs if E1 is at 0 and E0 at -1000.

Braccoz

yes i know that, i just used those numbers for the sake of simplicity

trust me it's bugged, i can make a video if you want.

on the first move after the extruder select the offset of the previous extruder gets added to the move. note that when just swapping from ext0 to ext1 and vice versa the carriages move exactly where they should, its AFTER that that the problems occur

Repetier

Do you have LAZY_DUAL_X_AXIS 1 or 0? I always tested with 1 but then it does not even move on switch of course. Need to test when I get some time, but during tests 2 days ago I did not get any collisions, but was also testing something different.

Braccoz

tested both with and without lazy dual x. bug is still there

i'm looking at the code, i'm pretty sure the fix will just be something very simple like commenting out/adding a function call, but i have to make sense of entire parts of the firmware before

anyway, my guess would be that in the process of switching the extruders, the old x offset is not updated/adjusted somewhere in some other class (maybe printer?)

Braccoz

update:

i seem to have found the fix for the non-lazy dual x, it was just a missing

Printer::lastCmdPos[X_AXIS] = lastX;

in the non-lazy codepath.

the lazy dual x seems to work properly, except for when ext0 is on the right, now working on that

Braccoz

another update: 

lazy dual x logic seems correct even with ext0 to the right, it just needs a move of ext1 (leftmost extruder in this case) before starting to work correctly

so this may be another easy fix if i find the right spot in the code...

nevermind that. when lazy dual x is enabled everything seems to work correctly (with the-X_HOME_DIR fix) even with reversed extruders, albeit not in an intuitive way (of course i should say).

gonna try a test print tomorrow to confirm everything is ok and then will send pull requests for the other 2 fixes

Repetier

Great, will gladly include them.

Braccoz

submitted them.

i did try printing with various combinations of settings and i must say that while when LAZY_DUAL_X_AXIS is enabled everything works, there are still major issues when its disabled so more fixes will be needed.

of course i verified that said issues are not regressions from my fixes.

i would advice everybody that has dual x to enable LAZY_DUAL_X_AXIS, and i would put that into the stock configuration.h as it is missing right now

Braccoz

ok found the bug.

basically, without LAZY_DUAL_X_AXIS, everytime a toolchange is requested the X axis is moved to current position (already offsetted) + offset, so basically offset * 2. 

this also explains why LAZY_DUAL_X_AXIS works.

gonna try and fix that too

Braccoz

fixed that too.

it was something related to offsets AND homing when reselecting the currently selected extruder. i figured the cleanest, simplest and best solution would be to just skip executing any code if the next extruder is the same as current.

However, as i do not know all the quirks of the firmware and there may be some situation where part of the switching code needs to be run even if next extruder is the same, i restricted the return to just dual x configurations, tested it and can confirm it works.