Use MCU Temp as Trigger for Case FAN
-
Hello.
I copied this code snippet from the wiki and adapted it to my connections.
Unfortunately, it doesn't work as intended. The fans are always on (Temp in DWC is 36,9 °C).
But they're supposed to only start at 40°C.M308 S10 Y"mcu-temp" A"MCU" ; configure sensor 10 as on-chip MCU temperature sensor M950 F8 C"2.out3" Q500 ; create fan 8 on pin 2.out3 on MB3HC Board #2 and set its frequency M106 P8 H10 T40:70 ; set fan 2 value
-
@CrazyCreator you can't have a temperature controlled fan one one board using the temperature from another board
-
@jay_s_uk
Too bad... I guess I'll have to wire it differently.
Or will that be an update in one of the next versions? -
-
I scanned the reference but I don't see the relevant limitation.
I see where heaters and their associated temp sensor must be on the same board.
Frederick
-
@CrazyCreator What version of RRF are you using? Send M122 and post the response, please.
I can confirm having a temperature sensor on the mainboard, and connecting a fan on a toolboard, makes the fan come on all the time, in RRF 3.6.0-rc1. I sent:
M308 S0 P"temp0" Y"thermistor" T100000 B3988 M950 F0 C"121.out1" M106 P0 S0 H0 T100
Fan came on despite thermistor reporting 20C.
Ian
-
@droftarts said in Use MCU Temp as Trigger for Case FAN:
@CrazyCreator What version of RRF are you using? Send M122 and post the response, please.
30.3.2025, 13:40:22 M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.5.4 (2024-11-24 10:47:10) running on Duet 3 MB6HC v1.01 (SBC mode) Board ID: 08DJM-956BA-NA3TN-6JTDG-3S86J-TUB2T Used output buffers: 1 of 40 (35 max) === RTOS === Static ram: 155464 Dynamic ram: 93116 of which 1864 recycled Never used RAM 95548, free system stack 202 words Tasks: SBC(2,ready,0.9%,805) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,0.0%,335) CanReceiv(6,nWait 1,0.1%,796) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,9.1%,53) MAIN(2,running,89.6%,101) IDLE(0,ready,0.2%,29), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:07:52 ago, cause: power up Last software reset at 2025-03-29 17:03, reason: User, Platform spinning, available RAM 95476, slot 1 Software reset code 0x6000 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 MCU temperature: min 24.7, current 40.9, max 41.0 Supply voltage: min 23.7, current 23.8, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0 Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Events: 0 queued, 0 completed Driver 0: standstill, SG min n/a, mspos 8, reads 59622, writes 15 timeouts 0 Driver 1: standstill, SG min n/a, mspos 8, reads 59622, writes 15 timeouts 0 Driver 2: standstill, SG min n/a, mspos 8, reads 59621, writes 17 timeouts 0 Driver 3: standstill, SG min n/a, mspos 8, reads 59621, writes 17 timeouts 0 Driver 4: standstill, SG min n/a, mspos 8, reads 59621, writes 17 timeouts 0 Driver 5: standstill, SG min n/a, mspos 8, reads 59621, writes 17 timeouts 0 Date/time: 2025-03-30 13:40:22 Slowest loop: 2.74ms; fastest: 0.04ms === Storage === Free file entries: 20 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00 no step interrupt scheduled Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0 === DDARing 0 === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === DDARing 1 === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 === GCodes === Movement locks held by null, null HTTP* is doing "M122" in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger* is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 File2 is idle in state(s) 0 Queue2 is idle in state(s) 0 Q0 segments left 0, axes/extruders owned 0x0000000 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === CAN === Messages queued 4117, received 18253, lost 0, errs 0, boc 0 Longest wait 1ms for reply type 6042, peak Tx sync delay 6, free buffers 50 (min 49), ts 2363/2362/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 16851/16851 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x24cfc Buffer RX/TX: 0/0-0, open files: 0 === Duet Control Server === Duet Control Server version 3.5.4 (2024-11-25 17:32:26, 64-bit) HTTP+Executed: > Executing M122 Code buffer space: 4096 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 0.23, max time between full transfers: 184.7ms, max pin wait times: 44.2ms/11.7ms Codes per second: 0.00 Maximum length of RX/TX data transfers: 4805/1176
-
@CrazyCreator thanks for reporting this, it's a bug. Expansion fans can't be controlled by sensors on the main board. This will be fixed in 3.6.0-rc.2.