I am making a sign with my logo. I created it using CamBam which I find to be very intuitive. Some of the letters have a glitch when I run the gcode through Ground Control and my maslow. When pocketing out the letter the router jumps out of the lines of the letter and leaves a little bite. I will try to send a picture of the glitch because I know this isn’t very descriptive. I have narrowed down the exact line in the GCode that causes this by running it through ncviewer and if I remove the line the glitch disappears. I have the code for the letter M that this happens to and will upload it as well. The gcode line (181) is this: G3 X-4.6291 I0.0049 J0.0623.
It would have been nice to have the .nc uploaded as a file and not let me scroll for ages 
The file does not look right in camotics.
1 Like
The glitch occurs on line 181 which is commented out in the file.
MbWLogoRounded.Part1 [Pocket M].nc (7.7 KB)
The GCode is just the pocket. The picture also includes an engrave step that is not in the Gcode.
1 Like
The line causing the bump is a tiny move (0.003 on X) and has no Y value.
Seems GC overshoots in the attempt to move that small.
Line 140 has no X value. I think there has been an issue in the past that this “irritated” GC but I thought this was fixed. If you want to narrow it down you could try and add the ‘missing’ values (copied from the line above) in a text editor and report back if that changes something.
What was the post processor used in CamBam?
1 Like
I am using CamBam 0.98 but I have tried the 0.97 processor and the new 1.0 with the same results.
I will try your fix to see the results but I would prefer not to have to modify the code for each change. The total project is over 5000 lines.
1 Like
Any possibility this is due to the sled jumping as some part of it catches on the edge of the pocket? It sounds like you have already narrowed in on a source, but it that proves to be a false lead, this is what I would look for next.
2 Likes
@gero I tested it with the Y value added and it still made the bump. It looks to me like it is carving the wrong arc of the circle. Line 140 is a simple move (G1) but 181 is an arc (G3). I can look at the other places in the code where there are bumps and see if it is the same command with a small move.
@jwolter No, I have run this many times on clean boards and in different locations and it isn’t catching and If I remove that line of code it doesn’t make the bump.
I would appreciate if someone would run the code in CG and verify that it isn’t just me. It won’t use a very big spot on a test sheet.
Thanks
1 Like
If this is a bug in GC we need to replicate and narrow it down to the reason it’s happening. Earliest I can run the cut is Tuesday. Thanks for trying the edit @MbW.
Here is the result of the Edited file. You can clearly see the “Bump” is a full circle.
So this is the uploaded .nc plus editing? Anyhow it did the same without the edit, right?
1 Like
Correct, You just need to uncomment the offending line. (181)
BTW, I am running GC and Firmware 1.18 on Windows 10.
1 Like
Although the Bahrain division of Masow .nc forensics is highly intoxicated it was able to get some evidence on the MO. Fake server mode shows a jump that needs to be explained by the programmers
Edit: The simulation recorded https://youtu.be/WNQ34cw7KtQ bug at 4:01
2 Likes
I don’t know if I am smart enough to comprehend it if you told me but I am very interested in how you run that simulation.
I have a spare arduino mega in the home office for this task. You don’t need a motor shield or anything else attached to it. A small edit in the firmware before you upload it to the mega and you can run GC. Be aware that the Arduino IDE stores that change without asking, so I don’t do this in the workshop. Just to make sure that I’m not wondering for hours why the Maslow is not working 
The top terminal is the command window GC is started from. The second is a ‘tail’ on the log file (Linux). I use vlc to record my desctop 12f/sec.
1 Like
Thanks for that, by a strange sequence of events I have an extra shield but not an extra arduino.
1 Like
From my uneducated guess this glitch can be avoided from the CAD/CAM side.
What was the post processor used in CamBam?
Have you tried EMC2 (should be called LinuxCNC by now) or can you find a grbl post processor in cambam?
Was this gcode created from a .dxf file? If so I would look for unclosed polylines in the the CAD used before cambam. Generally I would set the Tools → Options → GeneralTolerance to 0.001 (default is 0.00001 
.
Source of my guess: CamBam - Tutorial : Pocketing
(might be outdated, no date visible)
Having that said, it’s ‘strange’ gcode like this that has pointed us to glitches in the past, showing the room for improvement. We still face the fact that FW/GC 1.18 has an issue with this arc:
G3 X-4.6291 Y4.1732 I0.0049 J0.0623
Are we limited by the processing power of the arduino to catch and solve this ‘on the fly’ during a cut?
An interesting find that I can’t interpret: Turning truncation on and truncating to 3 digits shows 4 full circles in GC that the sled will follow.
1 Like
I tried the LinuxCNC post processor with the same results. I can’t seem to find a grbl one.
The letter was created in CamBam itself so there shouldn’t be any open polylines.
This tread seems to have died but I still have the problem. It appears to be connected to the function that changes arcs with large diameters to lines. Is it possible to have a switch to turn this on and off at least for troubleshooting?
It is a glitch in the GC software that shows with this tiny move and the arc.
On one side it’s easy to say “use an other program for the gcode” on the other side the programmers could be challenged by the question why a simulator like camotics can deal with it and GC can’t.
Although it seems like an error that is brought down to the gcode made with cambab, I think it should be worked on, as it can have effects on gcode from other programs as well.
As a quickfix you found that removing that line solves the problem. Next I would do is investigate on cambam to get rid of this tiny moves. Did to try increasing the general tolerance?
For GC you can open an issue on github (or should that be in FW?).
1 Like
If the arc is too small, the system can get confused and think that instead of
making a tiny movement, you want a full circle.
When this happens, the start and end point of the arc are the same (and with the
limits of single precision math in the arduino, this happens once in a while
even when the g-code has different positions)
David Lang
1 Like