I’m trying to diagnose and debug a head scratcher I’m encountering with a VCarve-generated gcode file for an inlay project. I’m hoping somebody can help me identify the issue, and I can attach the gcode file if that’d help.
Problem: Shapeoko Pro appears to have WCS change in the middle of a job. Steps:
Zero to X/Y/Z of the stock corner before the job start
Job progresses with no issue
Observe that the cutter is shifted to the right by about 5mm about 80% of the way through the job
Wait for job to complete
Rapid to current X/Y 0,0 and observe that it moves to ~6mm to the right of the corner
This would usually tell me that steps are being lost and I need to go look for EMI or loose cables or take lighter passes (although these passes are very light, 0.15" max depth of cut). However, when turning the machine off and on, and re-initializing it (re-homing against the limit switches), it still goes back to ~5mm to the right of the corner.
I’d expect that once the machine re-homes to machine 0,0, it would correctly find the 0,0 of the stock corner. So this tells me that the WCS itself is changing in the middle of the run to be ~5mm farther to the right. Has anyone else encountered something like this before?
During initalization the homong switches trigger and move off the trigger position. Different firmware has changed the standoff position and 5mm sounds right. I would power down and slowly move in x and y to limits and check for rough spots. Check your v wheels for proper tension.
It’s not clear from what you’ve said (sorry) but is this a ‘new’ event, since starting to use the machine, or has it always been the case? Also, when you…
…does this manifest itself as a cut which is out of alignment with the programmed cut?
Also, how does it look in ncviewer or another g-code previewer?
There’s no v-wheels as this is a pro and I haven’t done any firmware/software updates between runs. Everything is consistent between homings. The limit switches are hall-effect sensors and are far more precise than 5mm (C3D support staff claimed within a few 10s of thou), so I don’t think it’s a slop issue in the switches either, unless I’m misunderstanding you.
This is a new event, I’ve used the machine before and relied on the Pro’s homing to recover from crashes many times prior (where it would re-find the 0,0 I’d probed to within a few thous of an inch).
The visualized gcode is correct according to ncviewer, but the actual cut is incorrect when run on the shapeoko. The shapeoko pro also re-zeroes to an incorrect location after power-cycling and re-initializing the machine, which is the real concern. I’ve inspected the hall-effect limit switches and they appear to be stationary.
Yes, ~80% of the way through the gcode program being run on the machine, it looks like the machine looses steps in the X direction and the spindle is shifted to the right about 5mm. When visualized on ncviewer, this isn’t the case. The X-axis appears to be smooth and the linear rails are clean, and the connection to the X-stepper doesn’t appear to have any issues (checked the connectors).
So that makes me wonder why the machine re-homes to an incorrect location after being power-cycled. It makes me think that the WCS has changed in the controller somehow.
You could toggle to absolute machine coords (by clicking on the Position label in CM) , and check whether the X/Y absolute values are the same before/after the event. If they are, but the physical positions still differ, you will know that the stored zeroes are not altered, but something mechanical is going on. Which I would bet is a loose setscrew on the X stepper motor pulley. If the absolute values change, then it could be on the software side but I would be very surprised.