@OrturTech , I was trying to recover an issue i had with movement out of bounds and discovered the following issue where you also answer this with a strange behaviour in maybe overscan.
I may have found the reason and I’m not sure if this is on the Ortur side or on the Lightburn side.
What i noticed in the errors i got was this
Send: G0 X-79.066Y-133.95
Recv: ALARM:2
Changing monitoring state from "Printing" to "Cancelling"
Changing monitoring state from "Cancelling" to "Operational"
Recv: [MSG:Reset to continue]
Send: \x18
Recv: ok
Recv:
Recv: Ortur Laser Master 2 Ready!
Recv: OLF 140.
Recv: Grbl 1.1h ['$' for help]
Recv: [MSG:'$H'|'$X' to unlock]
Send: ?$G
Recv: <Alarm|WPos:79.063,133.950,0.000|FS:0,0|WCO:0.000,0.000,0.000>
The Alarm is raised because the movement from position 79.063 back to the start position 0.0 is a travel of X-79.066, which is off by 0.003!!
If you start from absolute home 0.0 you will end up at -0.003, which is out of bounds and raises the alarm.
Enclosed you see the gcode exported out of lightburn if you need this for reference.
ps, i can confirm that this rounding is the reason of the alarm.
When moving the head G0 X0.1 Y0.1 entered manually in terminal before the print, the issue is resolved
What is odd though is the Gcode itself is sent with the offsent
And is when the “recieved” message comes from controler that the Alarm 2 is triggered
a) can you confirm if this happens WITH and without overscanning enables
b) Yes moving the origin 0.1mm would help for sure but that is just giving leeway for the error to happen and NOT stop the engraving
The file i sent was without overscan.
Enabling overscan makes the print fail after a few lines with Alarm 3
It is really ‘just’ an issue with rounding.
I removed the lines from the code and ran just the engraving from 0.0
I hadnt noticed in the grand scheme, but the size of that engraving was 19.997 high.
The original size of the svg is bigger. When typing 20 with aspect ratio locked, it resizes it consistently to 19.997
However, when I type 20 again, it scales the picture up again to 20 high.
(you can test this yourself by scaling the svg way bigger with your mouse and then typing 20 in the height field)
And with that picture at 20 high, the rounding isnt an issue and it just works.
hmmmm… See whats in this terminal output…
Its not a belt tightening issue, as i tell the carriage to go all the way to the end and back to exact the same rounding error
Trying as we speak
Still need @LightBurn@Rick to give their view
As the gcode seems to be streamed itself to the machine with the rounding error, and not the machine converting it - as it cant really machine is a bit dumb it does what its told to do.
Well… it seems the machine doesnt do exactly as it is told
If i tell it to G0 X1.333
It reports back that it has moved to X1.338
And there is no offset of absolute vs working position.
We were being a little silly, this does NOT resolve the problem but explains the issue
At a resolution of 80steps per MM. we wont have resolution for 3 decimals
If we bump - for the sake of argument - X steps per mm to 360 (4x as much)
hmm, The way i understand; with 80 steps/mm you can only step in 0.0125mm increments.
so if you cant divide the distance by exactly that, there will be a rounding error, which will eventually add up.
Would microstepping resolve this? That works for the z axis on my 3D printer
Sounds like my workaround of moving X and Y 0.01 after homing still is the only reasonable solution, as we cannot change the resolution of the steppermotor and even if we could, the issue
