while cutting the braces for the Maslow frame, the system would just start in some random direction part way through a cut. Observing the G Code scroll on Ground Control I observed the following:
Buffer overflow!
Buffer Used: 127
Buffer Number of Lines: 5
Buffer Begin: 99
Buffer End: 98
Buffer Contents: G3 X28.7687 …
These overflows would also randomly cause the system to loose its center point and the sled location would be inaccurate.
Wow, seeing a buffer overflow here Can't cut circle - it cuts a squigly squashed star instead - #18 by Gero, but in your case it seems to be cause by something else. 
The line Buffer Contents has strange /n in it…
Can you share the .nc?
Some notes: I am using GC 1.02 and FIrmware 1.03.
These files were generated from MakerCam.
They were positioned about 18" to the right of center.
Here is the .nc fileBrace Type 2.nc (9.2 KB)
Here is another: Brace Type 1.nc (2.4 KB)
Is there some log file that catches this sort of error? If not, what is the downside to adding one. I just happened to have a semi-repeatable issue that I just caught out of the corner of my eye.
In your GroundControl folder there should be a log.txt file with the error
I failed to replicate a buffer overflow with FW1.02/GC1.02 and FW1.03/GC 1.02.
Both files run smooth on my test system (no motorshield)
I am stuck here.
Are you able to replicate the error? Does it always show up at the same line?
No, it shows up at different places during the outline cut. I had run the cut several times, dry runs, before. Not sure if it blew the buffers during those runs.
Did you place the cut over to the right side of the cutting surface?
In addition to the log file @Gero mentioned, there is some info to be seen in the terminal session if you run GC from the command line.
Here is the log file from the overflow runlog.txt (648.6 KB)
Not that it would help, but starting at line 30475:
Sent: G3 X29.017 Y-5.6744 I0.1245 J0.0109
G1 X28.8073 Y-3.9487 F60
Buffer overflow!
Buffer Used: 127
Buffer Number of Lines: 5
Buffer Begin: 99
Buffer End: 98
Buffer Contents: G3 X28.7687 Y-4.0391 I0.0863 J-0.0904 \n \nG3 X28.7691 Y-4.05 I0.125 J0 \nG1 X28.9013 Y-5.5606 \n \nG3 X29.017 Y-5.6744 I0.1245 J(End of Buffer)
Buffer overflow!
Buffer Used: 127
Buffer Number of Lines: 5
Buffer Begin: 99
Buffer End: 98
Buffer Contents: G3 X28.7687 Y-4.0391 I0.0863 J-0.0904 \n \nG3 X28.7691 Y-4.05 I0.125 J0 \nG1 X28.9013 Y-5.5606 \n \nG3 X29.017 Y-5.6744 I0.1245 J(End of Buffer)
Yes, from the video I assumed ~36 inch from centre and that went true without issues.
That it happens at different places excludes anything from the .nc, I guess.
Interference in the USB cable? What keeps nagging me is the /n in the buffer, is that 'end of line? and how does that get in there?
Edit: from the log ($7=2) you are using triangular? There is a negative value for $6=-47 (sled centre of gravity)
Edit2: Kindly upload the groundcontrol.ini from your home folder. Will try if I can replicate something with exact your settings.
@Gero, were you running with the z-axis motor switch ‘on’? The log file from @George_Mallard indicates he was using a manual z axis. I just ran ‘Brace Type 1.nc’ first with auto-z (no problem) then with manual-z and got a buffer error with manual-z.
An example section from the log file that @George_Mallard posted above (must have a lot of the chatter removed 
):
Message: Message: Please adjust Z-Axis to a depth of -0.25 in
Maslow Paused
Sent: ~
Sent: G1 X2.242 Y8.5469^M
G1 X8.6775 Y1.9151 F60
Sent: G3 X2.1668 Y8.572 I-0.0752 J-0.0999^M
G3 X8.7784 Y2.0377 I-0.0242 J0.1226
Sent: G1 X0.67 Y8.572^M
Sent: G3 X0.545 Y8.447 I0 J-0.125^M
G1 X8.7784 Y3.5628
Buffer overflow!
Buffer Used: 127
Buffer Number of Lines: 5
Buffer Begin: 84
Buffer End: 83
Buffer Contents: G3 X8.7285 Y3.6627 I-0.125 J0\r \n \nG1 X2.242 Y8.5469\r \nG3 X2.1668 Y8.572 I-0.0752 J-0.0999\r \nG1 X0.67 Y8.572\r \nG3 X0.545 Y8.(End of Buffer)
Buffer overflow!
Buffer Used: 127
Buffer Number of Lines: 5
Buffer Begin: 84
Buffer End: 83
Buffer Contents: G3 X8.7285 Y3.6627 I-0.125 J0\r \n \nG1 X2.242 Y8.5469\r \nG3 X2.1668 Y8.572 I-0.0752 J-0.0999\r \nG1 X0.67 Y8.572\r \nG3 X0.545 Y8.(End of Buffer)
This was the sixth z-axis change in this .nc file. I’ve only run this one file, and only once, but there may be a clue here.
I was running with auto-z, but will do manual now. Good you could replicate an error.
Edit: Bingo: Can replicate!
Edit1: Confirmed that it happens at different positions in the code.
Edit2: Confirmed that it also happens with FW1.02/GC1.02 so FW 1.03 is found not guilty 
Great job narrowing it down to when the z-axis is off.
It seems strange to me that we’re suddenly seeing buffer issues again. I will dig into this right away!
Thanks Bar, any chance of that fix making it into a release build soon?
Based on Maslow history, I would say that you will get a personal test release within hours/max days and by next Wednesday the bug you found is history.
Yes! The fix will absolutely be a part of the next release, and we will get you an updated version to test before then.
@Gero, since you’re temporarily running ‘disconnected’, this is a good chance to try the FAKE_SERVO mode in the new firmware. 
. Fun to watch the fake Maslow trying to keep up!
Alright, I think I’ve got it caught. @George_Mallard when you have a chance, will you give this firmware a try and let us know if it fixes the issue?
cnc_ctrl_v1.zip (77.1 KB)
If you are curious as to what was going on, there is a GitHub issue here which shows what’s going on, with the solution in this pull request.
Thanks for catching that one!
