grbl Error 33

[bLouChip]

re. grbl Error 33 on the MegaV, as many know it can be intermittent. For about the past year I have been using SheetCAM to gen the toolpath on plasma and simple 2.5D routing jobs. SC allows you to choose how to gen arcs, it will either use actual arc G2/G3 segments or will gen arc chords (hundreds of small straight line segments) to approximate the arc shape. The benefit of G2/G3 segments are that the gcode line count is much much smaller, and can translate into smoother XYZ motion depending on other settings. Other toolpath generators did not give the option to use G2/G3 segments, or at least it wasn't obvious. 

Intermittently, even with the same gcode file using G2/G3 stmts, MegaV stock grbl will throw an Error33, which is supposed to mean that the coordinate math in the G2/G3 stmt has 2 calculated points that don't fall on the circle path from the current position. I've check the gcode coordinates and ran the math several times and its always right on, out to 4 decimals in mm. So why would this happen AND why would the same gcode file sometimes work and sometimes Error33, even on different circles/arcs in the file ? 

I stumbled onto a possible answer recently when a file had worked, then grbl threw Error33 after I had changed my WCS 000 point. So I could fiddle with my WCS zero by just 0.001mm increments and get it to work and fail repeatably and predictably. So that made me wonder if the rather course grained steps/mm (57.288) of the MegaV XY axes could be the root cause ? It seems like 200 steps/mm, like the Z axis, is the more usual expectation in grbl. It turns out this reasoning is likely the cause for the errors. I modified the Error33 validation test in grbl this morning, expanding the limit tests by 4x, and have been running many arcs and circles error free for the past several hours ! So perhaps this is a fix for the MegaV. I'll report back if this fix withstands further testing. 

There is more info on the mathematical validation checks here: linuxcnc.org/docs/html/gcode/g-code.html#gcode:g2-g3

[bLouChip]

Here's an update on the error33 mystery in the cases I have...

After much testing, grbl behavior discoveries, and reviewing grbl source code, it turns out a grbl fix is not necessary; rather one can use an arc stmt in Radius Arcs Format (G2 XnYnRn) rather than Center Arcs Format (G2 XnYnInJn) to avoid error33 in the scenario I'm using. See the link in the OP for details on these gcode stmts. 

I discovered in the grbl code that Radius Arcs Format is not subject to the same error33 validation, I suspect because the arc radius is given in the statement, it doesn't need to be checked, and there is no second radius to compare it to.

As eluded to in the OP, the Center Arcs Format fails consistently with the exact same gcode when run from the exact same WCS 000 machine position, exact to 0.001mms. The MegaV XY steppers configured (necessarily) with 57.288 steps/mm absolutely set up this error33 problem, but I discovered it also takes a grbl probe stmt preceding an arc Center Arcs Format stmt in order to trigger the error33. A grbl probe stmt such as G38.3 Z-15 F50, when tripping the probe circuit (switch), will cause a read of all axes positions and update the current machine position registers. That's fine, but it has a side effect of also clearing any fractional steps grbl had been keeping track of in a separate internal register. A fractional step is a distance value less than a full step; in the MegaV case of XY axes, a full step (one pulse to the motor) is 0.0175mm linear travel. grbl keeps track of these fractional steps and when a full step is accumulated it pulses the motor one time. So depending on the amount of factional steps that were lost during the probe event, it can easily be enough to fail an error33 condition of delta radii being > 0.005mm and delta radii > 0.1% of 1 radius. You won't see this scenario throwing error33 in machines configured with 200 steps/mm XY, because the test value of 0.005mm is the exact mm/step of that configuration, so it's less likely to have odd fractional steps to accumulate and thus get lost on probe events.

This scenario of probing before a leadin arc is prevalent in CNC plasma process, every plasma cut has 2 probe cycles (just like a homing cycle). The torch has to find the top of the cutting surface every time due to heat and uneven water pan bed, the torch cutting height is 1.5mm off the surface.

So all this research has lead me to realize I can avoid the error33 tests all together buy using Radius Arcs Format on the G2/G3 stmts. I changed my SheetCAM post processor to generate arc stmts as Radius Arc Format, life is good 🙂

I'm happy to share any of the fix or alternate fix if folks need it.

The down side to this course grained stepper configuration in this use case of plasma cutting is that I potentially loose 0.009mm (on average) of X and Y accuracy on every cut, thus in 100 pierces in one job I could be off by an accumulated 1mm. A small price to pay for a very powerful drive train though, no worries.

[bLouChip]

Well as usual, I've gone nearly full circle on this issue   There's more...

So when I decided to tackle this error33 I thought it was broader than a plasma process issue, but no, the cases I had consistently seen when trying to use G2/G3 arcs for the past year seem now to be strictly confined to plasma process.  The few milling process error33s I've seen, including leading up to this past weekend when I dove in on this issue, were caused unknowingly at the time by gcode generated with only 2 decimal digit (0.01mm) precision. That's a known cause of error33, the fix is to use 3 decimal digits.  So that was a 1/2 day warmup to realize that mistake.

So now I'm locked in on plasma gcode cases only, fine. I'm using G2/G3 Center Arc Format, that's what SheetCAM post processors used as default. After verifying various arc coordinate math that was generated it always passed the radii validation tests as good data for an arc or circle. So I got onto the course grained stepper theory as the cause, fiddled with the grbl validation tests to relax the tolerances, and boom it worked as a solution consistently. But I still couldn't explain, using the original grbl tolerances, why just as many arcs threw error33 as those that didn't; and it tedious to weed out the failing arcs from the gcode file because I had to comment them out in order to move to the next arc in runtime. And if WCS000 changed mistakenly, start the process all over again.  Ugh. I could have left it alone, I had a fix, but I had to know why.

So after identifying 4 or 5 arcs that threw error33, and seeing no clear pattern of failure in the data, I began to eliminate gcode stmts leading up to the error33 arcs. G38.2 and G38.3 probe stmts began to emerge as suspects; but so did arc stmts that only used all 3 axes XYZ.  I could generate a plasma leadin that did not ramp down Z in a XYZ motion off the pierce height, and rather move Z only from pierce to cut height, then begin the arc leadin, and all of those arcs worked fine, AND they had preceding probe stmts.  But, I could also eliminate the probe stmts and use XYZ arc motion from pierce to cut height and all of those arcs worked fine !   What gives ?

So not seeing a common thread between these 2 stmts, I focused on just the probe stmts and discovered the side effect of grbl loosing the fractional steps of the XY axes (Z also presumably) while reading the probe switch closed position/coordinates. That was key, that answered WHY with regard to the probe stmts; AND that lead me to the second fix, mutually exclusive to the first fix, that I could use G2/G3 Radius Arc Format stmts and there is no error33, its not even tested in grbl because it's not necessary to test, the radius is known good from the CAM generator.  In the other arc format, Center Arc, the 2 radii are calculated in grbl, one from arc start to center, and one from arc end to center, and then those radii are compared with the predetermined tolerance and error33 if out of tolerance. The down side of using Radius Arc Format is risk of loosing precision, significantly, on larger arcs and circles. Well, now knowing my CNC plasma job was already loosing precision on XY as the result of every Z probe cycle, I didn't like that accumulation of motion precision loss coupled with Radius Arc Format precision issues inherent in large arcs. Didn't sleep well the more I thought about it, AND, WHY DO ONLY XYZ Center Arc Format arcs fail after a probe cycle? 

So here's the answer...  when I would not use the SheetCAM option to ramp Z in arc leadins, SheetCAM would move Z from pierce to cut height first, before the first arc stmt, and in doing so the stmt generated would also include the current position of XY, so it was a G1 XYZ stmt where only Z would have motion because XY had arrived at the pierce coordinate before the torch probing began, many gcode stmts prior.  So guess what, that G1 XYZ stmt reloaded the "grbl fractional step registers" for XY, as I referred to it in the earlier post. In reality, I doubt there is a "fractional step register" for each axis, rather grbl keeps track of an axis position with a floating point variable but rounds it to 3 decimal precision mm (4 decimal in inch mode) when reporting the value in console messages, which is how UGS gets the axis positions that we see in the DRO display/window. The seemingly fractional step theory has to do with MegaV only being able to move XY at increments of 0.018mm (0.0175 rounded).

So it occurred to me, why not use the same "side effect" XY non-motion prior to the first XYZ arc motion after a probe cycle in order to avoid risk of error33 ?  and boom, it works !

So at the end of my torch probe cycles, again necessary to find the top of the material prior to each plasma cut, the torch has always been moved from Z0 to pierce height, and in that former G0 Znn only stmt I've now updated my SheetCAM post processor to add the current XY coordinate, so it becomes a G0 XYZ stmt.  This is now the 3rd fix, again mutually exclusive to the others, to this drawn out episode of fixing grbl error33s !

This 3rd fix is the one I'm going with, since in addition to solving the mystery of error33s, it seems to also solve all the loss of precision issues that came with the other two fixes.

Here's an example of my torch touchoff (probe cycles) with an arc leadin with Z ramp from pierce height to cut height, and it works first time every time so far, from any WCS000 so far. Fingers crossed

The SheetCAM post processor code is posted in the google share folder photo gallery if anyone needs it.

========================

; Post: GRBL plasma LDC v24-11.scpost V11
; File gen date: 8/8/2023, time: 2:49:05 PM
G00 G17 G40 G54 G90 M5 F0
G21
; Zero Z at top of material
; Torch Probe Travel = 8.2
; LDC Small Shape Size in mm = 75.0
; THC effective On/Off status = 1
; Arcs As Moves = 0.0
G0 Z20.000 (retract Z for start of job)
;********** Op name: Inside Offset, small, T41: P-HT45AS-16gaHR
;========== Op index: 0, Shape number: 1, Kerf width mm: 1.0
G0X35.765Y49.671
G0Z3.700
; LDC begin per-cut torch touchoff to set Z0
G91 (relative mode)
G38.3 Z-16.900 F1000 (probe fast to find sw)
G0 Z5.000 (retract off probe switch)
G04 P0.400 (wait for sw debounce)
G38.3 Z-5.000 F50 (probe slow)
G0 Z8.200 (fast retract to top of material)
G92 Z0 (set temp Z0)
G90 (return to absolute mode)
; end torch touchoff

;move Z to pierce height, XY non-motion to restore grbl position precision lost during probe

G0 X35.765 Y49.671 Z3.700 
M4 S1000 (THC effective On condition) (fire the torch...)
G04 P0.8
F500.0
G2X33.652Y50.197Z1.500I0.000J4.513
F2000.0
M7 (enable Z THC anti-dive circuit when SPWM < 86%)
; LDC Small Shape, disable THC on this shape, and do so with continuous motion
S200 G2X35.765Y58.696I2.114J3.987
G2X44.790Y49.671I0.000J-9.025
G2X35.765Y40.646I-9.025J0.000
G2X26.740Y49.671I0.000J9.025
G2X35.066Y58.669I9.025J0.000
G2X36.441Y57.492I0.099J-1.276
;========== Op index: 0, Shape number: 2
M5 (torch off)
G04 P0.8 (allow THC to give Z control back to grbl)
M9 (disable Z anti-dive circuit)
G0Z20.000
G0X76.405Y49.671  (move to next cut, pierce coordinate)
G0Z3.700
; LDC begin per-cut torch touchoff to set Z0

========================...