Loosing "0" but not really

[rwhite44]

This problem comes and goes but seems to act the same way. At the very end of a run the last thing it carves, such as, I just carved the word “Year” and this was at the end of about a 20 minute run the “r” was up and to the right about 1/8” from where it should be and when it returned to the home position (bottom left of the board) it was off that much. I clicked on the Home Button (0,0,0,) on the computer and it returned to the correct home position. This is getting very frustrating. I usually run the machine between 75 and 80 percent, speed wise, which has helped. I try to keep the rails and drive screws clean. Why would this machine cut in the wrong position and still know where the “0” home position is. Any ideas would be appreciated.

[jeb2cav]

Hi - you're not really losing z0. The g-code compiler for the Shark writes an ending position of x0, y0, z0.8

So, that's why it returns correctly and as you'd expect otherwise when you toggle the move to 0,0,0 button after the job has completed.

end of tap file.jpg

End of Tap File

(4.17 KiB) Not downloaded yet

I've attached a screen grab of the end of a tap file. In this case, it moved "up" to z0.2 as its last cut move, then moved to z0.8, then moved to x0, y0.

So, the behavior you are seeing is expected, and you do not lose z0. Hope that helps.

[rwhite44]

Thanks Joe but maybe I didn't explain the return to home correctly. When it did come home after carving The "e" in the wrong place the x and y were not at zero they were both a few tenths off the z was ok at a few tenths above the board when I hit the home (0,0,0) the x and y went to "0" and of course the z also went to "0" and everything was setting just where it was supposed to be but the "e" was carved in the wrong place. Hope this helps explain it better. As i said this has been an intermittent problem sence we got the machine about a year and half ago and it is always on the last graphic it carves.

[jeb2cav]

I'm sorry, I missed that aspect of your question in your first post.

If the last letter is off in alignment, yet the tool returns to the correct position after hitting move to 0,0,0, then I would suspect some design issue that resulted the letter being out of alignment. But, it sounds like you may be using the same file and only intermittently getting this failure (?).

I've had a few incidents where my shark lost its location (my perspective), and in those cases when I stopped the cut and hit move to 0,0,0, the machine was no longer at the "correct" spot. From your description, it sounds similiar - last letter not right, tool end of job resting location is "off" by a similar amount. Yet, when you hit move to 000, it returns to the correct location.

Have you had this happen using the same tap file - ie using the same file, it cuts as expected before or after this event on a second try?

Of course you've kept the shark clean - I assume lubricated as well (have to say it).

The really confounding part of this issue is the correct return to zero after stroking move to 000. This makes me think there is some issue with the tap file as compiled.

So - does this happen with the same file or just intermittent yet similar condition when it occurs (ie the last letter)?