Sorry to keep replying to my own posts here, but I have made some more progress, and now have it working completely (as a stand alone trigger anyway). Im just using a microswitch to detect filament so OP your setup might vary a bit.

M950 J12 C"io8.in"
M581 P12 T1 S0 C1
M581 P12 T3 S1 C0

So this setup detects running out of filament only when printing, but inserting filament anytime. I made a file, trigger3.g, which runs whenever you insert filament, acts as a filament load script. Filament runs out, print pauses runs pause.g, filament is inserted, it runs trigger3.g, then I click "resume print" and it starts back up. Works like a champ. Still not sure how to use M591, but this is working.

@Danal said in Firmware update woes. Duet3:

We know that you have RC7 on the firmware. We don't know, at this moment, what DSF you have.

Ohhhh. Headslap. Alright standby, working on it now. Yeah I know the front panel deal is weird. Its a long and strange story, but we have some printers that were purchased that already have front panels that underperformed in their shipped state, and a safety requirement that they can be controlled physically. Ill update the pi and report back in 5.

@dc42
Ohhhh, yep that makes all the sense in the world. Many thanks for the help. I just got off the phone with a company we work with that is producing printers, and they are looking to build their next line around the Duet 3. I passed how impressed with are with it, and how amazing the customer support is. Thanks so much for all the help, you guys rock.

@dc42
I was hoping to circle back with you on this, primarily on the inclusion of M915 in the rehome.g file. I dont have a M915 command in my rehome.g only a G28 XY. What is required in rehome?

@bearer thanks! Found it.

Im not sure the best way to show it other than an image. It certainly seems to work fine without sensorless homing for me, but I actually found the guide after I started playing with it, and was afraid I was doing something wrong.

Hi all, is there a way to send gcode to multiple printers at once, or to send gcode to a specific IP via DWC? I have 4 printers (soon to be 6) running Duet3 boards. At the beginning of the day it would be great to be able to have them all home, preheat, and create a height map. Is this possible?

BLUF/TLDR: What all needs to be in rehome.g and can stall detection can be used without sensorless homing. Seems to be working, but I want to make sure Im doing things correctly.

Hi all, I was hoping to get a little clarification on stall detection and some of the information in the guide. Im using a Duet 3 on a core XY printer, and I have read through all the documentation, and know its a bit more difficult to configure reliably on XY.

I added to the last line of my config:

M915 X Y S2 R3		

I wrote a test gcode file that just moved the head around, and I stopped it with my hand and it seems to work great (so maybe I should just leave it alone). My question is, in the Dozuki, it states "You must enable senorless homing if you want to use stall detection". Is this still true? I have a BLTouch, and Im using end stop switches and everything seems to be working as it should. In my rehome.g I only have:

M400
M118 S"CRASH DETECTED"
G28 X Y
M400

Does resume.g run when rehome.g is triggered? Is there more I need to add? I also read:
"Step 2: Enable M915 in your slicer

This step requires the same M915 command that is in your rehome.g file be at the END of your STARTING gcode script in your slicer of choice. Place it at the end of your start script gcode commands.

Step 3: Include M915 X Y S3 R0 F0 at the BEGINNING of your ENDING gcode script in slicer of choice"

I dont have an M915 command in my rehome.g. It seems like what is being implied is that stall detection should only be enabled (with an consequent action) during printing. If so, thats easy enough, Im just confused on what all needs to be in rehome.g and if stall detection can be used without sensorless homing.

Using stand alone Duet 3, MB6HC 3.01-RC10, Duet Web Control 2.1.5. I think youre right. Went I went line by line, M558 is where it changed back to 0.7.

@Phaedrux
It sure does. It works like an absolute champ. Thank you so much.

@Phaedrux
Woah. This is a treasure trove of information. So many new uses, that solve a number of things I have been working on. The M913 is exactly what I was looking for, thats brilliant. Im starting to understand part of my learning problem, I go to the zuki, look for the command and immediately scroll to the applicable firmware, not realizing that often only changes are listed. M558 for example, I had no idea feedrate was supported. Headslap. I used your changes, and it works perfectly thank you so much!

One I dont fully understand is the P flag for G31. If I half understand, it sets the threshold for the signal for , in my case, the BLTOUCH. How is this value determined?

Phaedrux, and everyone here, you have all been so helpful, and it really is appreciated. This seems to be a really amazing community, and thank you for taking the time.

Okay, so I went line by line to see when the z-trigger height changed. In my latest config its set to 2.8
G31 reports the same. When Homeall.g runs:

M558 P9 C"io7.in" H5 F600 T5000 

G31 reports 0.7.
Thats when it is changing but I dont understand why. Unless re-declaring the pin without defining the mesh defaults to 0.7? I suppose I could just define the mesh 3 times?