I work with OP and am familiar with his situation. Let me see if I can clarify his ask. We already have the machine built with drivers and electronics in place. We are replacing the current azteeeg board with a duet wifi and we want to try and keep everything in place. In a perfect world, with our current configuration, we would modify a ribbon cable to use the duex5 for all of the fans, heaters, and thermistors, but break off step, dir, and en wires to power our external drivers for X, Y, and Z (to clarify, these wires will never reach the duex5). We would use the drivers on the Duet WiFi to power the 4 Nema 17 extruders and remap our axes in config.g.

The question: Will this break anything. We intend to use level shifters between the duet and our drivers.

I had a similar issue a while back. What kind of driver are you using? Is that driver set to have microstepping?

Im working on a printer that requires higher current than currently allowed with duet. Is it possible to order a board without drivers? Or could future builds come with step and dir headers for Z X Y E1 E2 drives like on smoothie?

I blew the x driver on my board. I remapped my axes and removed the old driver with a soldering iron. Everything worked fine until I updated to the new firmware and now I get spammed with

Error: Short-to-ground on drivers 0
Error: Over temperature shutdown on drivers 0

It still heats up and moves but that is kinda bothersome. Can I disable this?

A feature that automatically applies toolhead offsets. It sounds like G1 R2 will work if I update to t 1.19 beta. I will try that. Thanks

G1 R2 wont work for me as I have U axis controlling a servo that moves the nozzles out of the way. This feature would save me a lot of headaches.

Thanks for the response. I will update my firmware and see if that fixes things.

I am using a Duet Wifi on a custom built printer and I'm having trouble getting Gcode to execute as intended. I am using a fan channel to control a motor via a relay. This motor performs a mid print process that I cant really discuss but the motor needs to be ON while certain moves are being executed, then turned OFF. What is actually happening is that the motor turns on earlier than intended and cuts off earlier as well. I believe this has something to do with the way the buffer code is executed. I have tried adding pauses before and after the M106 commands and this helped a little but it is still not working properly. Is there a way to get the M106 command to execute in the correct sequence?

Please count me in as well.