Error 33 with Arc Motions

[einencool]

Hello,
I've got a question about your Post Processor.
Very often I get the "Error 33" when trying to cut some round shapes or with adaptive clearing.

I read about this issue, that it comes from a difference in the positions where the arc begins and where it ends.

Sometimes I've no chance to get the Code running on my CNC (using Grbl 1.1 with bCNC) When I switch the Post to the normal GRBL Post. then everything works fine.

Someone wrote, he changes the Arcmotion from "xaOutput" tp "xOutput" and then it works.
Could this be possible, and what could be the reason for that?

If you would like, I can attach a little Program with the Strooom and the GRBL Post to see the difference.

Many thanks in advance.
Greets Chris

[Strooom]

Hello, Yes it is a known bug, It was introduced by another contributor and I missed it when doing the merge. In the mean time I know what causes the problem : insufficient digits for gcode words used on arcs. When thevarc has a small radius, the rounding error of the last digit somtimes is too big for GRBL. So its rather simple to correct, I just postponed because I was working on other stuff. If you want to experiment, look into the javascript and increase the number of digits by 1 or 2. Kind regards, Pascal Op di 17 jul. 2018 om 21:50 schreef einencool <notifications@github.com>

Hello, I've got a question about your Post Processor. Very often I get the "Error 33" when trying to cut some round shapes or with adaptive clearing. I read about this issue, that it comes from a difference in the positions where the arc begins and where it ends. Sometimes I've no chance to get the Code running on my CNC (using Grbl 1.1 with bCNC) When I switch the Post to the normal GRBL Post. then everything works fine. Someone wrote, he changes the Arcmotion from "xaOutput" tp "xOutput" and then it works. Could this be possible, and what could be the reason for that? If you would like, I can attach a little Program with the Strooom and the GRBL Post to see the difference. Many thanks in advance. Greets Chris — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APqnZdI1Jducf_lNfbwhStoDzVe64bXWks5uHkAagaJpZM4VTdTd> .

-- Met vriendelijke groeten Pascal Roobrouck

…

------------------------------------------------------------------------------------------------ *Instructables <https://www.instructables.com/member/strooom/> | Github <https://github.com/Strooom> | Twitter <https://twitter.com/strooom>*

[einencool]

Hi Pascal,

You mean, for Arcs the amount of digits should be 5 or 6 ?
So 0,00000x points instead of 0,000x?

For me it sounds a little bit strange, because on the „normal“ GRBL Post there are only 3 digits and it works.
In your Post there are already 4 digits.

But I will try it in the next days and give you a feedback.
I hope I‘ll find the Program where I have so many issues.

Thank you for your response
Greets Chris

[Strooom]

I think you are right, 4 digits should be ok. Let me look into this when I get home - currently enjoying a week of holidays in the mountains... P Op wo 18 jul. 2018 om 21:15 schreef einencool <notifications@github.com>

Hi Pascal, You mean, for Arcs the amount of digits should be 5 or 6 ? So 0,00000x points instead of 0,000x? For me it sounds a little bit strange, because on the „normal“ GRBL Post there are only 3 digits and it works. In your Post there are already 4 digits. But I will try it in the next days and give you a feedback. I hope I‘ll find the Program where I have so many issues. Thank you for your response Greets Chris — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APqnZWUC4kpP9F6abUkzRKnhobldsH98ks5uH4logaJpZM4VTdTd> .

-- Met vriendelijke groeten Pascal Roobrouck

…

------------------------------------------------------------------------------------------------ *Instructables <https://www.instructables.com/member/strooom/> | Github <https://github.com/Strooom> | Twitter <https://twitter.com/strooom>*

[einencool]

Hi Pascal,

Sure, enjoy your trip, and if you get some time for this, it would be great if you can fix this :-)

Greets
Chris

[rccoffin]

Hi Pascal - I've been using your F360 post for some time now for a DIY GRBL based CNC with some very limited functionality. I did some (poor) hacks to accommodate my preference for inches and remove a few other limitations of my machine. Over the weekend I was doing a 3d carve from F360 and started getting a lot of error:33, 36, & 26. Looking at the gcode I noticed a couple of things which I think are causing this. Trailing zeros are getting trimmed which leaves you with a smaller number of digits for the arcs - my hack was to add "trim:false" to the vars xyzFormat, arcFormat, feedFormat. I also found a google reference to GRBL1.1 not respecting previous position in G2/G3 modal commands. I found GCode in my nc file with lines of G2/G3 without the xyz moves but with the appropriate ij moves. My hack for this was to add "force:true" to each of the vars xaOutput, yaOutput, zaOutput. The gcode looks better now. I'll try to run this weekend. Hope this is useful input. I sure appreciate all the work that you have done on this post.
Regards - Russ

[Strooom]

Hi Russ, thanks for your message. Indeed there seems to be some problems with error 33, although I have never had it myself. Several people have posted their opinion on the cause of this error, but I'm not 100% sure we completely understand it. Your suggestions are useful : 1. I understand the trim:false, but I don't understand why trailing zeroes would matter, as they don't really change the value of the number... Could be that the ascii-to-float routine GRBL uses, has a problem here.. I could add the trim:false, but would like to understand why it makes a difference... 2. I understand the force:true, but the purpose of a smart postProcessor is to only output gCode when really needed... Furthermore I want to remove the xaOutput variables from the code (they were added by 'swarfer', but introduced other problems..) By adding force:true I am worried that each line of gCode will output X, Y and Z, even if there is no change in some of them.. I am reviewing the whole postProcessor right now, and when I have a test-version, I'll send it to you. Looking at the stars in Github, it seems to be really useful to many cnc-hobbyists around the world, so it is worth to give it another upgrade... kind regards, Pascal Op di 24 jul. 2018 om 02:41 schreef rccoffin <notifications@github.com>:

…

Hi Pascal - I've been using your F360 post for some time now for a DIY GRBL based CNC with some very limited functionality. I did some (poor) hacks to accommodate my preference for inches and remove a few other limitations of my machine. Over the weekend I was doing a 3d carve from F360 and started getting a lot of error:33, 36, & 26. Looking at the gcode I noticed a couple of things which I think are causing this. Trailing zeros are getting trimmed which leaves you with a smaller number of digits for the arcs - my hack was to add "trim:false" to the vars xyzFormat, arcFormat, feedFormat. I also found a google reference to GRBL1.1 not respecting previous position in G2/G3 modal commands. I found GCode in my nc file with lines of G2/G3 without the xyz moves but with the appropriate ij moves. My hack for this was to add "force:true" to each of the vars xaOutput, yaOutput, zaOutput. The gcode looks better now. I'll try to run this weekend. Hope this is useful input. I sure appreciate all the work that you have done on this post. Regards - Russ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APqnZUxNAUEAleycLwOIoBavBTUiWUBEks5uJm04gaJpZM4VTdTd> .

-- Met vriendelijke groeten Pascal Roobrouck

------------------------------------------------------------------------------------------------ *Instructables <https://www.instructables.com/member/strooom/> | Github <https://github.com/Strooom> | Twitter <https://twitter.com/strooom>*

[Strooom]

Here is when GRBL decides to throw an error 33:

When the arc is projected on the selected plane, the distance from the current point to the center differs from the distance from the end point to the center by more than (.05 inch/.5 mm) OR ((.0005 inch/.005mm) AND .1% of radius).

Looking at the 0.1% of radius :

• when using x decimal digits of resolution, the rounding error is ~ (0.5 /10^X)
• 0.001 * R >= 0.5 / 10^X
• R <= 0.5 / 10^(X-3)

So with X=3, arcs with radius of 1mm could be in trouble..

Possible solution I see :

1. Increase resolution (X=4 or x=5)
2. linearize the arc if the radius is still smaller than 10^(X-3)
3. reduce tolerance for linearization from 0.005 to 0.002 mm

[rccoffin]

Thanks Pascal - I know my hacks are brute force and heavy handed and I wouldn't recommend adopting directly - I look forward to the new version of the post processor.

• the trim;false was only because I noticed that error 33 happened when 0.3210 had been trimmed to 0.321 - I know these numbers are technically the same and there could be some other cause. BTW - I had set both linear and arc to 4:4 previously. I have no evidence that there is 100% correlation between trimming and error 33.
• the force:true is overkill as well. I suspect that the error:33 was resetting something in GRBL so that when UGS send is restarted GRBL forgets where it was and complains. Again no 100% evidence ...
• thinking about it, even though GRBL was complaining about things, there did not seem to be any problems with the actual carve. You would think it would mess up things but there was no visible problems introduced. The many error-pause-ok-restart sequences did not seem to have any undesirable outcome other than I needed to be more watchful of the operation.

Regards - Russ

[Strooom]

ok Russ, thanks for that info. I am diving into the details of Autodesk postProcessors and hopefully I can write a better next version. I'll be sending a test file soon. P Op wo 25 jul. 2018 om 15:38 schreef rccoffin <notifications@github.com>:

…

Thanks Pascal - I know my hacks are brute force and heavy handed and I wouldn't recommend adopting directly - I look forward to the new version of the post processor. - the trim;false was only because I noticed that error 33 happened when 0.3210 had been trimmed to 0.321 - I know these numbers are technically the same and there could be some other cause. BTW - I had set both linear and arc to 4:4 previously. I have no evidence that there is 100% correlation between trimming and error 33. - the force:true is overkill as well. I suspect that the error:33 was resetting something in GRBL so that when UGS send is restarted GRBL forgets where it was and complains. Again no 100% evidence ... - thinking about it, even though GRBL was complaining about things, there did not seem to be any problems with the actual carve. You would think it would mess up things but there was no visible problems introduced. The many error-pause-ok-restart sequences did not seem to have any undesirable outcome other than I needed to be more watchful of the operation. Regards - Russ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APqnZdHaJ3pmrOlVYRAzZa-9oCBEx527ks5uKHTSgaJpZM4VTdTd> .

-- Met vriendelijke groeten Pascal Roobrouck

------------------------------------------------------------------------------------------------ *Instructables <https://www.instructables.com/member/strooom/> | Github <https://github.com/Strooom> | Twitter <https://twitter.com/strooom>*

[Strooom]

Hi all,

I've investigated the issue and I think it is due to rounding errors on very small arcs..
I think it can be solved by:

• increasing the number of digits - which I've done. Fusion will trim the numbers from trailing zeroes anyway, so in most cases this will not lead to a significant increase of the GCode filesize...
• setting some parameters such as minimumChordLength, minimumCircularRadius, minimumCircularSweep. When these are set to slightly larger values, Fusion will linearize those tiny arcs if it needs them.

Finally, with investigating this issue, my understanding of how the postProcessor works was extended, and as such I was able to simplify some other parts of the code. I think the simpler, the better.

Let me know how it works for you !,

kind regards,

Pascal

[Mynasru]

After increasing the number of digits, and setting the parameters larger it worked for me.