Help with XYZ Probe

Good morning, long time reader but first time posting here. I have a question about setting up an XYZ probe on a primo. I’ve been successfully drawing and using my new build, and would like to be able to use a probing routine to repeatedly find work 0,0,0. I know I don’t really need it, but I enjoy experimenting and would like to try it.

To start, I’ve tried to setup a Z only macro (based on information found on this forum and others)in cnc.js and am able to run it, however it fails on g38.2 command.

I’m running the v1 dual end stop firmware on an SKR 1.2 from Ryan’s store. My output is below, and indicates the command isn’t recognized. Wondering if I have a syntax issue or if there is something I need to configure. Any advice on how to troubleshoot from here is appreciated.

Thanks,
Mike

CNCjs 1.10.3 [Marlin]
Connected to COM4 with a baud rate of 115200
FIRMWARE_NAME:Marlin 515D 2.1.1 (Mar 30 2024 16:23:09) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:V1CNC 515D EXTRUDER_COUNT:0 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Cap:SERIAL_XON_XOFF:0
Cap:BINARY_FILE_TRANSFER:0
Cap:EEPROM:1
Cap:VOLUMETRIC:0
Cap:AUTOREPORT_POS:1
Cap:AUTOREPORT_TEMP:0
Cap:PROGRESS:0
Cap:PRINT_JOB:1
Cap:AUTOLEVEL:0
Cap:RUNOUT:0
Cap:Z_PROBE:0
Cap:LEVELING_DATA:0
Cap:BUILD_PERCENT:0
Cap:SOFTWARE_POWER:0
Cap:TOGGLE_LIGHTS:0
Cap:CASE_LIGHT_BRIGHTNESS:0
Cap:EMERGENCY_PARSER:1
Cap:HOST_ACTION_COMMANDS:1
Cap:PROMPT_SUPPORT:1
Cap:SDCARD:1
Cap:MULTI_VOLUME:0
Cap:REPEAT:0
Cap:SD_WRITE:1
Cap:AUTOREPORT_SD_STATUS:1
Cap:LONG_FILENAME:0
Cap:LFN_WRITE:0
Cap:CUSTOM_FIRMWARE_UPLOAD:0
Cap:EXTENDED_M20:0
Cap:THERMAL_PROTECTION:1
Cap:MOTION_MODES:1
Cap:ARCS:1
Cap:BABYSTEPPING:1
Cap:CHAMBER_TEMPERATURE:0
Cap:COOLER_TEMPERATURE:0
Cap:MEATPACK:0
Cap:CONFIG_EXPORT:0
area:{full:{min:{x:0.0000,y:0.0000,z:0.0000},max:{x:1220.0000,y:2440.0000,z:200.0000}},work:{min:{x:0.0000,y:0.0000,z:0.0000},max:{x:1220.0000,y:2440.0000,z:200.0000}}}
feeder> G91
ok
feeder> G0 Y10
ok
feeder> G90
ok
feeder> G54
Select workspace 0
X:0.0000 Y:10.0000 Z:0.0000 Count X:0 Y:1000 Z:0
ok
feeder> G21
ok
feeder> G91
ok
feeder> G38.2 F75 Z-35
echo:Unknown command: “G38.2 F75 Z-35”
ok
feeder> G92 Z10
X:0.0000 Y:10.0000 Z:10.0000 Count X:0 Y:1000 Z:0
ok

G38 g-code command is not enabled in the V1 maintained Marlin firmware for the Primo. You can use G28 instead for Z. I’ve seen a couple of threads on the forum about enabling G38 in the Primo firmware. It is not as simple as just changing a single define and recompiling. Here is a post where I enable G38 for use as part of a bitsetter functionality, but the results are very specific what I was trying to do. In this post, Ryan gives a recipe, but I don’t know if it was ever verified.

As for finding the corner for X and Y, I went part way down that rabbit hole using a corner plate similar to this one. The problem I ran into was that the scripts need to know the diameter of the router bit. I could have just made separate routines for 1/8 and 1/4 bits, but I’d be depending on the milled diameter of the bit being accurate, and that the diameter would be read correctly even with the flutes on the bit.

As an alternate solution to probing, you could mount fences (or pins) so that your stock is mounted at a known coordinate. Then your scripts could easily find the corner of the stock.

Thank you Robert. I have read many of your posts and appreciate the thoughtful response.

Most of my planned work will be using templates, and I have dog holes to be able to locate the stock template or “part holder” in a repeatable way. I was actually thinking I would use the corner probe for the “odd parts” that require me to remove any guides and just clamp. I know I can manually position X Y zero, but thought it would be fun to explore the precision of a corner probe.

I will review the links you provided and see if I really want to go down this path. It sounds like “in your experiences” is the payoff for most people isn’t necessarily worth the effort. I certainly realize that in my wood working, the limiting factor is not the MPCNC or the accuracy of zero, it’s me!

Thanks for clarifying the firmware issue, and for the suggested reading.