On two signs that we've tried to make recently, we've had issues where the machine starts off cutting correctly, then part-way through it shifts from where it should be. On the first one, about halfway through a clean-out V-Carve section, the machine shifted about 1" to the left of where it should be (X-axis) and tried recutting the section it just finished, only 1" to the left. We resaved all of the toolpaths and tried again today. This time, it worked fine for a while, then starting running too high; the point of the v-carve bit was about 1/4" above the top of the material, when it should have been about .075 deep.
The first thing that I checked today was the router to make sure that it hadn't moved up in the bracket, and it was good. We paused the machine, rather than stopping it, and I noticed that the coordinates for the Z-axis and the G-code did not line up. I attached a screenshot of the controller. The Z-axis coordinates show that the bit was at 0.241 when, according to the G-code it should have been at -0.075.
Machine bumping a hard limit will result in following coordinates being off by the amount it would have traveled past the limit. The Sharks have no limit switches or marks to warm you your cut may go past where the gantry or router would bump into the end of travel.
Static discharge this time of year can make the motor or controller skip/forget a move resulting in following coordinates being off (right but in the wrong place)
A coupler could slip suddenly then recatch resulting in following coordinates being off.
The router carriage bumping into a clamp or anything else that prevents moving in a direction will throw off following cuts.
I've had all these things throw off a cut at one time or another. If you tell your machine to move to 0,0,0 when done with one of these flawed run and it moves to some other point than it started from then oin of the above is very likely the cause.
I find it hard to understand how this is a hardware issue. If I run into a hard limit I will lose step but the software output should still match the G-code. There are no sensors that tell what position the bit is at. It is only software that goes G-Code to steps to position in the display window. I was just forced (expired license code) to upgrade control panel 2.01 and now have the same issue but not as bad. So far it has only been small fractions of an inch and primarily in the Z-axis.
From your display it looks like you are not running 2.01. Have you upgraded to the latest version of your control panel? Prior to this latest upgrade I always had position exactly matching G-code. It looks to me like there is a problem with at least my version of the control panel and perhaps others as well.
if you ram the machine into the top or the side and the motor still turns, even a little bit, then the software will think the position is higher or further over than it is because it thinks the motor moved a bit further than it actually did. That would result in a change in the (0,0,0) location.
Why would the G- code window in th3 control panel and the position display in the control panel show different values!!!! That is what I am seeing and the original poster on this topic. I agree with the statement that the zero will change and the part will be ruined but when that happens the G-code and position display should match.
The only way they cannot match is with a software issue In The control panel?
Your x and y coordinates do not match your part coordinates either so you don't have a valid argument at this point. I don't know if the stopped line is reading ahead of the machine coordinates or not? or the pause is the next line the machine will read.