Toolpath shifting several inches in the middle of the program

I have an SO3XXL and recently installed the HDZ and also upgraded to a 400Hz spindle with VFD. I am working on a project that has a 6 hour toolpath (It’s an enormous plaque). I am using a very old laptop to drive the SO3 and use both Carbide Motion and CNCJS. My SO3 is in my UNheated garage and I live in Northeast US (CT), so it is currently pretty cold. About 2 or 3 hours into my program, the SO3 shifts by many inches. I have been in the garage during one of these shifts and the carriage is not getting hung up on anything, it just makes a detour in the middle of a cut. I use Fusion 360 to create my project and G-Code, but I don’t think Fusion is the cuplrit. The shifts are occuring at different times and locations and seems to be random.

I broke up my toolpaths into smaller GCode files and they seem to be running fine. I also put a heater on my computer, so I was wondering if maybe the computer isn’t happy in the cold and is skipping a bunch of lines while sending to the SO3. This phenomenon has occurred with CM and CNCJS.

When I first hooked up the VFD, I had an issue with the SO3 disconnecting from the computer whenever the VFD was turned on, but that turned out to be a grounding issue with the VFD shielding. I had the shield grouned to the VFD ground. Once I isolated the VFD shield wire, I had no problems with maintaining a connection.

Usually this is a mechanical failure, usually caused by cutting a slot as narrow as the endmill which results in 100% tooling engagement — best practice is to enlarge the cut so that only one side or the other of the endmill is cutting at full depth.

I would recheck the zeroes after the cut, to prove that steps were lost.
Then possibly redo the same job as an air cut: if there is no shift then, chances are it’s mechanical as Will mentioned.
Also, if you could save the full console logs for a cut that has this issue, it will be interesting to check whether there is anything suspicious in GRBL messages (or even double check where the Gcode commands asked the machine to actually go, and compare that to the original Gcode file, to rule out data corruption)

@WillAdams and @Julien I was using a 3d adaptive toolpath (Fusion 360) and the GCODE file was over 500,000 lines. I was using a 0.25" end mill with a 0.125" depth of cut at 50in/min and 16000RPM. ONe of the shifts was about 8-10" (I didn’t measure it, but it was huge. Definitely not losing a couple of steps). I did move the cutter back to the zero point and I think it had shifted, but only by about an inch (I didn’t measure that either). The shifts are random.

I have been cutting for several hours today and haven’t had an issue. (Of course the cutter is probably veering off course right now). I did break the file up into smaller chunks so I am running about 1.5 hours at a time. Plus I have a heater pointed at my computer. It’s cold enough that the touchpad doesn’t work :grinning:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.