3.01RC11 on WiFi + Duex5 M950 Fan on Duex causes reboot loop.

UticaTechClub

@dc42
Here is something new... I don't know why I never tried it before.
I disconnected the the Duex bus cable and it no longer reboots. I feel bad that I never tried it before
Now, I could try few other things.

UticaTechClub

@dc42
@T3P3Tony
Duex board hosts five inputs (E2_STOP ... E6_STOP), one per extruder.
Our configuration hosts five tools in total, and used E0_STOP - E1_STOP on Duet WIfi and E2_STOP - E4_STOP on Duex5. Those ports have standard RepRep optical limit switches connected to them. Those limit switches monitor tools parking states - very useful application.

When tool is parked, it's 3D printed housing has a little tab which engages the optical limit switch. Depending on translucency of the material used for tool housing, the little tab may not be completely opaque, thus causing some light to travel through it, putting optical limit switch into the state other then ON or OFF. When you power up 3D printer, it will suffer continuous reboots. Please note (#1) that E0_STOP - E1_STOP ports are not susceptible to this, that is why, two tools configuration always worked. Note #2, is that continuous reboots will be only happening when FANs are configured using M950 F3 C"duex.fan3" Q500, M950 F4 C"duex.fan4" Q500, M950 F5 C"duex.fan5" Q500, M950 F6 C"duex.fan6" Q500, M950 F7 C"duex.fan7" Q500 gcodes.

I am planning to check the output voltage of such half-lit optical switch with the scope, and perhaps simulate the condition using the voltage source instead of the optical limit switch.

CONCLUSION:
There must be a slight difference in schematics of how E0_STOP - E1_STOP wired compared to E2_STOP ... E6_STOP on Duex5.
To prevent such condition, data feed must not be ambiguous.

A am very sorry, for taking your precious time with this, but exceedingly happy that the issue is now resolved.
Thank you guys!!!

dc42

Thanks for the update.

Do the outputs for fans 3 to 7 run close to the wires for the optical endstops connected to the DueX?

There is indeed a difference between endstops connected to the Duet and endstops connected to the DueX. Endstops connected to the Duet are polled during homing moves to see when they trigger. Endstops connected to the DueX generate an interrupt to the Duet, which then has to read them via the I2C connection. There is a mechanism to prevent the DueX interrupts causing excessive overload on the Duet main processor; but it sounds as though this mechanism isn't working as well as necessary.

UticaTechClub

@dc42
"Do the outputs for fans 3 to 7 run close to the wires for the optical endstops connected to the DueX"
Yes
But, I always look back at firmware 2 running on the same HW without interference issues.

UticaTechClub

@dc42
While on this topic, is there a way to query e0_stop - e1_stop and duex.e2stop - duex.e6stop inputs through object model?
I want to use them in gcode meta commands expressions.

Thank you!

dc42

@UticaTechClub said in 3.01RC11 on WiFi + Duex5 M950 Fan on Duex causes reboot loop.:

@dc42
"Do the outputs for fans 3 to 7 run close to the wires for the optical endstops connected to the DueX"
Yes
But, I always look back at firmware 2 running on the same HW without interference issues.

Older versions of RRF2 didn't actively keep the DueX endstop input status up to date. This led to increased endstop latency. New versions of RRF2 and all versions of RRF3 use a separate task to keep the DueX status up to date, by responding to the interrupt from the DueX immediately.