@KnyteTech looks good, but I suggest you use P1 instead of S1 in the M950 command.

Sorry for the late update I ran into some other issues I needed to take care of.

So it looks like I got this working after I fixed a few issues. I managed to print a temp tower without issue, maybe I'll have problems in the future with other prints.

Installed a mount close by the extruder (around 1" of distance between the sprite pro extruder Removed my filament-error.g (it was trying to pause then run filament-error.g) Used the BTT recomended g-code but adjusted E value to 22 Changed my retraction speed to 60mm/s

Here is the g-code I'm using

; Filament Monitor (Filament Runout Sensor, Big Tree Tech - Smart Filament Sensor V2) M591 D0 P7 C"io0.in" L2.88 R75:125 S2 E22

@AJ-Quick From where can I get this board?

@jay_s_uk Okay, thank you for you help 🙂

@Muhammed the PS_ON pin could be used for this purpose, but you must connect a flyback diode (the right way round!) in parallel with the relay coil, to protect the output from the coil back emf when you turn the relay off.

Alternatively, use a relay module instead of a bare a relay, then you should be able to drive from one of the pins on the expansion header.

@infiniteloop Thank you so much for your reply. This will give me a push forward.

@Ryosuke-Saito In my experience with other brushless step/dir interfaces it is the other way round:
A stepper with 200/400 polepairs versus a BLDC motor with eg. 10 or 15 PP needs way more pulses per revolution.
The good thing about FOC is, you can fake a much higher resolution than there is. The microstepping works here, too.
So I configured my gimbal motor drivers the same way as the steppers and they work flawlessly as extruder drive.

@ELAD . Is it working properly? I am designing a laser cutter with the ODRIVEs. Please let me know

@dc42
Hi, that did the Trick.
Thanks fo the wise answer.

@RandyL00123 you read the current value from the object model and adjust with G31 by doing something like G31 K0 P{sensors.probes[0].value[0] + 50} (untested, needs validation, maybe add 100 instead of 50) with added safeguards should the idle value already be something high (above 850 or so) to avoid crashing with a triggered sensor

@Phaedrux I fix the fan and now it's working. Thank

@Yukikaze I confirm that this was not working in rc3. I have corrected the 3.5 source code and tested the fix. Thank you for reporting it.

Just confirming endstops work fine on 3.3V. I've wired the fans to a 12V fan socket. All working so far...

@Cognirit we've also integrated the scanning Z probe into our new Revo Roto Tool Board.

@Paddy That should be okay. For a list of Duet 2 WiFi/Ethernet pins and functions, see https://docs.duet3d.com/Duet3D_hardware/Duet_2_family/Duet_2_WiFi_Ethernet_Hardware_Overview#inputoutput

See also this thread where the Orbiter filament sensor is discussed: https://forum.duet3d.com/topic/34132/orbiter-filament-sensor-setup

Ian

@droftarts I need some brainstorming here.
I thought about it a lot and the following scenario is working while the printer is idle:

idle && no filament -> press button to start loading filament
idle && filament present -> press button to start unloading filament

I think this is clear so far and working in the macro.
However there are two tricky situations need to be covered:

Print paused manually for filament change so filament is present but status is paused Filament runs out and print is paused

For case 1 we can use the original macro as filament is present, but I'm not sure how I could handle when print is paused with error. I have looked up all the available statuses and printer status is same when manually paused and when paused with error. I'm wondering what other parameter we could use this case to determine if the print was halted by error or manually.

@ageis https://www.antclabs.com/about