When cutting a 15000 line part I got a buffer overflow error at line 13127 and it would not let me go past that line. If I tried to do a “go to” it would do some quick jerks and say sled can’t keep up.
What I ended up doing was deleted everything between the first few lines of gcode and line 13127, updated gcode, started again and everything worked.
Not sure why this happened. Something from makercam filling up the buffer?
If you upload the .nc I could take a look. We had a few reasons for buffer overflow in the past.
I ran the file in fake-servo mode and could not replicate the buffer overflow.
I did notice a trillion
G3 X1.2635 Y-3.7431 I0.0635 J-0.153
Oops! This gcode line has caused a calculation error, it will be replaced by: G1 X1.263 Y-3.743
Need to clean up the log, but run out of time now. Will continue later.
Any documentation on what you are doing? I would like to learn how to troubleshoot issues such as these.
I’m not a programmer, but GC seems to round up constantly because of arches bigger then a house, that parts could just be a straight line, the eye will not notice. You are at a 100/0 of an inch.
- approach for me would be to check the ‘tolerance setting’ in the software you use and increase them.
- Try the truncate in Maslow settings set to 3 after digit, this comes at own risk.
I’ve been able to run this file without a buffer problem. The buffer error sounds like it would come from the PC/GroundControl side rather than the firmware - what platform is GC running on?
If you’re using the development version of GC, there is an experimental ‘Buffer Gcode’ setting at the bottom of the Settings page - what was its setting when the error happened? It defaults to ‘OFF’…
grep -r “Oops” log.txt | wc -l
counts 2121 ->Oops,<- in my log.txt file after running the code.
Thank you @Gero or writing that up! So you think the lines being replaced are what’s filling up the buffer?
@blurfl windows 10 Surface pro. I was not aware of the development version. I am using the portable version.
MakerCam has a way of creating arcs that require precision beyond what is available with the floating point software we use. The ‘Oops’ messages come when the firmware finds one of those, and substitutes a short straight line instead of the curve. It would be useful to be able to see the ‘buffer overflow’ message happen, to figure out which buffer is affected. GC should write the lines into the log on receipt, so a slow response from writing to disk could back up.
@ScrumdyBum, do you have the log.txt file from the run with the buffer problem? Is there something in that log that mentions ‘buffer’? By the way, are the lakes part of the TVA Reservoir system? Fond memories of boating there as a boy…
I ran the file with FW/GC 1.14 in FAKE_SERVER today.
I noticed a ‘One Machine Position Report Command Misread’ that does not show up in the log.txt, so I logged the terminal on a second run. I have 5 ‘Machine Position Report Command Misread’ logged during the total cut. How is that possible in fake-server and why does it not make it into the log.txt?
Another curiosity is that one line is not rendered in GC (was the same in 1.13)
The missing line does look OK in the g-code in bCNC.
And one more error:
The file reaches 100% completed before the cut is finished. On the last 2 moves, the buttons go into pause mode, exactly when 100% switches to 0%. The sled continues cut to the end of the g-code.
If a click the resume button, GC will just start the file from beginning.
This was also in 1.13
The ‘resume’ button is white in my screenshot, as I’m missing 1 image in my colour theme.
Edit: Thank you @ScrumdyBum for this file, as it is a great stress test for the software and seems to reveal some hidden flaws.
Edit2: This error does not make it into the log.txt nor in the terminal log
Wow, great troubleshooting! I really need to take the time to setup a test environment.
@Gero, I’ve noticed this kind of ‘unrendered’ line in some of the other complex curve files we’ve troubleshot. I think I remember the Maslow logo file had some gaps in the rendering too.
I think it is related to the floating-point math issues that cause the firmware to go cutting randomly. The gaps that GC shows aren’t the same gcode segments that cause the firmware problems, though, and in GC they just don’t draw the problem segment on the screen. I imagine that the floating point implementation in python is enough different from the Arduino that there might be different results from the trig. calculations for the complex curves.