Is something wrong with this gcode or is it gsender?

gSender ❓ Question
1

I get the following errors in gsender when running this job:

Error 1 on line 92 - Expected command letter

Error 33 on line 93 - Invalid g-code ID:33

Error 33 on line 98 - Invalid g-code ID:33

Here is line 90-99, I added the line numbers to make it easier to read:

90: G3 X142.875 Y93.662 I11.113 J0
91: G1 X261.938
92: G3 X262.255 Y93.98 I0 J0.318
93: G1 Y94.298
94: G19 G3 Y94.615 Z-2.569 J0 K0.317
95: G1 Z6
96: X261.62
97: Z-2.252 F33.3
98: Z-3.541
99: G2 Y94.298 Z-3.859 J-0.317 K0 F100

I created the gcode with Fusion 360.

I’m using gSender 1.2.2 – I’ll check for updates and update to the latest version before I run my next job.

Based on the suggested reading here gSender 1.2.2 still seeing gcode errors - #6 by SLabuta – possibly Fusion 360 just isn’t compatible with gsender, so I need to find/learn a new tool to create the gcode. But, it is so nice being able to use one tool for everything, unlike my 3D printing workflow where I do have to load up a separate slicer :expressionless:

2

No matter what CAD software you use, it will have to know something about your equipment before it can produce gcode for that equipment. Usually, this is in the forum of a post processor that has been tuned to produce gcode for the named equipment.
It could be as simple as selecting a generic grbl controller.

So, did you define something about your equipment in Fusion 360 when you went to save to gcode?

2 Likes
3

What post processor?

I use Fusion extensively and almost always with gSender. The issue isn’t one of compatibility between the two.

1 Like
4

I am using the Grbl/grbl post processor from the Fusion 360 Library. Version 44104. I just noticed when I click “edit” it takes me to some source code which has a link to this page:

5

Probably an important detail. When I do “Test Run” it reports no errors. I also turned on these settings (below) and I see no errors when opening the file. So far I only see errors when actually running the job. I am using the remote mode, starting the job from the browser on my Mac with the actual gSender app installed on a Raspberry Pi 4B connected to the Longmill MK2 48x30. Maybe some issue with the file transfer with this remote mode – I might try it local and see if different results.

image
image784×302 17.2 KB

6

I exported the file as mm instead of inches, and I also am running locally on rpi instead of remote browser/headless. The job isn’t 100% done yet, but it got further than where it started erroring last time.

I suspect the fix was the mm instead of inches change, since this states that could be an issue: fusion360 g code errors · Issue #213 · gnea/grbl · GitHub

Next job I need to run I’ll try mm and remote/headless to rule out the remote part being the issue – it is a PITA to connect to the rpi, so hopefully the headless/remote stuff isn’t a problem.

7

But you’re using mm in your original file in the original post, right?
I haven’t messed with the default Grbl post, and I’d be surprised if we had a regression in their official post processor. If $C mode runs without errors, but you get reports when running with the machine it could be an EMI issue or a bad USB cable or something.

I remember that GitHub thread. Can’t believe it was 7yrs ago. I still hear from that luthier once in a while.

8

Interesting. I thought it was inches before, but based on those numbers in original post it must have been mm also. I had the post process settings on the default “document units”, and that is set to mm I see (even though I entered all my values in inches and UI set to display inches).

I will need to make a few more of this exact piece but it will probably be a while before the next one. If I remember I’ll follow-up here with the results – I will try it remotely again next time.