On my printer (3 leads screws, 4 bed screws) the bed.g looks like this and performs an automatic level:

M561                    ; clear any bed transform

; If the printer hasn't been homed, home it
[more code ...]

; Probe the bed and do auto calibration
M558 H10 ; higher dive hight for yet to be levelled bed
G30 P0 X{move.axes[0].max/2}  Y{move.axes[1].max+sensors.probes[0].offsets[1]} Z-99999
G30 P1 X{move.axes[0].max-10} Y10                                              Z-99999
G30 P2 X10                    Y10                                              Z-99999 S-1

M558 H3 ; back to speed

while this is my "bed_level.g" macro for tuning the bed level screws:

; Check bed level

; Probe the bed
M558 H10
G30 P0 X{move.axes[0].max} Y{move.axes[1].min} ; probe near an adjusting screw 
G30 P1 X{move.axes[0].min} Y{move.axes[1].min}  
G30 P2 X{move.axes[0].min} Y{move.axes[1].max} 
G30 P3 X{move.axes[0].max} Y{move.axes[1].max}  S-1  ; probe near an adjusting screw and report adjustments needed
M558 H3

echo "Deviation:", move.calibration.initial.deviation ^ "mm"

As you can see the commands are the same really, so I must assume the difference is that one is called from a G32 command, vs the other is a standalone macro without any special meaning.

Is the STL / STEP for the probe holder availalbe that I see in the picture of the Revo toolboard?

@jay_s_uk This did indeed solve the problem. Well spotted!

I've just started to wire in my new Roto Toolboard. I connected the x-probe on the toolboard the same way I had it on the LC1 that it is replacing. But when I configure the input I get a timeout.

M574 X1 S1 P"21.io1.in"
CAN response timeout: board 21, req type 6060, RID 26

The board does respond to status requests and the lights are flashign in sync, although it seems slightly out of phase with the motherboard. The main and tool boards are wired to the same power supply. In fact the toolboard is wired to the same terminals the LC1 was using before, which was working fine.

The only other thing I have changed is the firmware on the motherboard. It was 3.2 with the LC1 and is now 3.5-rc3 with the RR.

Any ideas what might be causing the timeout? Status repsponse from the toolboard below

M122 B21
Diagnostics for board 21:
Duet TOOL1RR firmware version 3.5.0-rc.1+ (2023-11-17 12:25:22)
Bootloader ID: SAME5x bootloader version 2.9 (2023-10-06)
All averaging filters OK
Never used RAM 165332, free system stack 192 words
Tasks: Move(3,nWait,0.0%,182) HEAT(2,nWait,0.1%,102) CanAsync(5,nWait,0.0%,67) CanRecv(3,nWait,0.0%,80) CanClock(5,nWait,0.0%,70) ACCEL(3,nWait,0.0%,68) TMC(2,nWait,1.1%,60) MAIN(1,running,93.6%,306) IDLE(0,ready,0.0%,29) AIN(2,nWait,5.2%,231), total 100.0%
Last reset 00:31:20 ago, cause: software
Last software reset data not available
Driver 0: pos 0, 507.0 steps/mm, standstill, SG min 0, temp 35.3C, read errors 0, write errors 0, ifcnt 45, reads 46489, writes 0, timeouts 0, DMA errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, segs 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00
Peak sync jitter -2/11, peak Rx sync delay 185, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 24.2, current 24.2, max 24.2
MCU temperature: min 32.2C, current 32.6C, max 32.6C
Last sensors broadcast 0x00000002 found 1 9 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 20238, send timeouts 0, received 9104, lost 0, errs 0, boc 0, free buffers 38, min 38, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: LIS2DW, status: 00
Inductive sensor: raw value 268435455, frequency 25.00MHz, current setting 13, ok
I2C bus errors 0, naks 0, contentions 0, other errors 0

Is the STL / STEP for the probe holder availalbe that I see in the picture of the Revo toolboard?

@Piet Right. I'm not a big fan of leaving bed edges unsupported with only 3 mounting points. You might be able to tell my bed isn't that stiff. I therefore actually have 2 screws and 2 fixed points. The two screws are there so I can adjust twist in the bed. One might be theoretically enough, but two allows me to make opposing adjustments that don't move the probe point in the middle near the lead screw. Probing all 4 in the script gives me the output I need to even everything out.

All this gives us a workaround for your original question: Probe an additional dummy point in your manual test and you get the output you need for your one-off calibration.

I suspected as much. It might be worth keeping it around for backwards compatibility. Currently the error response breaks Octoprint.

On my printer (3 leads screws, 4 bed screws) the bed.g looks like this and performs an automatic level:

M561                    ; clear any bed transform

; If the printer hasn't been homed, home it
[more code ...]

; Probe the bed and do auto calibration
M558 H10 ; higher dive hight for yet to be levelled bed
G30 P0 X{move.axes[0].max/2}  Y{move.axes[1].max+sensors.probes[0].offsets[1]} Z-99999
G30 P1 X{move.axes[0].max-10} Y10                                              Z-99999
G30 P2 X10                    Y10                                              Z-99999 S-1

M558 H3 ; back to speed

while this is my "bed_level.g" macro for tuning the bed level screws:

; Check bed level

; Probe the bed
M558 H10
G30 P0 X{move.axes[0].max} Y{move.axes[1].min} ; probe near an adjusting screw 
G30 P1 X{move.axes[0].min} Y{move.axes[1].min}  
G30 P2 X{move.axes[0].min} Y{move.axes[1].max} 
G30 P3 X{move.axes[0].max} Y{move.axes[1].max}  S-1  ; probe near an adjusting screw and report adjustments needed
M558 H3

echo "Deviation:", move.calibration.initial.deviation ^ "mm"

As you can see the commands are the same really, so I must assume the difference is that one is called from a G32 command, vs the other is a standalone macro without any special meaning.

I'm getting this error response from a Duet 3 with SBC. Is this due to the SD "card" being a directory on the SBC, which doesn't need initialising? The gcode documentation or forums do not give any hint on why this code is not supported (any more).

Have you had a look at RepPanel?

@achrn Playing with it a bit more last night I can confirm that the sample code does run correctly when called directly. Where I have problems is when I call the exact some code while there are other things going on.
I'm trying to write an Octoprint plugin that provide a virtual printer in Octoprint, so that I can use TheSpaghettiDetective and the Canvas plugins for the Pallette device without having to go through the serial connection. So the code is called up on startup of the Octoprint server when it loads all plugins and the process is obviously busy at that time with multiple threads doing things at the same time. This seems to have an affect, hence my question on the tread safety of the API.

@achrn Don't think so. This is an initial model, coming in unsolicited directly after the connection has been made. The printer is standing still and I can see the complete model in the recv line. The problem might actually be on the dsf side, where it shouldn't send out a machine model unless specifically requested.