Gcode error 33: Invalid Target

Software / Firmware Jackpot Board / FluidNC
1

Hi All,
Generated and ran the Test Crown with flying colors (build thread soon!) Using EstlCam 12 + Jackpot.

Updated FluidNC to 3.7.12 (web installer, manually copied over index.html.gz as per instructions. Confused that they didn’t include pressing the Boot button to start the flashing in the instructions… but worked in the end.) Kept my mostly stock config.yaml (just added table size limits and pulloffs to square/tram.)

For some reason, even this simple Circle test (also getting it with a square test bracket thing that’s super simple) the gcode generated throws this:

[MSG: ERR:  33 (Gcode invalid target) in /sd/Circle.gcode at line 19]

The Gcode in question. Line 19 is at the bottom, the G2 command.

G21 (MSG G21: Metric mode)
G90 (MSG G90: Switching to absolute positioning) 
G94 (MSG G94: Feed = per minute)
G92 X0 Y0
$HZ (Home Z)
M0 (MSG Attach probe)
G38.2 G91 Z-75 F400 (MSG G38.2: Fast probing to material)
G1 Z5 F400 (MSG G1 move Z up by 5mm, speed 400)
G38.2 G91 Z-6 F100 P0.50 (MSG G38.2: Slow probing to material. Plate thickness: 0.50)
G1 Z10 F900 (MSG G1: go to Z10, speed 900)
M0 (MSG Remove probe, start spindle)
G0 X0.0000 Y0.0000 Z0.0000 F10000
G0 Z5.0000 F3000

(No. 1 Part machining: Part 1)
G0 X6.2013 Y6.2013 Z5.0000 F10000
G0 Z0.5000 F3000
G1 Z0.0000 F180 S24000
G2 X3.0180 Y10.0475 Z-5.0000 I18.8011 J18.8010
*dies*

I have an arc in my other test file, and the G3 command throws the same error.

I also generated the same file in EstlCam 11, so it doesn’t seem like that’s the issue.

But, the crown gcode still works like a champ on the new firmware version (I skipped the probe for pen purposes.) It has plenty of G2 and G3 commands (circles, arcs.) This works great:

G21
G90
G94
G92 X0 Y0
G0 X0.0000 Y0.0000 F10000
G0 Z5.0000 F3000
(No. 1 Engraving machining: Engraving 1)
G0 X24.9205 Y7.3575 Z5.0000 F10000
G0 Z0.5000 F3000
G1 Z0.0000 F120 S24000
G1 Z-0.0100
G1 X24.4100 Y9.0866 F900
G2 X42.8088 Y12.5866 I33.5699 J-126.3622
G2 X74.6541 Y13.7669 I23.2760 J-197.7991
G2 X99.1099 Y11.0729 I-5.9547 J-166.4011
G2 X107.7594 Y9.0866 I-20.2270 J-107.9094
G1 X107.1192 Y6.9182
G3 X89.0271 Y10.3332 I-32.8943 J-124.6382
G3 X57.6210 Y11.4798 I-22.9424 J-197.7174

Any ideas? I’m super confused. FluidNC seems perfectly happy with the gcode in the attached image.

I guess I can try disabling the circle/arc generation in the estlcam settings.

PXL_20240120_183558469
PXL_20240120_1835584691920×1446 157 KB

1 Like
2

Did you change your Estlcam setting from Marlin to GRBL?

If you have I can see what arcs look like on my output in a bit. GRBL handles arcs fine, so it must be a slight format difference.

1 Like
3

I definitely switched setting to GRBL. The weird thing is the test crown has arcs galore, all fine. So not sure what’s so weird about my basic test. Just a DXF exported from Fusion360…

4

(I did verify that turning off arcs/circles works, but that’s not really a solution.)

5

I also imported the jackpot settings file for estlcam 11 and generated the same “invalid target” error, so scratching my head on this one.

6

I do see that it’s setting a Z height in the G2 and G3 commands which is one difference.
And when I run the arc-less code, it doesn’t respect the Z probed height, it air cuts.

So I’m suspecting some Z height shenanigans.

7

Consider this possible cause:

8

What does your probe script look like? Or how are you probing?

9

I baked the probe in the top of the script in the post. I’ll try manually probing (your script, thanks for that!) without all that instead and see what happens.

10

maybe copy and paste here the probe code at top of file

11

Success!
I removed the homing code and just did homing manually.

Thanks for helping me troubleshoot! Issue is definitely something to do with Z heights

Weird. I’ll look closer later after lunch.

(Random part I threw together in fusion for clamping fun)

PXL_20240120_200951370
PXL_20240120_2009513701920×1446 212 KB

7 Likes
12

Awesome.

13

After revisiting the code, I think the issue was that i was using G91 in those initial probes:

G38.2 G91 Z-75 F400

Don’t have a strong grasp on the whole workspaces concept, but pretty sure that was the issue, somehow. Still staring at Supported Gcodes | Wiki.js
I’ve embraced the whole manual Probe, set X=0, Y=0 where I want it (via the web ui, love the Tablet mode!) then running the job. Might try nonvolatile workspaces if I end up with set fixtures (e.g. corner clamp screwed to the surface.)

1 Like
14

So, I think (and when it comes to Gcodes, that’s dangerous), but if I remember right, that G91 basically told the probing operating “probe relative to current location, by -75 in Z” —

There can be a big difference between “go to absolute location -75” and “go to -75 relative to current location”

And I think the GCode G91 reference to “incremental” (as opposed to G90 meaning absolute) means basically “relative to where we are now.”

1 Like
15

All starting to make sense, and explains why I was surprised to be hitting my Z soft limit at times.
Was in a rush to cut something at the time, but will take a slower approach as I evolve my workflow. What fun!

1 Like
16

Probably been linked a million times since it’s 6 years old, but finally came across this video on gcode coordinate systems from Bart himself, which gives some added clarity.

1 Like
17

I had never seen that video. Very helpful. Thanks!

18

Looking over this again a few weeks later with a fresh perspective, the issue appears to be that I never set mode back to G90 (absolute mode) again after homing (which sets G91, relative mode, in-line with the G38.2 commands.)
So the cuts were starting in relative mode, explaining the air cuts and the error for the arc command. Apparently arcs in relative mode are a bad idea (not possible even?) in this case. Also explains why I was hitting soft limits on Z, legitimately!

1 Like