I think I saw this issue today as well. I was making 4 large pieces for a template for a leeboard. First 2 pieces with no problems. Then the 3rd piece failed 3 times in a row in the exact same spot, when the router made a long diagonal move over the center of the machine. This was the move from the home position to the first cut position, the first z movement.
2 times , when the router stopped moving, the BL kept spooling out lots of belt so I switched power off to not make the belt spooling in the wrong way.
retract, extend, rehang dance
The third time it stopped moving it gave the 15mm warning, with loose belts, and immediately lost connection, I had to power off and on to be able to connect to the machine and control it.
After this I thought it might be something wrong with the g-code, so I tried to cut the 4th piece of the template: this went without a problem.
Then the fourth attempt to cut piece #3 and again it failed in the exact same spot as the previous 3 times, 15mm error and lost connection, power off and on.
I had been jogging diagonally over that spot before cutting, to see if the machine would stop if I did that.
So in the final attempt I didnât start the job with the router at the home position, but I jogged it to near the first cut position before starting the job. This time all went well, so not a problem with the g-code.
Maybe a workaround found.
One thing I noticed, but I donât know if it contributes to the problem, is that the home position for the cut was displayed on my screen at the center position of the machine bed. While in reality it was far more to the lower left.
Iâm using 0.88 on a M4.0 with soldered bridges and hot-glued connections
That does sound like exactly the same issue! Excellent testing to track down exactly what is going on.
To me this sounds like maybe some sort of divide by zero error or something like that in terms of how the math is being done. Like for some possible frame dimensions there is something funky happening in the math which is causing it to crash.
One possible easy fix is that new firmware is coming out tomorrow which frees up a TON of memory so if there is something funky happening with the math maybe having more memory available will help in some wayâŚthat being said I donât think floating point math works that way.
It does seem like this is a confirmed issue, although unfortunately itâs quite tough to reproduce since it seems to be frame specific.
I measured the sides and diagonals and checked in CAD the frame dimensions, and corrected the z- values of each anchorpoint.
Frame dimensions are roughly 3800x2600, so it is not a problem solely of square frames