I am attempting to cut the tree (pic attached). I am experiencing 2 different issues. 1. Oops! This gcode line has caused a calculation error, it will be replaced by: G1…” This error appears many times, but the cut appears to keep going as expected. Then, later in the cut the router (all movement) just stops - no errors, everything just stops. I used the “goto” command to skip a couple of lines of g-code ahead, it makes a short cut and freezes again. I have attached a few photos and the g-code file that I am running. Any help or suggestions are greatly appreciated!
The short take - some small arcs caused math problems and have been cut as straight lines. (I’ll bet they’re so small you can’t find them ) These lines are safe to ignore.
The long-winded take - These lines ‘Oops…’ indicate that the firmware has run into a conflict between its internal floating point precision and the values presented in the gcode file for a very small arc. To overcome the conflict, it cuts a straight line in place of the arc. Newer versions of the firmware have changed the message text to something less informal.
I think i opined in some long forgotten thread that GC’s Preflight Checklist could be considerably more comprehensive. It’d be great to identify these conditions well ahead of running them live…
As for solutions to remove this condition, the place to start is in CAD. Not sure of your particular CAD program, but most advanced apps can output their G-Code with different degrees of precision, and aliasing of these type of curves. It can become a balancing act/art at a certain point because many many short lines (the aliased arc) aren’t ideal either, and result in more lengthy g-code than needed.
It’s large and small arcs in this case. In your CAD program you might have the option to set the tolerance level higher. It is often set far to small for what the Maslow can achieve. An arc with radius of 53918.1397 inch would hardly be seen as a curve, so might be a straight line instead. So the design/drawing side is the first place to avoid creating this large arcs.
In theory the program should not stop because of the amount of errors caused by large and small arcs, however we had a similar case with a user reporting a “Buffer Overflow”. Trying to replicate that failed, so there was no clue on where to look. There might still be a bug in the software. I’m currently running this file in simulation mode to see if perhaps with this wonderful tree, we get some more clues on what is happening.
Unfortunately, the arcs that cause trouble to the firmware calculate correctly in the python math library - and there are arcs that python bumps it’s nose on that calculate correctly in the firmware.
The reason for the router to stop might be apparent in the log file, or from studying the .nc file. The arc error message should not cause the stop. Do we know what line number where it stopped?
If the ‘Home’ position was moved from 0,0 - as is commonly done to move the cut to a different place on the sheet, the coordinates get translated by GC as it reads the file. The screen shot doesn’t quite include the line number that would be on the same line as the Z: position. It looks like a zero, though.
PartKam does appear to be generating “interesting” code. I am surprised to see something written in Flash (ActionScript) for this purpose.
[this is not meant in any way as a criticism of the original poster. PartKam has some very intriguing features, especially its nesting capability. But, flash was removed from firefox and chrome in 2015 due to security issues. I think it still runs in IE and Edge, though].
I see line 30992:
T0 M6
This calls for a tools change (T0) and prompts the user: "Tool Change: Please insert tool ", pausing until the yellow ‘Pause’ button is clicked. I think it should also change the image in the pause button to show that it is waiting for a click, but haven’t verified this.
Ir originally stopped at line 3236. You are correct, the run seemed to continue even with the errors apparently caused from the arcs. I am not sure what caused it to freeze here. I used the “goto” command and skipped to 3268. It then froze at 3276, i jumped to 3308 and then it froze at 3316. Pausing and resuming did not help either. thanks for your thoughts and ideas!!
It is not safe to use a goto to skip into the middle of a block. It might have unpredictable results. The starting
point of a g-code path is not explicitly known. It should be the end point of the last successful command.
In your case it should have been somewhere between the points in 3234 (10.262, 12.8566) and that of 3236 (10.3053, 12.8491), Resuming in 3268, the machine is told to go to (10.2169, 12.8668) using an arc with a particular center. This might not even be possible, since the point might not be on the arc at all.
All coordinates are before adjustment due to Home position.
thanks, no experience. no real time, either. But, I can read like mad.
It is no particular surprise that python and AVR code give different results. I am pretty sure that AVR is using a 32 bit float, and almost all pythons use a 64 bit float.
I hope to be able to help some in the future, but, right now real life is biting pretty hard.
A good approach is to start from the previous z-axis change - this is why there are buttons for that… . I usually ‘goto’ the questioned line number then use the <Z button to back up.
Is there any way to correct the issue or is the rule, No Small Arcs?.
the problem isn’t small arcs, it’s shallow arcs (things with a very large
radius, I believe right now it’s >1000 inches).
The problem is the limits of floating point math, they only allow so many
significant digits, and when you exceed that, bad things happen.
These arcs are so shallow that unless you are cutting the arc across the full 8’
width of the machine, they will appear to be straight lines anyway, so Ground
Control is replacing the arc with a stright line and telling you about it, just
in case it actually does matter in your case.
Why does the router stop moving, what can be alter in ground control to
ensure that the router does not stop due to many error conditions with Arcs?
that’s a completely separate problem that needs to be tracked down. It’s
possible that it doesn’t think that it’s stopped moving, but that you have told
it to make a ton of tiny moves, and it’s grinding through doing them. Or it
could be that there is some error happening. does anything show up in the log
file when this happens?
) These lines are safe to ignore.
. I usually ‘goto’ the questioned line number then use the <Z button to back up.