Large GCode File Issue I am sure this has been discussed at length but

Large GCode File Issue

I am sure this has been discussed at length but I can’t seem to see information specific to my issue. Relative to CNC cutting: Because ChiliPeppr cannot handle large files I separate my final (entire) file into separate parts to a size ChiliPeppr will accept. So for example when part1 finishes, the tool raises to a safe clearance, shuts off the spindle and stops. At this point I clear out the recent files within the ChiliPeppr workspace (using the ChiliPeppr link). I then load part2, start the spindle and lower the tool to the cutting depth. I then run part2. Now all seems fine however for some reason the y axis value shifts approx. 3 or 4 mm. Please keep in mind the machine has not physically moved in the x or y axis after part1 has finished. (For reference, the last cutting motion from part1 is y travel) It’s still at the last coordinates and final resting point at the end of part1. Any idea what causes this and a work around? Is there a small amount of code in the buffer at the end of the program? I’ve ruined too many pieces due to this issue and just can’t quite put my finger on it. The last failure I had, I tried homing the machine, resetting zero and restarting the part2. However this did not resolve the phantom y axis offset (shift).

Any help or insight would greatly appreciated.

Forgot to mention I have a tinyG controller. Specs below:

[fb] firmware build 440.20
[fv] firmware version 0.97
[hp] hardware platform 1.00
[hv] hardware version 8.00
[id] TinyG ID 3X3566-YQX


What work coordinate system do you use? I recently ran a long multi part job the way you are describing since Fusion 360 spit out a huge Gcode file and everything was fine, but I did make sure it was just using machine coordinates (G53) to generate the Gcode. Perhaps you are using G92 temp offsets and then some Gcode command is wiping your temp offsets?

Thanks John. I don’t specify the coordinate system in the GCode however I use G54 within ChiliPeppr. However that is a good tip with using G53 I’ll have to give that a shot. I do re-issue G21G64G17
G90 at the beginning of each partial GCode file but I don’t think this will affect the result. [Unless you correct me ;-)].

A little more info. I cut a small reference hole in the piece to gauge location accuracy of the spindle between loaded part programs. I’ve noticed that it is not consistent however sometimes I loose approx. 0.3mm of location and other times around 3mm. However I always lose locational accuracy. The way I check this is move the cutter to the reference hole after one of the partial code files has completed. Amazing about how far off it can be. I have reduced jerk settings so there is a smooth and slower transition upon acceleration and deceleration on movement. So I think I am either loosing 1) loosing some communicaton through the serial inteface or 2) somehow loosing steps in the motor or 3) somehow skipping a “tooth” on the belt drive. The belt gear is about 25mm in diameter with 24 ~ 28 teeth (didn’t take it off but just looking at approximate calculations here) So doing some rough calculations missing a gear tooth would result in roughly 3mm of lost travel. (25mm dia * 3.14 /24 teeth). But that wouldn’t explain a 0.3mm deviation in travel. All my belts are snug and double checked. I’ve also noticed that if I empty the planner buffer (with %) at the end of a partial program the axis shifts about 0.3mm on the axes coordinate readout. I would have to run it a few more times to determine whether the machine moves also or not. (Not sure yet if the machine moves also). Any further ideas or comments?


I have seen on some versions of firmware on TinyG controller lose position on a feed hold / wipe operation. You may want to experiment with different versions.

Thanks John. Awesome interface by the way. Good job. Have a great day.