Posts made by brendon

@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?

@dc42 Is it not worth downgrading the firmware to see if it works on any other versions?

@dc42 +12v between the 2 output pins.

@dc42 Technically it has 'never worked'. I wired up the LED strips when I assembled the machine, but just got around to connecting them this week. How far back in firmware releases should I try?

I have the out 4-6 jumper between V_OUTLC1 + 12v and the out 7 - 9 jumper between V_FUSED + V__OUTLC2. Moving the out 4-6 jumper to V_FUSED + V_OUTLC1 has no effect.

Moving the out 7-9 jumper between V_OUTLC2 + 12v causes out9 to always be +12v.

@dc42 Yes. If you remove the SD card (I am not using an SBC), the LEDs are enabled at power on.

@jay_s_uk Thanks for checking in. I had seen this mentioned in the documents but didn't see anything mentioned about having to disable it to use out9.

@dc42 No error messages. Is it possible that out9 is shared with something else by default and needs to be disabled?

The issue appears to go back to at least RRF 3.2.2

I am looking to use out8 and out9 for LED strips. I have both enabled identically, but I am unable to control the level of (or turn off) out9 (it is always on, even at boot). Out8 works as expected.

I am running RRF3.4-beta5

Any help is greatly appreciated!!!

Here is the relevant config.g

; lights, right
M950 F3 C"out8"
M106 P3 S0

; lights, left
M950 F4 C"out9"
M106 P4 S0

Control of brightness:

; lights off
M106 P3 S0
M106 P4 S0

; lights on
M106 P3 S255
M106 P4 S255

Here is the entire config.g file

; Configuration file for Duet 3 (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Thu Oct 08 2020 13:25:03 GMT-0400 (Eastern Daylight Time)

; General preferences
G90                                          ; send absolute coordinates...
M83                                          ; ...but relative extruder moves
M550 P"CustomCore"                           ; set printer name
M669 K1                                      ; select CoreXY mode

; Network
M552 P0.0.0.0 S1                             ; enable network and acquire dynamic address via DHCP
M586 P0 S1                                   ; enable HTTP
M586 P1 S0                                   ; disable FTP
M586 P2 S0                                   ; disable Telnet

; Drives
M569 P0.0 S1                                 ; physical drive 0.0 goes forwards
M569 P0.1 S1                                 ; physical drive 0.1 goes forwards
M569 P0.2 S1                                 ; physical drive 0.2 goes forwards
M569 P0.3 S1                                 ; physical drive 0.3 goes forwards
M569 P0.4 S1                                 ; physical drive 0.4 goes forwards
M569 P0.5 S1                                 ; physical drive 0.5 goes forwards

M584 X0.1 Y0.2 Z0.5:0.3:0.4 E20.0            ; set drive mapping
M350 X16 Y16 Z16:16:16 E16 I1                ; configure microstepping with interpolation
M92 X160 Y160 Z3200:3200:3200 E398           ; set steps per mm
M566 X700 Y700 Z180:180:180 E300             ; set maximum instantaneous speed changes (mm/min)
M203 X60000 Y60000 Z600:600:600 E5000        ; set maximum speeds (mm/min)
M201 X2500 Y2500 Z200:200:200 E5000          ; set accelerations (mm/s^2)
M906 X1600 Y1600 Z1600:1600:1600 E1500 I30   ; set motor currents (mA) and motor idle factor in per cent
M84 S30                                      ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 S1                             ; set axis minima
M208 X320 Y300 Z300 S0                       ; set axis maxima

; Endstops
M574 X1 S3                                   ; configure sensorless homing for low end of x
M574 Y2 S3                                   ; configure sensorless homing for high end of Y
M574 Z1 S2; P"io3.in"                        ; configure Z-probe endstop for low end on Z
M915 X Y S5 R0 F0

; Z-Probe
M558 P9 C"20.io0.in" H5 F360 T20000          ; Set Z probe type to switch, the axes for which it is used and the dive height + speeds
M950 S0 C"20.io0.out"                        ; create servo pin 0 for BLTouch
G31 P500 X0 Y-43 Z1.76                       ; set Z probe trigger value, offset and trigger height, -z separates from bed, +z brings nozzle tip closer
M557 X38:295 Y-3:252 P5                      ; define mesh grid

; leadscrew locations
M671 X-18:354:169 Y77:77:343 S3

; Heaters
M308 S0 P"temp0" Y"thermistor" T100000 B4138 ; configure sensor 0 as thermistor on pin temp0
M950 H0 C"out0" T0                           ; create bed heater output on out0 and map it to sensor 0
M140 H0                                      ; map heated bed to heater 0
M143 H0 S150                                 ; set temperature limit for heater 0 to 150C
M308 S1 P"20.temp0" Y"pt1000" L-25           ; configure sensor 1 as PT1000 on pin temp1
M950 H1 C"20.out0" T1                        ; create nozzle heater output on out1 and map it to sensor 1
M307 H1 A407.5 C228.4 D2.9
M143 H1 S400

; Fans
M950 F0 C"out3" Q500                         ; create fan 0 on pin out3 and set its frequency
M106 P0 S0 H-1                               ; set fan 0 value. Thermostatic control is turned off
M950 F1 C"20.out1"                           ; create fan 1 on pin out4 and set its frequency
M106 P1 S1 H1 T80                            ; set fan 1 value. Thermostatic control is turned on

; part cooling ssr
M950 F2 C"out7"
M106 P2 S0

; lights, right
M950 F3 C"out8"
M106 P3 S0

; lights, left
M950 F4 C"out9"
M106 P4 S0

; Tools
M563 P0 D0 H1 F2                             ; define tool 0
G10 P0 X0 Y0 Z0                              ; set tool 0 axis offsets
G10 P0 R0 S0                                 ; set initial tool 0 active and standby temperatures to 0C

; Custom settings are not defined

@dc42 Thanks for the update, I'll keep an eye on the release notes!