arc leadins throw grbl error:33

[bLouChip]

Hello all. new user. I like SC, gave some considerable study and testing before purchasing. However I've run into a problem, need some advice please.
Using SC for plasma process only, importing svg drawings. my CNC is Mill Right brand, running grbl 1.1i on atmega2560 arduino.
I modified the SC post pp "GRBL plasma.scpost" to include the torch holder floating carriage for probe touchoffs before each cut; I have attached my modified scpost here. I've not modified OnArc(), mostly contained mods to OnPenDown() and a few OnInit(), OnFinish() tweeks and global vars.

Problem: arc leadins are throwing the grbl runtime error:33, Invalid_Target. I've tried 5, 6, and 7mm arc leadins, all fail; have not tried other lengths. The SC stock install of "GRBL plasma.scpost" fails the same. I also have Ramp style leadins, have not tried no ramp style. I'm running in metric and outputting "0.000" decimal format, but "0.0000" fails also. Here's what's odd, I have a desktop arduino uno running grbl 1.1h, and it runs the gcode fine.

SC is working fine in other leadin styles and lengths. Its just arc leadins giving me grief.
I actually bought SC in part for use of arc leadins; ugh. Tangent leadins are sufficing for now, but would like to get this fixed. The calcs I've done on the arc leadin gcode seems to be within tolerance of the grbl spec, but close. I've attached my xls for those calcs also. I've tried some things already to offer more rounding forgiveness such as grbl $12=0.010 (no help), SC miniarcs=10.0 (ugly, not a solution).

Has anyone seen this type of behavior already ? or does anyone have suggestions ?

thanks,
Lou

[bLouChip]

I have a "fix" to this problem.
thru trial and error, I noticed the 1st leadin arc began to run fine in grbl after I re-zeroed the Y WCS coord. That was odd, and it just so happened it was on an integer (as in nnn.000mm) machine coord. So I zeroed X on an integer machine coord, that caused 1st leadin arc to fail again. So knowing I was on to something, I began setting WCS XY zero using G10 P0 L2 X-nnn.001 Y-nnn.001 and so forth, then running the gcode job, and low and behold nnn.004 (in mm) for both axes had both leadin arc coords running fine.
the actual WCS (54) zero coords machine offsets that worked fine on both leadin arcs were: g10 p0 L2 x-645.004 y-422.004
This is fraught with uncertainty and somewhat strange. I'll continue some research.

net: no issue with SC gcode gen for leadin arcs. As the updated xls shows (org post), the calculated radii for both sets of leadins is spot on, to 0.0000mm precision. I should have posted the gcode as well yesterday, so I'm posting here.

The issue/error33 in this case appears to be a quirk of grbl 1.1i.

[Les Newell]

GRBL does seem to have some strange arc issues. One option is to break arcs into short line segments. To do this, edit the post and replace your function OnArc() with this version:

Code: Select all

function OnArc()
   post.ArcAsMoves(0.1)
end

[bLouChip]

Les,
ArcAsMoves() did it! Thanks much. I was looking at that this morn. Here's what I came up with, preserving some feedrate code before and after the arc moves. Or was that necessary to preserve given the ModalNumber() posting of feedrate ?
Switching the job gen to ArcAsMoves is much better than fooling around with WCS zero using G10 P0 L2... through trial and error.
I prefer the shorter code gen of using actual arc gcode, thus as you see I made triggering ArcAsMoves a user defined var I can set if this problem comes up again.

Code: Select all

function OnArc()
   if oldFeed ~= feedRate then
      oldFeed = feedRate
      post.ModalNumber ("F", feedRate * scale, "0.0###")
      post.Eol()
   end
   
   if (var.LdcArcAsMoves ~= nil and var.LdcArcAsMoves > 0) then
      post.ArcAsMoves(var.LdcArcAsMoves)
   else
      if(arcAngle <0) then
         post.Text ("G3")
      else
         post.Text ("G2")
      end
      post.NonModalNumber ("X", endX * scale, format)
      post.NonModalNumber ("Y", endY * scale, format)
      post.ModalNumber ("Z", endZ * scale, format)
      post.Text ("I")
      post.Number ((arcCentreX - currentX) * scale, format)
      post.Text ("J")
      post.Number ((arcCentreY - currentY) * scale, format)
   end
   
   post.ModalNumber ("F", feedRate * scale, "0.0###")
   post.Eol()
end

[Les Newell]

You don't need this code:

Code: Select all

   if oldFeed ~= feedRate then
      oldFeed = feedRate

ModalNumber does that for you.

[bLouChip]

I now have a fix for this problem that allows for the use of G2/G3 without error33 random failures.
This applies to CNC plasma process.
I discovered that G38.2 probe stmts have a side effect of grbl reading the control point probe position in that the precision of all axes is lost to no better than the precision of a single axis Step. MillRight MegaV XY steppers are config'd at 57.288steps/mm or 0.0175mm/step, thus up to 0.009mm on average has been lost by reading the probe coordinates (grbl position state) which are in full step increments, thus evenly divisible by mm/step. Not good to loose precision. Exact to 3 decimal precision is good in general, but it is necessary to avoid grbl error33 when the next XY motion stmt after a probe is a G2/G3 XYIJ center arc format stmt.

So the fix involves simply reposting the gcode G0 X(currentX) Y(currentY) Z(pierceHeight) when moving the torch to pierce height after a torch touch off probe prior to each plasma cut.

My .scpost file is attached for reference and sharing.

also, more background about the whole ordeal is provided here: https://millrightcnc.proboards.com/post/25905/thread

[Les Newell]

Nice bit of detective work! Thanks for posting your findings here.

[bLouChip]

Thank you Les. It was fun

I got myself into this ordeal because I love the arc leadin with Z ramp down to cut height.
I have a couple of machine torches, one brand being the Tecmo PTM60. Its nozzle and shield design tends not to repel piercing dross as well as Hypertherm's design. As a result I consistently get dross collecting in the gap between the nozzle tip and the shield on the PTM60. If I dwell (pierce delay) longer to minimize this effect, then I get a larger blow hole on the pierce. So I'd like to try a longer ramp, shallower ramp angle. Is there the pierce ramp angle exposed in a .scpost variable?, I looked but didn't see it. So this would be similar to the ramp angle of a milling operation, so perhaps add the field to the jet operation when selecting Leadin Ramp?

[djreiswig]

I always figured the ramp angle was based on the cut speed and plunge rate. If they're the same then you get 45 degrees. Maybe I'm wrong.

[bLouChip]

I believe the leadin ramp angle is fixed at 45 deg, Les would have to confirm; 45 deg is the case with tangent and perpendicular leadins. I just tested this by setting up the leadins so they ran horizontally on just the X axis, no Y motion. Its easy to see in a tilted graphic window too. But the coordinate motion math proves it too. In my case the diff between the pierce height and cut height is 2.2mm, and that is also the distance traveled along X axis during the plunge. The feedrate is the plunge rate, there can only be one feedrate specified on any motion block and it relates to the speed of the jet along the distance of the ramp rather than to an individual axis in this case.

So thinking out loud just made me realize that I can take advantage now of knowing the angle is fixed at 45 deg, and the feedrate is along a distance that I can calculate: 1.41 x (pierceH - cutH) so 1.41 x 2.2 = 3.1mm ramp distance. @750mm/m = 12.5mm/sec plunge rate, 3.1/12.5 = 0.25sec time to plunge to cut height. Now I can factor that time (0.25s) into my pierce time, having a starting point as to how much to shorten my pierce delay time until I get the pierce result and quality I want. This may not solve my dross blowback issue with the PTM60, but it will be helpful when cutting open shape kerfs in artsy/crafty projects where I try to hide the pierce holes by minimizing their size relative to the kerf width.

So I believe I'd still like to try to fiddle with the ramp angle, if possible, in the case of trying to minimizing dross blowback into what is an inferior torch compared to an HT45, the latter having no issue at all with deflecting blowback dross using the same or similar pierce and cut parameters as to the PTM60.

[Les Newell]

Just to confirm, it is fixed at 45 degrees.