LAZY_DUAL_X_AXIS and homing behaviour doubts

Braccoz

here i am again bothering you with dual x stuff :P

i got a couple of questions regarding homing/moving when LAZY_DUAL_X_AXIS is enabled.

1. when LAZY_DUAL_X_AXIS is enabled, homing all axes makes X home twice. for example my order is YXZ, it becomes YXZX. is this intentional? why?
2. if trying to move Z while the current extruder is parked, both Z and X will move at a snail pace until X reaches its offset. it's really really annoying when having one offset larger than the bed itself :P is that intended?

Repetier

1. I use ZYX and it does it only once. Problem is lazy means x moves out first move after homing, so if Z comes after X it is out and that is not intended if using lazy, so we rehome x so it is in park position.

2. Again lazy = move x next move. Only exception are pure E moves. So it moves with next Z and there you have Z speed as limit I guess, so not so fast. One solution could be to add pure Z moves also to ignore it like for E moves.

Braccoz

i did some digging and come to some conclusions

the 2 "issues" are related to the sledParked logic. about the double X homing, it happens when X is not the last axis in the order, because there is this at line 2068 in printer.cpp

if(!sledParked && xaxis) { // park sled

        homeXAxis();

this is where the 2nd X homing gets called. i believe it may be there because of the probing stuff, because otherwise it would be just redundant as at that point X is at home for sure.

a potential "fix" would be to just force sledParked to true for homing orders without probing/temp but idk, code would be messy and redundant.

the other way, which i think would fix issue 2 too, would be to refine the sledParked logic to not unpark unless really necessary, but i guess it could get really complicated (it looks like it is enough already) and prone to errors

Braccoz

Repetier said:

1. I use ZYX and it does it only once. Problem is lazy means x moves out first move after homing, so if Z comes after X it is out and that is not intended if using lazy, so we rehome x so it is in park position.

2. Again lazy = move x next move. Only exception are pure E moves. So it moves with next Z and there you have Z speed as limit I guess, so not so fast. One solution could be to add pure Z moves also to ignore it like for E moves.

did not see your answer as i was writing the followup post :P

now that you mention it, as the current implementation already ignores pure E moves it could be feasible and relatively harmless (i know i will regret saying this...) to extend it to pure Z moves too and solve both issues in one fell swoop. gonna try, wish me luck

Braccoz

yea so the sledParked changes were very easy except that's only half of the story, and the other half is about offsets.

accidentally stumbled onto another bug about offsets with lazy_dual_x: 

if you have an Y offset for one extruder, home the machine, switch to ext1 then back to ext0 without making a move the machine won't move anymore until re-homed.

Braccoz

ok i *seem* to have everything sorted out.

first, the bug with y offsets and lazy_dual_x was that when swapping extruders the lastCmdPos[Y_AXIS] had to be saved and restored in a similar fashion to the lastCmdPos[X_AXIS]

then, i have the extension of lazyness to pure Z moves implemented with a new flag LAZY_EXTRUDER_OFFSETS that when true, just wraps a check for 

if (com->hasX() || com->hasY() || com->hasE())

around the x-y destinationSteps calculation in Printer::setDestinationStepsFromGCode

so far it all seems to be working, but i'll hold off pull requests for a while as i prefer to test the code for quite some time to avoid creating more issues than i solve

Braccoz

so in the end i think i'm gonna scrap this idea for 2 reasons, one being that i noticed the commands from the controller don't follow the same path as the gcode commands, thus requiring additional modifications to the code that are far from pretty, the other being that the behaviour that i'm trying to avoid would still be there on Y axis, which is far more dangerous as far as crashes go because it has a much higher travel speed.

oh well, atleast i fixed a bug in the meantime