Gcode error33

[vMeph]

im using fusion 360 and in some g codes i get error33 i was looking into file i see similar codes and some dont make errors this is one of the error code detect in UGS platform, the machine stops then i got to hit to continue G3X271.4427Y20.7057J0.0373

[vMeph]

@swarfer i didnt have a chance yet to do something on machine but later on the weekend i will test the post processor. apart from it i was wondering why fusion 360 post turns spindle on first , then does the rapid move to initial position, first XY, then Z wouldnt be more safe using Z first then XY then spindle on folowing by a dwell? what if you forget to raise Z up? then will scratch material or eaven brake tools, go against clamps etc...

dont know if it makes any sense what im saying, just fells like the order they did doesnt sound like to be to safe no idea..

[chamnit]

@swarfer : The curious thing is that the G18 and G19 arcs worked fine if I replaced the custom xaCoord arc variables with the plain xCoord variables. I did not have to specify the G18 and G19 to be ignored. Changing the number of digits didn't effect and break the exported gcode program.

The post file does some other operations to the default Coord variables. I agree that there is likely a bug with the G18 and G19 arcs. But I suspect there is something with the custom arc Coord variable that isn't being handled correctly. Either internally or in the post script. Not sure which.

[swarfer]

HI guys Yes Sonny, using more digits for arcs is a mistake in this post because the preceding move to the start of the arc is using fewer digits, thus there is a precision mismatch due to roundoff. that is why I have now set the arc and regular formats to have the same number of digits (both 4: 5 rather than 3 : 4 works for me).

But even with that I was still seeing errors unless I restricted arcs to G17 because Fusion was generating a tiny little arc at the bottom of some of the plunge moves.

I will delve into it some more, but I do need feedback from users who have had problems, I am relatively new to Fusion and so have only 1 'real project' file so far, which has not yet made it to 'run on real machine' status (radiused sanding blocks for guitar repair for my son :-).

Of course, setting minimumCircularRadius = spatial(0.01, MM); to 0.5mm is still an option (-:

@vMeph : high speed spindles can take time to come up to speed and I think that it why they turn it on first. The stock post assumes you have G28 set according to the standards, with Z0 at the top of Z travel. It will move there before any other moves IIRC (unless you turn the G28 off). But that use of G28 confuses many hobby users who reset GRBL at the stock 0,0,0 point, and that is why Strooom wrote a whole new post for GRBL which avoids G28 but does use G53 for an initial Z move, so resetting at stock origin is still a bad idea.

I need to look at the details of doing user options for some of this stuff, maybe that G53 move could be optionally replaced with a relative Z positive move to the retract height for those users who still don't want to use MCS and G54 properly.

[chamnit]

@swarfer : We established the bad arcs generated were much greater than any precision error. So I don't agree with your hypothesis of two different precision values causing the problem. I think I remember testing it with the same precision and your post still generated errors.

Also, your theory also doesn't explain why the default Grbl.cps on Fusion360's website works fine. It worked with a default value precision the same as your post or keeping it unchanged. It also worked fine with the default minimum chord or radius values at 0.01mm. No reason to have to increase it to 0.5mm.