Home all: X/Y axis is driving against endstop
in Bug Reports
If i start to home the axis by pressing home all, it first seems to work correctly. If the z axis starts to home, the last axis which was homed is driving slowly (z axis speed?) against the already triggered endstop. After the z axis is homed, y is driving to the correct position. I had the homing order xyz. I suspected a crosstalk between the wires so i separated them but the problem still existed. I changed the homing order to yxz. Now the x axis was driving against the triggered endstop. I thought i had a wrong configuration but i didnt found an option to solve this problem so maybe its a bug. If i try to home every axis separetly it seems to work correctly (at least i think so). The prints are looking great so i dont think the printing process is affected.
My configuration:
Repetier fw 1.0.3
Arduino due with Ramps configured as Smart Ramps
Microswitches as endstops for x and y
My configuration:
Repetier fw 1.0.3
Arduino due with Ramps configured as Smart Ramps
Microswitches as endstops for x and y
Comments
Homing order is just calling the 3 homings which work in the order
I admit I got a bit confused when the wrong move happens. Would you say all moves first finish correctly and then you get an extra move ignoring end stop? I ask because if you look into void Printer::homeAxis(bool xaxis, bool yaxis, bool zaxis) for cartesian printers you see there are many possible conditions where at the end a new position is targeted for. So my guess is that one of those is causing the extra move.
Its realy confusing. I also changed the y stepperdriver and the position of it to the Extruder 1 slot to exclude hardware errors but no change.
The more confusing point but not confirmed: I started home all at a high z position and there was no error (not confirmed because im not realy sure if it was home all or i homed every axis separetly.
Today i found the parameter "#define min_software_endstop_x/y/z" (which is not represented in the online configurator?) in the configuration.h which should prevent moving below 0 coordinate but i cant check it now if its true in the used file. Do you think this could be the solution?
The next option i already considered and wanted to try is to set a big enough value for these parameters to avoid the collision. But if its really a bug then its a workaround and not the solution.
Today or tomorrow I will try some other settings.
There is no dependency distortion correction - end stop testing.
From your description I take that y axis is moved much slower then z axis, also z axis has more steps, correct? I mean if 2mm back move are sufficient it can't be much. Of course it should be zero steps during z move. But it can in deed move a bit when autoleveling is enabled depending on the rotation of bed. But not on the testing move as they are axis only. Only when positioning afterwards. So still a strange issue.