Tip: use metric for your post processing

Community Discussion 🧠 New Wisdom
1

I had a strange error today. The resolution was as simple as changing the post to mm instead of the evil imperial inches. So I share this not as a suggestion for gSender, but as a suggestion for gSender users. (it was also the only category that seemed to make sense - mods move as you deem necessary obviously)

I ran two jobs. First one ran with zero issues. Tried to run the second and I received the brown “hold” box on the upper right of the visualizer. Clicked “resume” it kept going. After the 5th time 20 seconds in to the job I hit the e stop and tried to solve the problem.

Switched USB cables, kicked trash cans, prayed to the CNC gods, nothing worked. Search didn’t find much other than a hint about USB connection. I cried for a little then I think I found some setting to enable error logging and ran it again.

This time I got errors for invalid g code on some lines.

This made no sense to me. The code was made using identical post processor as the job I ran successfully a mere 30 minutes earlier. From the same fusion file. I copied the setup to the next component to setup toolpaths. Same 2D contour and holes. Similar shape. I could not figure it out. Google told me the invalid tool paths are sometimes related to inch post in grbl not cranking out enough significant digits to make for happy math. Whatever - it worked in the earlier job why would it suddenly matter when there isn’t much difference in this?*

So I regenerated the gcode using mm instead of inches.

It ran without a hitch. I am officially a metric post process convert now.

  • as I think about it I guess the issue may be the second one was more of a parallelogram shape versus a rectangle. Maybe it liked more significant digits for precision moving X and Y to a point instead of just X or Y? anyway… metric ftw
4 Likes
2

@CharlieMike The question of whether to use grbl mm or grbl inch has been discussed here many times. Members far more knowledgeable on this than me always recommend using grbl mm. They hasten to add that this does not mean that you must design in metric units. There seems to be quite a bit of confusion on that point. (I design in VCarvePro in inches. I’m old. What can I say. Taking the advice of those members, I write out using the grbl mm post processor.)

The explanation as to why it is the preferred post has something to do with the fact that grbl is natively metric. When pushed to change all the meaurements to imperial, it can do it. However, some accuracy is lost. The effect this has on our projects varies wildly depending on the project. I’m thinking that you hit on something with your projects that reinforces the grbl mm advice.

Thanks for posting about your experience.

4 Likes
3

“Ah that’s all nonsense I’m not going to do things where I need to be THAT precise - who cares. Inches will be fine for me.”

Opps. :face_with_open_eyes_and_hand_over_mouth:

With Fusion it’s also easy to design in whatever I want and just post to metric so it’s also no issue. But yeah - this was an eye opener. Learned something today.

I think they’ll let me keep my US citizenship as long as I still occasionally design in inches. So I should be good. Right, Uncle Sam?

3 Likes
4

I’m thinking that what you’ve hit on is some creeping error in gSender’s code that doesn’t do the conversion correctly or to specs.

Perhaps its an insidious hint from the gSender developers? :smiley:

1 Like
5

@CrookedWoodTex gSender does not do any conversion. If the header of the gcode contains G20, all of the movement numbers in the file are inches. If it contains G21, all are millimetres. The post processor writes those header instructions. gSender simply reads them. (Excuse me if you already know all this.)

1 Like
6

It is confusing because gSender is actually setting error codes from the post processor gcode.

7

Exactly! The same post processor I used to successfully run a job just minutes before. Both created out of the same Fusion file. Just different components. So it was quite confusing and frustrating that suddenly the code it was outputting appeared to have a problem. It was clearly listed as an Error 33 so I did see it was an issue with an invalid motion command so I did understand it could have been a non syntax type error. But still a head scratcher at first.

I am curious to learn more about how grbl works and why this is a thing. But not THAT curious. I’m good with just setting it to mm and moving on with this one.

8

Yes this is an interesting issue documented with a couple specific CAM programs and the post processors, I recently documented it here too: grbl Alarms & Errors - gSender

Thanks for posting @CharlieMike, think I’ll actually move it to the general conversation area so it gets exposure to others on the forum too :+1:

1 Like
9

@CharlieMike Can you share the file that has the issue?

1 Like
10

That ↑is funny! Maybe they will kick me out because I switched to metric everywhere! :man_shrugging:

2 Likes
12

I use 6 on my inch Post Processors.

@Soxone Since you like checking your gcode…a bit unnecessary these days, but I made a simple arc checking Google Sheet back when these errors were more common.

1 Like
13

HELP! I encountered the same issue: error 33. The small radii, (radiuses?) cause the tool to forget to lift at the traverse.

Switch to metric they said, it’ll be easy.

I’m missing one step, because my part is showing up .0393701 sized.

I switched the report in inches off in gsender, and changed my settings in Aspire to mm. The part that was 24” x 12” is now 600mm (and change) x 300mm. I saved to Rapidchange’s MM PP.

But the part shows up 24mm long. WHat setting am I missing?

Thanks, you guys have saved me more than once or twice.