Recv:22:55:10.517: Warning:Move to illegal position prevented! Position should not be trusted any more!
Recv:22:55:10.517: XT:-65.09 YT:399.92 ZT:160.17 and as you see you are within limits. Only critical is XT which is within limits if I ignore roundings not visible. But min/maxPosOff have 0.1% increased values of rotMin/max to fix that. But maybe since float is not high precision it is even higher.
So current guess since all values look ok is to increase the allowed deviations a bit. This is in MotionLevel1.cpp line 311
void Motion1::updateRotMinMax() {
where they get computed. It is actually this part:
for (fast8_t i = 0; i <= Z_AXIS; i++) {
rotMax[i] *= 1.001;
rotMin[i] *= 1.001;
minPosOff[i] += rotMin[i];
maxPosOff[i] += rotMax[i];
}
When it is only rounding we should modify it into something that also adds a constant for rounding errors. So please try
for (fast8_t i = 0; i <= Z_AXIS; i++) {
rotMax[i] += 0.01;
rotMin[i] -= 0.01;
minPosOff[i] += rotMin[i];
maxPosOff[i] += rotMax[i];
}
instead. This gives us 0.01mm extra in all directions. Float has 6 digits relevant so that should be significant for printers up to 10 meter and 0.01mm won't hurt loosing as print space.
I see by looking on my printer the following movement:
1. Homing z
2. moving down definetly more than 10 mm (I think roundabout 26, right?
3. Homing y
4. Moving y to smaller values, roughly 10 mm?
5. Homing x
6. Moving x to higher values
7. It moves up (to larger z values), bit the other axis are not moving anymore.
Is this intended?
By the way: The result seems to be okay from my observed movements, but I don't understand why the multiplication of a negative value (here -65mm in the x-axis) gives the correct value. I would guess that for a negatiove axis value one should multiply it by 0.999 instead of 1.001 ?!
edit: mistake. So in any case it should be 0.999 if this results in a real movement to have some safety-space around it? You may see, I am not familiar. So if you think my thought is rubbish, ignore ist.
What we wanted was increasing allowed dimension. min is always negative so -10 * 1.1 is -11 which is more to outside. I like your idea adding 10 as well. Here you have
Recv:23:39:01.386: maxPosOff: 468.01 410.01 170.48 For position Recv:23:39:02.216: XT:-65.09 YT:399.92 ZT:160.17
So for xy it is definitively no rounding error here. Objectively it must be Z then having a rounding error. It shows 160.000 in official coordinates and gets compared with stored z max. So also one of the other results showed y axis please add debug message sin the failing position test. Here a good version: PrinterTypeCartesian.cpp line 34
shows clearly it is just a rounding error we have here. Just uploaded a fixed version so no more tests required. You can just use latest version without any changes.
Comments
auto level disabled:
But normally you do not want echo on.
The problem is getting really crazy. It seems we've done everything correct.
This is what is used for x and y transformed as limit.
Then you get:
and as you see you are within limits. Only critical is XT which is within limits if I ignore roundings not visible. But min/maxPosOff have 0.1% increased values of rotMin/max to fix that. But maybe since float is not high precision it is even higher.
So current guess since all values look ok is to increase the allowed deviations a bit. This is in MotionLevel1.cpp line 311
where they get computed. It is actually this part:
When it is only rounding we should modify it into something that also adds a constant for rounding errors. So please try
instead. This gives us 0.01mm extra in all directions. Float has 6 digits relevant so that should be significant for printers up to 10 meter and 0.01mm won't hurt loosing as print space.
I like your idea adding 10 as well. Here you have
For position
Recv:23:39:02.216: XT:-65.09 YT:399.92 ZT:160.17
So for xy it is definitively no rounding error here. Objectively it must be Z then having a rounding error. It shows 160.000 in official coordinates and gets compared with stored z max. So also one of the other results showed y axis please add debug message sin the failing position test. Here a good version:
PrinterTypeCartesian.cpp line 34
If it fails z test you might add a epsilon there:
Your debug info said 160.000 so 0.01 should be more then safe to catch it if that is the problem.
Your sequence analysis is correct. In the debug info
DX/DY/DZ are delta = relative motion distances. The last z move is adjusting to rotation.
The big z back move after z homing:
Recv:23:38:57.936: Move DX:0.00 DE:0.00 DY:0.00 DZ:-20.58
is
so in sum 20.58 to compensate rotation
And at the end you undo this. Would normally be much smaller it's just the 10mm you added on top.
##########################################################
shows clearly it is just a rounding error we have here. Just uploaded a fixed version so no more tests required. You can just use latest version without any changes.