Buffer Overflow

Software Ground Control
1

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?

1 Like
2

If you upload the .nc I could take a look. We had a few reasons for buffer overflow in the past.

2 Likes
3

Lake border - Copy.nc (499.8 KB)

1 Like
4

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.

3 Likes
5

Any documentation on what you are doing? I would like to learn how to troubleshoot issues such as these.

1 Like
6

Tools I use:

  1. Visual check on the g-code with a text editor.
    A short reference how to read x/y/z moves and measurements is is here.
  2. Visual check in GC. (latest release FW uploaded to the mega and latest GC).
  3. Visual check and test run in CAMotics.
  4. Visual check in bCNC.
    {Side note} This has a cool g-code editor that you can use to optimise the non-cut travel by moving each cut as a block around with up/down arrow clicks.
  5. I have a spare mega, that’s plugged it in to my home office computer, without a motor shield or anything. I change the latest firmware by editing one line in the config.h inside the arduino IDE before uploading.
    Removing 2 // and a space enables you to run GC for testing g-code without moving parts :slight_smile: .
    Notice that the arduino IDE will save the change without asking! Doing this in a productive environment could give you 0 response from the machine.
    fake_servo
    fake_servo958×606 106 KB

    You now have a MaslowCNC simulator that you can check virtual runs.
2 Likes
7

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.

  1. approach for me would be to check the ‘tolerance setting’ in the software you use and increase them.
  2. Try the truncate in Maslow settings set to 3 after digit, this comes at own risk.
2 Likes
8

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’…

1 Like
9

A

grep -r “Oops” log.txt | wc -l

counts 2121 ->Oops,<- in my log.txt file after running the code.

10

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.

11

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…

2 Likes
12

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)

image
image.png1410×900 113 KB

The missing line does look OK in the g-code in bCNC.
image
image.png1150×900 192 KB

1 Like
13

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.

image
image.png1411×900 138 KB

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

2 Likes
14

Wow, great troubleshooting! I really need to take the time to setup a test environment.

1 Like
15

@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.

3 Likes