@Phaedrux Thanks. The DWC v1.20 in my second post was a mistake, that was my previous version. I'm on DWC 2.04 now, but good point, I'll upload the full 2.05 zip file in case I missed anything.

Everything seems to be working okay otherwise which is a surprise since I had to piece together what the original manufacturer did to get it set up by looking at the wiring and old .g files. 24V supply, 220V heated bed supply, self driven servos....way more complicated than the simple i3 style cartesian I setup previously. I'm really thankful for resources here and in the wiki. I wouldn't have been able to do this otherwise.

Thanks Phaedrux, I'll give that a try.

I'm a bit confused as to what G30 parameters I should be using to set the datum though? Is is just a plain G30 command that will set it or are there additional parameters that I need to use?

When I call G32 and run bed.g, this is what I have right now. Does this look reasonable?

M561			; clear any bed transform
M280 P7 S60 I0		; clear probe errors
M401			; deploy probe
M402			; retract probe 
G28			; home all
M400			; wait for homing to complete
T0			; activate left extruder and move within its coordinate system
G1 X417 Y303 Z10	; move probe to the center of the bed
G30			; probe center of bed to set z=0 datum

G29			; perform bed mesh probe

G1 X50 Y50 Z5 F6000	; move to (50,50,5) at 100mm/s
M280 P7 S60 I0		; clear any errors
M402			; retract bed probe

Then in my startup G-Code I'll run:

G1 X417 Y303 Z10 F6000	; move probe to center of bed
M400		; wait for move to complete
G30		; Probe center of bed and set z datum
M400		; wait for probe to complete
G29 S1		; load height map from file (to enable bed compensation)

I've got a large format machine and I've just updated to RRF firmware 2.05 after coming from 1.19 which basically means I've had to set up the machine from scratch again since my homing and bed leveling routines no longer seem to work as they did in the old firmware. The printer is a large format machine (1000x1000x500) that uses inductive end stops on x, y and z but is also equipped with BL Touch for bed mapping. Currently I'm getting an error that a z datum hasn't been set after homing when I try to load a height map.

Previously, my process to level the bed and get things working was as follows.

• Physically level the gantry.
• Physically level the bed using a dial indicator mounted on the gantry.
• Move the left nozzle in the center of the bed and physically adjust it's height to be 0.15mm above the glass using a feeler gauge.
• Repeat for the second nozzle.
• Move the probe to the center of the bed to probe the same point and use G30 S-1 determine the z offset necessary for G31 command in config.g.
• Run G29 mesh probe and store the results.
• My startup G Code would then home all, load the mesh file and I would have the slicer apply a -0.15mm global offset.
• First layer bliss. No issues.

With the older firmware the BL touch was setup using M558 P6 probe type and was physically wired to the E1 end stop position. Upon changing to the newer 2.05 firmware I've had to rewire the BL Touch to use the z probe connector on the board and change the M558 command to a P9 probe type. This seems to have changed how BL Touch interacts with the firmware leading to my z-datum issue.

Is there a way to get the machine to use the z=0 point set by the z endstop as the datum for the height map? Or can someone suggest a series of commands I should be running to probe the bed and properly establish a z-datum using the BL Touch?

@dc42 Will do. Thank you for your help!

M401 and M402 commands are working and I was able to get through two bed leveling routines without an issue. Looks like it's now working as intended.

One more quick question, is it now best practice to use M401 and M402 command for probe deployment/retraction in macros and startup g-code or is using M280 commands still okay? Just curious if I need to edit my macros and .g files to use the M401/402 commands so the board can properly track the probe state?

Deployprobe.g has M280 P7 S10 I0, but I found a mistake in the retractprobe.g file which had M280 P7 S90 I1 instead of I0. I suspect this was part of the issue.

I corrected this, changed the M558 command to use P9 and moved the wiring connections from E1 STOP to the Z PROBE connections. I'm running a bed leveling routine now, so we'll see how it goes. I'll also check the M401 and M402 commands once it completes.

I'd rather keep using the physical end stop for Z if I can. It worked fine in 1.19 and I trust the sensor a lot more than I trust the BL touch for homing given that a $1000 piece of glass is on the line and I'm almost never in the same room when starting a print.

Can I just move the the wiring connections from the E1 Stop connector (GND and E1 STOP) to the appropriate pins for the z probe connector (GND and Z PROBE IN) and change my M558 to use the P9 probe type?

I've just upgraded the firmware on a large format 3DP Workbench from 1.19 to 2.05 and I'm having some issues with getting the BL Touch working correctly. Right now I can command the probe and it works correctly most of the time, but when I run my bed leveling routine which has 256 points due to the size of the bed (1mx1m) the probe will occasionally fail to retract which causes the leveling routine to fail.

The machine has a version 1.04b duet ethernet board and an expansion board that runs servos with built in drivers on the x, y and z axis. Additionally, it uses some sort of magnetic or inductive end stop to home the x, y and z axis (it does not use the bl touch to home z). These end stops are powered from an off-board source, but the signal wires connect to the end stop connectors on the duet main board.

The BL touch has been wired up to use the heater 7 connector on the expansion board (GND, +5V and signal) but is also wired to the E1 endstop at the GND and E1 Stop pins.

The stock 1.19 firmware used the following commands to setup the BL Touch and endstops:

;;;;;;;;;;;;;; ENDSTOPS ;;;;;;;;;;;;;;;

M574 X1 Y1 Z1 S0 ; Define active low and unused microswitches
M574 E0 S0 ; Define E0 endstop active low for filament sensor

;;;;;;;;;;;;;; BLTouch Bed Probe ;;;;;;;;;;;;;;;

M307 H7 A-1 C-1 D-1 ; Set Heater 7 as servo pin for BLTouch
M558 P6 X0 Y0 Z1 H5 F120 T6000 ; Set Z probe type to unmodulated, the axes for which it is used and the probe + travel speeds
G31 P100 X39 Y190 Z2.95 ; Set Z probe trigger value, offset and trigger height

The 2.05 firmware that I setup using the config tool now has the following:

;;;;;;;;;;;;;; ENDSTOPS ;;;;;;;;;;;;;;;

M574 X1 Y1 Z1 S0 ; set active low and disabled endstops
M574 E0 S0 ; Define E0 endstop active low for filament sensor

;;;;;;;;;;;;;; BLTouch Bed Probe ;;;;;;;;;;;;;;;

M307 H7 A-1 C-1 D-1 ; disable heater 7 on PWM channel and use for BLTouch
;M558 P9 H5 F120 T6000 ; set Z probe type to bltouch and the dive height + speeds (generated by RRF configurator)
M558 P6 X0 Y0 Z1 H5 F120 T6000 ; set Z probe type to unmodulated, the axes for which it is used and the probe + travel speeds
; changed to match stock 1.19.2 firmware from 3DP
G31 P600 X39 Y190 Z3.10 ; set Z probe trigger value, offset and trigger height
; changed to match stock 1.19.2 firmware from 3DP
M557 X40:910 Y191:950 S58:50.6 ; define mesh grid

I know that using a type P6 probe in firmware 2.05 isn't preferred, but I've tried running the M558 P9 probe code generated by the firmware tool (and commented out above) and the BL Touch won't even respond to deploy/retract commands so I'm not sure what to do.

I've attached a wiring diagram (please excuse my MS Paint skills) and the full 1.19 and 2.05 config.g files below.

Previous 1.19 config.g.g

New 2.05 config.g.g

@Phaedrux Thanks. The DWC v1.20 in my second post was a mistake, that was my previous version. I'm on DWC 2.04 now, but good point, I'll upload the full 2.05 zip file in case I missed anything.

Everything seems to be working okay otherwise which is a surprise since I had to piece together what the original manufacturer did to get it set up by looking at the wiring and old .g files. 24V supply, 220V heated bed supply, self driven servos....way more complicated than the simple i3 style cartesian I setup previously. I'm really thankful for resources here and in the wiki. I wouldn't have been able to do this otherwise.

I should learn how to read better...I ignored the fallback procedures because I though they pertained to re-flashing if something went wrong, but they're actually alternate methods to get the firmware upload to work. I was able to solve the issue by using fallback procedure #1 in the wiki and directly moving files to the on board SD card. I'm now on 2.05 and web interface version 1.20 2.04, no issues.

RRF 1.19.2
Webcontrol 1.20
Duet2 Ethernet, board v1.04b with expansion board
Cartesian kinematics with external servo drives for X,Y and Z, and Duet powered extruders

I'm attempting to upgrade a 3DP Workbench from Duet firmware 1.19.2 to 2.05.

If I'm reading the instructions correctly, I should only be trying to update the Duet Ethernet firmware by itself first (not using the combined .zip file) and I need to rename the .bin file to "DuetEthernetFirmware.bin". I've done this but when I attempt to upload the renamed DuetEthernetFirmware.bin file the upload stops midway and will not proceed. I also see a note in the wiki saying that I should update iap4e.bin if upgrading to 1.21 or later from 1.20 or earlier, so I attempted this thinking it might get the main firmware file to upload properly but when I do so the web interface reports "Error" in the progress bar and the upload also fails.

I have no issues connecting to or running the machine from the web interface outside of trying to update the firmware so I'm relatively certain this isn't a network issue.

Any advice on how to proceed?