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
@CharlieMike The question of whether to use grbl mm or grbl inch has been discussed here may 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.
ā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.
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?
@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.)
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.
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
I found this article on Error 33ā¦it explains a few things. With this in mind I took a look at the Vectric Post Processor and made a couple of changes to mineā¦mainly in the formatting of the variables for both Inch and MM processors. I occasionally got Error 33 from GRBL but have not experienced any problems since changing my variable formatting. (I always design in Inches). The variable formatting I use is as followsā¦ (you can format a lot more than just variables in the PP)
+================================================
+
Formatting for variables
+================================================
VAR LINE_NUMBER = [N|A|N|1.0]
VAR DWELL_TIME = [DWELL|A|P|1.2]
VAR POWER = [P|A|S|1.0|10.0]
VAR SPINDLE_SPEED = [S|A| S|1.0]
VAR FEED_RATE = [F|C| F|1.1]
VAR X_POSITION = [X|A| X|1.4]
VAR Y_POSITION = [Y|A| Y|1.4]
VAR Z_POSITION = [Z|A| Z|1.4]
VAR X_HOME_POSITION = [XH|A| X|1.4]
VAR Y_HOME_POSITION = [YH|A| Y|1.4]
VAR Z_HOME_POSITION = [ZH|A| Z|1.4]
VAR ARC_CENTRE_I_INC_POSITION = [I|A| I|1.4]
VAR ARC_CENTRE_J_INC_POSITION = [J|A| J|1.4]
I use 4 decimal for both inches and MM (probably overkill for MM but whatever). To my way of thinkingā¦ I wanted at least .001" accuracy so I figured if I use 4 decimal places and the software rounds it up to 3 then all is well. Now, if I am all wet about GRBL core rounding up maybe someone can enlighten meā¦ but I can say my Error 33 problems have not surfaced lately.
The Vectric Post Processor is really very easy to modify as Vectric has great documentation on modifying the PP. It is accessible from the Vectric Help menu dropdown within the program. I have modified my Vectric PP for readibility and functionality of my g-codeā¦ I always check my generated g-code with Notepad++ before I give it to gSender to run on the machineā¦ so far it has worked out pretty well for me. I hope this is useful for other Vectric designers out there.
@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.
