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

[109JB]

error 33 indicates that the target position is not correct, but we cannot tell from that single line of code. In order to calculate we need the start position of the arc which will be the previously commanded X, Y position.

[chamnit]

@vMeph : Please provide the g-code prior to this error. I'd like to start gathering up all of these Fusion 360 problems to see if there is some commonality.

[vMeph]

@chamnit @109JB im not sure exactly where is that problem is located cause i had to skip and ignore so many lines. the problem appear on this design was used a 3D parallel operation

this is the file in the section where the problems would appear fileW33.txt

[neilferreri]

@vMeph Have you tried something other than UGS to send the code?

[vMeph]

@neilferreri no i didnt try with other i always have used UGS platform

[gerritv]

im not sure exactly where is that problem is located cause i had to skip and ignore so many lines.

If you get errors there is no point in continuing, you need to solve the cause.

Running your file with GrblPanel I get the Error 33 at line 141.

[usbcnc]

It happens in this line if (delta_r > (0.001f*gc_block.values.r)) { FAIL(STATUS_GCODE_INVALID_TARGET); } / When delta_r = 0.0107002258 r = 0.0372999981 gc_block.values = {f=100.000000 ijk=0x00a39950 {0.000000000, 0.0372999981, 0.000000000} l=0 '\0' ...}

[usbcnc]

The GCODE lines around the error lines are. G2 Y30.2403 Z-4 J-0.0699 K0.1426 G1 Y21.546 Z-4 G0 Z5 X271.443 Y20.695 Z2 G1 Z-3.974 F100 G3 X271.4427 Y20.7057 J0.0373

[usbcnc]

Modify line 142 from G3 X271.4427 Y20.7057 J0.0373 to G3 X271.443 Y20.695 J0.0373 Solved the issue. Please look at line 139 X271.443 Y20.695 Is is where X and Y is. The circle is trying go to X271.4427 Y20.7057 which with J0.0373 and this will not be a circle based on the calculation. The detection is not in UGS but in GRBL firmware.

[chamnit]

I suppose I should ask: Why is Fusion360 generating arcs with a 37 micron radius and an arc length of 10 microns? Round off becomes a huge problem at that level of precision. Most hobby CNCs can't resolve below 25- 50 microns. It would be better to just program a short line at that point. Is there a way to force Fusion360 to ignore small arcs?

[X3msnake]

It's probably a problem in fusion 360 linking

Try removing Lead in, Lead Out and define linking as Straight Line

2017-07-17 5:04 GMT+01:00 Sonny Jeon notifications@github.com:

I suppose I should ask: Why is Fusion360 generating arcs with a 37 micron radius and an arc length of 10 microns? Round off becomes a huge problem at that level of precision. Most hobby CNCs can't resolve below 25- 50 microns. It would be better to just program a short line at that point. Is there a way to force Fusion360 to ignore small arcs?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/230#issuecomment-315664627, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-libUUj3emi2aLQ9HxAhhf3orciGks5sOt1qgaJpZM4OZKru .

-- Com os melhores cumprimentos, Vinicius Silva

[swarfer]

I suppose I should ask: Why is Fusion360 generating arcs with a 37 micron radius and an arc length of 10 microns?

Because the post is allowing it (-:
There is an option to turn off arcs entirely, but there is also a setting in the post that sets the minimum, radius. Segments below that radius will be converted to one or more line segments. details here... https://forums.autodesk.com/t5/fusion-360-computer-aided/arc-radius-too-small/td-p/5551526

[vMeph]

@swarfer Im not home at moment but i think there is a setting in fusion to specify minimum arc tolerance,what would be the best value set?

[chamnit]

@swarfer : The link briefly states you can alter minimum chord length. If that's true, you would need to set that value to something greater than 0.1mm. IMHO, chord length is far more important than radius but both are necessary.

@vMeph : I would probably set it at something like 0.1mm or greater. It could be lower if you have high precision requirements. But like I mentioned above, I think chord length has a stronger influence on the error computation. So try to set that as well.

[vMeph]

@chamnit would be great to have a minimun value set for what GRBL can handle without produce errors for radius and chord lenght

I will look later on what sets fusion have for it

[chamnit]

@vMeph : I've considered it before and I do have it on the development list for the next version when there is flash and extra speed to do so. Floating point math on the 328p is slow and takes up a lot of room. It will still likely fit, but haven't taken the time to flesh out a complete implementation. These Fusion360 issues have not been improving on Autodesks side. So I may have to install something. We shall see.

[vMeph]

@chamnit this is what Fusion 360 have set has default for grbl

[chamnit]

I've been looking into this problem some more, and concluded that it's not Grbl. Fusion360 is generating really horrible arcs. Every error Grbl produces is doing exactly what it should.

For example, line 1776 programs a G2 arc like so: G2 X152.445 Y151.9257 J-0.032 and the start position is X152.445 Y151.935. X doesn't change and the difference between Y is -0.0093mm. It should draw a 180-degree clock-wise arc with a radius 0.00465mm. Instead, Fusion360 says the arc radius is 0.032mm. It's off by nearly an order of magnitude. The other errors I checked showed the same type of problem.

They all also seem to be constrained by the 0.01mm minimum chord length post setting. It's reasonable to conclude that this is not a precision error, but rather a bug in somewhere in Fusion360's toolchain when dealing with the minimum chord length (and possible other scenarios). In addition, I suspect it's somewhere in their post-processing scripts.

If I install a patch to ignore errors with short chord lengths like these, I will just make this Fusion360 bug persist. At best, this is simply a patch. Not a solution. I may install compile-time options to do this, but it will not be enabled by default.

AFAIK, Fusion360 is the one of two CAM programs that constantly throw this invalid arc error. The other I think is called MakerCAM. I just remember that it's open-source, not used by a lot of users or well maintained, and the arc generation tools are likely poorly written. AutoDesk doesn't have being open-source and being under-funded as an excuse.

[vMeph]

@chamnit dont know if this helps out this is the fusion 360 original post processor grbl.txt and this is the @Strooom update post processor OpenbuildsGRBL.txt

i was using Strooom post processor

[matthewSorensen]

When using helical ramping, I've had Fusion360 generate arcs that violently crash machines. I posted the same file to a non-Grbl machine, and it was fine, and disabling G2/G3 when posting to Grbl also solved the issue.

The bug(s?) definitely seem to be in the default Fusion post. Simply disabling small arcs on the Grbl side is not a safe fix, as sometimes it generates large and completely dubious arcs...

Unfortunately, I didn't bother saving the files to reproduce this...

[chamnit]

@vMeph : I looked at the post files. I can't tell what, if anything, the bug is. Most of the function calls inside them are not in these post files. I think the bug(s) are somewhere in these internal Fusion360 post files that handles the minimum arc chords and radii settings. It's hard to tell to by not being a Fusion360 user to see how things change when you alter some of these post settings. You can always try to alter minimum chord length and arc radius and then send it to Grbl in $C check mode to see if it throws any errors. If they do, post them here.

@matthewSorensen : Thanks for the data point. I'm not totally surprised by large arcs also being a problem. Do you recall which post you used on the non-Grbl machine? I"d like to see how the post config is different.

[vMeph]

@chamnit i did afew tests using the file i posted before and this is what i come up with

minimumChordLenght 0.3 minimumCircularLenght 0.3 no error minimumChordLenght 0.3 minimumCircularLenght 0.2 error minimumChordLenght 0.2 minimumCircularLenght 0.3 no error minimumChordLenght 0.1 minimumCircularLenght 0.3 error

anything below this looks like will produce errors all the time other designs that i did i never have found errors no idea why this one will produce errors

[chamnit]

@vMeph : Interesting. It looks like they are both dependent on each other and each cause issues. I'm uncertain if this will solve all future problems, and these results are likely tied to your particular program. Also, 0.3mm chord length and arc radius are pretty large. I wonder if this means Fusion360 produces multiple, small linear fits for arcs smaller than this, or does it produce just a straight line in place of an arc? If it's the first one, then you should be good to go.

For future reference, the Fusion360 forums state that setting allowedCircularPlanes = 0 will disable G2/3 arcs in the generated g-code and just make G1 line approximations for everything. This is pretty much guaranteed to work.

[neilferreri]

@vMeph @matthewSorensen Can you share a Fusion 360 file for which you are having problems? I use Fusion 360 for a lot of my CAD work and most of my CAM, but I haven't noticed these errors. I just ran several F360 generated gCode files and did not see errors. I am sure the tiny arc thing is a bug, but maybe it's for a specific CAM operation / setting. I've never seen anything generated from Fusion that crashes a machine, and @vMeph your file completed, by non-ideally ignoring those tiny arc moves.

[vMeph]

@neilferreri file is on top, the cam operation used was a 3d parallel

[neilferreri]

@vMeph I am referring to the actual .f3d file. I can't recreate the error with any operation on any file.

[vMeph]

@neilferreri file is here .f3d https://1drv.ms/u/s!Ap1NL0mf0Z-1kWIw-5dYxdmgRPeO

[neilferreri]

@vMeph I created gCode with the default grbl post and there were no errors. I'll have more time to look at the exported file later. Try with the defaults.

[chamnit]

@neilferreri : Interesting. There isn't much difference between Stooom's post versus the current Fusion360 default post. His post basically increases the number of digits in arc values to help with numerical roundoff. From what I remember, the only thing of note was the tolerance value was increased from 0.002mm to 0.005mm in Stroom's version.

[chamnit]

@neilferreri : Please post the new gcode file. I would like take a look at it.

[neilferreri]

@chamnit I'll post it as soon as I get back to my computer.

[vMeph]

@neilferreri and @chamnit im also very curious about whats gonna be the results, to know if this is something im doing wrong or what is fusion doing wrong

i original changed the Strooom post process but i tryed also with is original post processor and still have same errors

i changed the post cause i would put my drill bit on top of material and i would mark there my work position and everytime i start the job the spindle would turn on and would move on XY and then raise the Z, i was strugling to why was doing this, it come up that i was never raising Z before ask to do the job, Silly of me lol

this is how post processor of fusion 360 does is order of things

1- start spindle (would scratch material) 2 -move X Y to position (would scratch material) 3 - move Z up 4 - move Z down and start mill

above order dont have logic to me or is just me?

so i changed the code of post processor in this order that sounded more logic to me

1 - move Z up 2 - go to X Y position 3 - turns the spindle On 4- move Z down and start mill

so if i ever forget to move my Z up i got no problems with scratching my material and eaven for safety reasons this sounds to have more logic

[langwadt]

@vMeph I've just installed f360 and generated a simple gcode file with the "Generic Grbl" post and the first move is a G28 Z0 which on a homed machine moves the tool to the highest position

[vMeph]

@langwadt yes but in my case i have disable the G28 cause that will force all files to go home first and if i performe that once dont need to do all the time i put a new file but if you notice it will post then the spindle then XY and then Z so lets say you position your bit on top of material if you forget to put the z up and start the job it will turn spindle on the will move XY to position of material start point and then will move the Z up

[langwadt]

@vMeph you only need to home once after resetting on the machine. after that you just jog/probe the tool to the right position and set/zero the work coordinates

[neilferreri]

@chamnit @vMeph Opened the Fusion 360 file, ran default grbl post. I did not modify anything else. Here's the resulting gcode: test_vMeph.txt

[vMeph]

@neilferreri thanks for your results sounds like the problem isnt with grbl.cps F360 the problem is with the updated F360 Strooom post processor, would you confirm it and test it also? https://github.com/Strooom/GRBL-Post-Processor

the grbl.cps only error that generates is from the line that is add to the post(T21 M6) do you remove everytime by hand the (T21 M6)?

i apolagize all the problem and time caused by this issue

[neilferreri]

@vMeph @chamnit I can confirm that errors are thrown with the OpenbuildsGRBL.cps from @Stroom and not with the default grbl post process for vMeph's file. Again, I have run hundreds of jobs using the default grbl post process, and I have not seen that error. @vMeph I separate my multi-tool jobs by tool, and I typically manually remove the M6 command. I also have gotten in the habit of adding in some extra Z lift and a return to X0Y0 at the end of the job. That really helps facilitate making multiple copies. I also always raise my Z before a job. Interestingly, the errors occur in different places than your original. I did not modify anything.

`

G3 X101.9871 Y61.2866 J0.0338 (line=2352) error:33 (Invalid gcode ID:33) G3 X95.9877 Y68.371 J0.0369 (line=2435) error:33 (Invalid gcode ID:33) G2 X108.9864 Y143.3968 J-0.0403 (line=2901) error:33 (Invalid gcode ID:33) G3 X170.9039 Y39.5616 J0.033 (line=4651) error:33 (Invalid gcode ID:33) G3 X271.4431 Y20.7063 J0.0368 (line=5374) error:33 (Invalid gcode ID:33) G3 X266.4435 Y15.0849 J0.0321 (line=5446) error:33 (Invalid gcode ID:33) G3 X248.4448 Y15.3086 J0.032 (line=5678) error:33 (Invalid gcode ID:33) G3 X231.446 Y35.322 J0.0369 (line=5916) error:33 (Invalid gcode ID:33) G2 X247.4448 Y146.2788 J-0.0383 (line=6697) error:33 (Invalid gcode ID:33)`

[chamnit]

@neilferreri : @vMeph : Can you post your Fusion360 version number and type (Mac/PC)? Also, are you both using the exact same default post config file? Meaning the most recent one? I'm curious to see why you two are generating slightly different gcode results. In the meantime, I'll get setup on Fusion360 to test this myself.

[neilferreri]

@chamnit Win7. PC. Fusion 360 ver. 2.0.3174. Generic grbl post with no modifications (I may have disabled G28). OpenbuildsGRBL post downloaded from link @vMeph shared. I used his model ran the CAM post process and it worked with the default GRBL, errors with the OpenbuildsGRBL post. I also thought our gCode would be the same since I was using his file with his CAM settings and everything. The only difference may be that vMeph modified the OpenbuildsGRBL post.

[vMeph]

@chamnit i gonna see what version is but from what i know is always latest version cause i do the updated all the time, f360 is free for startups, hoobiest and company that make less then 100k or non profit from what i know its free. i use the default post processor grbl.cps that comes included on F360, im using a Asus i5 PC

[vMeph]

I was using OpenbuildsGRBL i have modify the order of OpenbuildsGRBL, but i have try the OpenbuildsGRBL original and produces errors, with grbl.cps no issues

[CNCQuilter]

I have also encountered the same Error 33 wrt my own generated parametric values. I believe the problem may be related to imprecise calculation (rounding) of the circle formula (x-h)^2 + (y-k)^2 = r^2 and the Pythagorean relationship i^2 + j^2 = r^2 where h and k are the circle center coordinates, and i and i are the relative offsets. This is particular vexing for me.

Note the problem does not occur for “perfect” i, j, r triangles such as 0,1,1 3,4,5 5,12,13 8,15, 17 9,12,15 etc. So I suspect the issue is broader than just Fusion 360. Hoping for more insight soon.

[chamnit]

@CNCQuilter : The g-code standard describes arcs in a horribly posed mathematical sense. Just as you noticed. It's very easy to write an invalid arc command. Particularly in radius mode, and less so in incremental IJK mode.

There are hundreds of CAM program out there, and Fusion360 is only one of two that consistently produces an arc error in Grbl and has been repeatedly reported here.

If you read the thread in more detail, we've already ruled out rounding of floating point numbers as the cause. It was one of the first things we looked at and is what the modified post file that @vMeph explicitly does, which is increase the precision of the values to reduce roundoff errors. So, it's something else, and likely something internal to Fusion360. If so, it still could be roundoff error, but its not within a user's control to alter that.

[CNCQuilter]

Sony,

I beg to differ somewhat with your suggestion regarding Fusion 360 as the source of the problem;

although it certainly may share in the blame.

I have the same problem with values that were mathematically calculated in EXCEL.

I calculated the Start/End points of various arcs (based on the intersection of circles) along with their linear offsets ( i, j values) and I have experienced the Error 33 repeatedly.

I don’t fully understand grbl’s firmware setting $12 - Arc Tolerance and I sometimes wonder if it may somehow partially account for the Error 33’s.

Thanks again,

Dave K

---

From: Sonny Jeon notifications@github.com Sent: Friday, July 21, 2017 12:43 PM To: gnea/grbl Cc: CNCQuilter; Mention Subject: Re: [gnea/grbl] Gcode error33 (#230)

@CNCQuilterhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cncquilter&d=DwMFaQ&c=3buyMx9JlH1z22L_G5pM28wz_Ru6WjhVHwo-vpeS0Gk&r=zO1BysYTt4UFmSFEv9o0SbJim_z9Tb-G4UxWKuM9N7I&m=U3jh7jQhbdO4CTu3wWyBs8c1W20u-PS_Zvqj8cNMTOc&s=FuZwWv2i_k9w3lF1TkwXVEot74P3uK1fOH94bxb2vbY&e= : The g-code standard describes arcs in a horribly posed mathematical sense. Just as you noticed. It's very easy to write an invalid arc command. Particularly in radius mode, and less so in incremental IJK mode.

There are hundreds of CAM program out there, and Fusion360 is only one of two that consistently produces an arc error in Grbl and has been repeatedly reported here.

If you read the thread in more detail, we've already ruled out rounding of floating point numbers as the cause. It was one of the first things we looked at and is what the modified post file that @vMephhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_vmeph&d=DwMFaQ&c=3buyMx9JlH1z22L_G5pM28wz_Ru6WjhVHwo-vpeS0Gk&r=zO1BysYTt4UFmSFEv9o0SbJim_z9Tb-G4UxWKuM9N7I&m=U3jh7jQhbdO4CTu3wWyBs8c1W20u-PS_Zvqj8cNMTOc&s=wC5Bv_qy3eYGANOxfWp8bkLGabfa83BjMWCg0_-wVes&e= explicitly does, which is increase the precision of the values to reduce roundoff errors. So, it's something else, and likely something internal to Fusion360. If so, it still could be roundoff error, but its not within a user's control to alter that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_gnea_grbl_issues_230-23issuecomment-2D317050999&d=DwMFaQ&c=3buyMx9JlH1z22L_G5pM28wz_Ru6WjhVHwo-vpeS0Gk&r=zO1BysYTt4UFmSFEv9o0SbJim_z9Tb-G4UxWKuM9N7I&m=U3jh7jQhbdO4CTu3wWyBs8c1W20u-PS_Zvqj8cNMTOc&s=hIadydIxka9ApEa0qL9-b3_FwlOihq3hGCadOijJ7m4&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AScC7oedmXjZpY6KWha8-5FuGTjS7PGQJgks5sQNUzgaJpZM4OZKru&d=DwMFaQ&c=3buyMx9JlH1z22L_G5pM28wz_Ru6WjhVHwo-vpeS0Gk&r=zO1BysYTt4UFmSFEv9o0SbJim_z9Tb-G4UxWKuM9N7I&m=U3jh7jQhbdO4CTu3wWyBs8c1W20u-PS_Zvqj8cNMTOc&s=wxKAyHyU5a49rfKlDxEYHOuP9HUY-mhAPWc1iHWZKJM&e=.

[chamnit]

@CNCQuilter : Please read and try to understand what I just said.

One, hundreds of other CAM programs don't produce this arc error. Only Fusion360 and one other have consistently in the last several years. This means that something in the way Fusion360 or it's post processor is making it generate invalid arcs. See my comment above where I show how bad it is. It's greater than numerical roundoff.

Two, again, arcs are poorly posed in the mathematical sense and are susceptible to error, if they are not carefully handled. You have already demonstrated that and this is a very well known problem that is inherent to the g-code standard.

Third, Grbl's arc tolerance setting has nothing to do with g-code error checking. Nothing. This parameter simply determines how fine of resolution Grbl needs to trace the arc, AFTER the arc command has been checked for errors.

[vMeph]

@chamnit not sure if this relevant but lets not forget that OpenbuildsGRBL.cps https://github.com/Strooom/GRBL-Post-Processor/wiki that post processor doesnt come with F360, in my case that was the one that was producing errors with my file, but with the post processor that comes with F360 grbl.cps didnt produce those errors but like was sayed before there have been problem with F360 with other people, so dont know what to say about the way F360 post processors works i found this videos from how to make changes on orders and things about the post processor in F360, it has 3 videos about it, i didnt had the chance yet to see them all but ill leave here the link anyway https://www.youtube.com/watch?v=a2iJ9uG38eY&list=PLjUJwQJKr2zfMEwqUoUEFpw-Px8dAxnEL&index=1

[chamnit]

@vMeph : Agreed. Up to this point, Strooom's post file seems to be the problem, but it's virtually identical in overall operation to the default Grbl post on Autodesks website, except a handful of items. Most of the alterations are superficial and set gcode headers and such. Strooom originally wrote his post mod to eliminate early Fusion360 arc errors by increasing the precision of values. AFAIK, it worked and has been working. I suspect either recent Fusion360 updates may have introduced or unveiled a bug or the post only cured part of the issue, not all of it.

If I had to make a wager, I still think it's an issue of the tolerance and minChord/Radius settings and how Fusion360 handles multiple constraints being active. There are a lot of things that could go wrong because it can quickly get very complicated to solve. So post settings may be only valid in a certain range. I'll try to test this hypothesis this weekend.

[chamnit]

@vMeph @neilferreri : I've located the problem in @Strooom 's post script. It has to do with the additional xaOutput, yaOutput, and zaOutput he uses to separate the higher precision numbers used only for arcs. If you replace the xaOutput with the proper xOutput in the arc generation part of the post, no more errors.

Interestingly, only the YZ-plane line needs to replaced. XY- and XZ-planes seem to work fine. Not exactly sure what this means or whether its specific to your job.

I'm not quite sure why using the additional xaOutput variables breaks the post. If I had to guess, there is something in the Fusion360 processing that disallows it or perhaps its a weird bug. Either way, one thing is certain, @Strooom's post is the problem.

[swarfer]

Hi all I spent some hours with this last night since I was the one who added the extra digits to the Strooom post for GRBL. (bit late I know, but life was happening at a furious pace) My findings are that increasing either, but not both, of minimumChordLength = spatial(0.01, MM); minimumCircularRadius = spatial(0.01, MM); to about 0.5mm prevents issues. But this might affect surface finish on some machines.

I thought that minimumCircularSweep = toRad(0.01); was way too small an arc and might be a factor, but increasing it did not prevent issues But it strikes me now that this setting must interact with the other two and I did not test this exhaustively.

The settings that do work (for this drawing??) are allowedCircularPlanes = (1 << PLANE_XY); var xyzFormat = createFormat({decimals:(unit == MM ? 4 : 5)}); // can use 3 : 4 for both var arcFormat = createFormat({decimals:(unit == MM ? 4 : 5)});

While I prefer the 4 : 5 setting, 3 : 4 also works just fine. I prefer 4 digits for mm because the step size for a belt driven machine will (often) be 0.0375mm (or half that).
I have this idea that we should tune our post settings to the step size. For example 'tolerance' should not be smaller than the step size, what would be the point of trying to go to 10.001mm when the machine cannot actually do it? For ultimate accuracy maybe Gcode positions should be rounded to the step size?

I was using Mephs actual Fusion file for these tests. I found that the middle 2 ovals would generate errors, but not the outer 2. All the errors I saw were on the G18 or G19 arcs on the lead-in segments, never on G17 arcs. That is why I tried to restrict arcs to G17, and it works! (so maybe Fusion has a problem with vertical arcs?) (and @chamnit earlier proved that using different precision for the arcs does not work here since the preceding G1 will be off enough to cause a problem since it has 1 less digit)

My updated version of the post can be had from https://github.com/swarfer/GRBL-Post-Processor and I will appreciate it if people can test it against their problem Fusion projects.

David the swarfer