Upgrading all of the firmware/softwares resolved the issue. Thank you all for the help!

@dc42 Sorry for the brevity in my previous response. Yes, out9 is still turned on and enabled after the board was erased but before the firmware was flashed.

@dc42 @T3P3Tony

The new board arrived and the Out channels are now properly controlling the LED strips. Thank you for helping me sort out my issue. The offending hardware is boxed up and will be arriving to you shortly. Thanks again!!!

@phaedrux I appreciate you checking back in. I apologize for being short with you; there's a place for levity when not counter-productive, but it's not helpful when the problem being reported could be construed as a possible safety issue. I was probably too brief in acknowledging I understood active-cooling was required, I was in the process of mounting a fan when I made the post. Since the fan has been mounted the board is behaving as reliably as expected.

My concern is that it's possible that there is no rate-limiting on the warnings being issued to the console. From what I saw, this only affected DWC and the machine seemed to be behaving/continuing it's expected operations. As a software engineer, it's not a huge leap to imagine that if more drivers started emitting incessant warnings that the actual machine performance could be affected. It's also possible that the loss of DWC control was not due to the volume of warnings, but some other gray area WRT thermal accumulation. I can only speculate as the last thing I saw in DWC before it disconnected was a flood of warnings.

Obviously if there was an actual risk to myself or the machine the power could be disconnected, I just didn't want to scrap hours of experiments if it could safely be avoided.

@infiniteloop I know that the board requires active cooling in the position that it's mounted on this machine. I have already mounted a fan and that has resolved the warnings.

My issue is that the board can get into a state where the machine is still moving/operating, but cannot be paused/stopped since DWC is unable to connect, possibly due to the high rate of errors that are being sent to the console.

@engikeneer I agree that it's logical that the driver reports the warnings to the console. My issue is that when the board is in that state, you cannot connect to DWC which means you cannot pause or stop the machine.

@owend Thanks for the tip! I'll look into implementing driver-error.g and driver-warning.g on my machine.

I'll have to run a test with driver-warning.g implemented to see if it suppresses the flood of messages to the console. It still seems awkward, as the default, that control of the machine is lost when the MCU was only reporting ~60c.

- RRF 3.3 reports driver warnings (e.g. over temperature, or phase disconnected) to the user. RRF 3.4 attempts to run driver_warning.g. If that file is not found then it just notifies the user via the console.

@phaedrux This is an inane, embarrassing response to receive from a "moderator". I clearly mentioned that I was intending to better cool the board. Thank you for wasting both of our time.

In the meanwhile, there should not exist a thermal scenario where the board is warm enough to throw warnings but able to continue moving/operating if it cannot safely be controlled via DWC. Once the board enters this state, the single web browser connected to DWC disconnects, meaning there is no way to pause/stop stepper motion/spindle/etc without killing the power to the board. Perhaps it's possible that the wireless portion of the Duet2 becomes too warm to operate, but the plethora of warnings in the console immediately before it disconnects seems to imply the volume of messages is the issue.

The machine I am working on needs improved cooling for the MCU/stepper drivers. In the meanwhile the volume of the over-temperature-warnings being written to the console seem to flood DWC such that you cannot connect or control the machine. It is impossible to connect to the machine until things cool down. Is there a way to limit these messages?

Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.4.0 (2022-03-15)
Duet WiFi Server Version: 1.26

@dc42 @T3P3Tony

The new board arrived and the Out channels are now properly controlling the LED strips. Thank you for helping me sort out my issue. The offending hardware is boxed up and will be arriving to you shortly. Thanks again!!!

@dc42 Sorry for the brevity in my previous response. Yes, out9 is still turned on and enabled after the board was erased but before the firmware was flashed.

@t3p3tony @dc42 Erasing and reflashing with Bossa did not resolve the issue. I will reach out to warranty@duet3d.com. I appreciate the assistance!

@t3p3tony If I erase it, will I have to use Bossa to re-write firmware?