I just upgraded from Duet Wifi with RRF 2 to Duet 3 mini 5+ with RRF 3.2.2 and SBC. It's an awesome system, and I especially like the object model. I have a few questions about ATX power:

1. On Duet Wifi, PS_ON was off (high) by default, so the board started with power off. On the 3mini, it seems to be on by default (low)? If I put an M81 into config.g, the power is briefly on and then turns off.
   I'm using a pull-up resistor to make sure that a floating state is interpreted as off, so that shouldn't be the problem. Am I doing something wrong or is this the intended behavior?

2. The state.atxPower entry in the object model seems to always be set to false, even when power has been turned on. The web UI reflects this; if I turn on power and reload the page, the switch is shown as off again. Is this a bug or something I've misconfigured?

Thanks!

When starting a print, I have often already homed the printer (as in the printer knowing its current coordinates), but not always. If I include a G28 command in the start G-code, printing always works, but often homes when it's not strictly needed. If I omit the G28, the printer might not already be homed, and if so the print fails. What I'm looking for is a way to home the printer only if it isn't already homed. Is there a way? If not, how about a G28 parameter for this? Any other ideas?

@T3P3Tony Thank you for that info!

I tried to get good photos of the area, but the lighting isn't ideal and U9 is really tiny.

I did however spray some some canned air around the area and the main processor as well as dab some blue tack around to catch debris. I'm not yet sure if that actually helped or if it's just a temporary fluke, but the steppers now work fine, the drivers report OK with no read/write errors.

I'm now successfully printing! Let's hope it continues working. Thank you for the help!

@Phaedrux I put it at five, but it seems to still be happening.

@dc42 Safari on macOS 14. I have not seen it happen with Chrome.

@T3P3Tony said in No more free sessions:

@tomasf how many different clients are you using to connect to the machine?

One. Just a single browser tab.

I'm running RRF 3.5, WiFi server 2.1.0 and DWC 3.5.1 on my Duet 2 WiFi and the connection keeps dropping and I get a red message saying "Failed to maintain connection to foo.local" and "No more free sessions". Then a password prompt pops up. If I reload the web page, it works for a few seconds or minutes, but then it happens again. Has anyone else seen this?

@Phaedrux It's the cable that came with the accelerometer.

Here's M122 after a reset if that could help:

=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.4.6 (2023-07-21 14:09:13) running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: MPKT6-F396U-D65J0-40KM8-3A03Z-R0UUN
Used output buffers: 1 of 40 (12 max)
=== RTOS ===
Static ram: 103712
Dynamic ram: 99580 of which 24 recycled
Never used RAM 38396, free system stack 206 words
Tasks: ACCEL(notifyWait,0.0%,346) SBC(ready,1.3%,434) HEAT(notifyWait,0.0%,358) Move(notifyWait,0.0%,363) CanReceiv(notifyWait,0.0%,941) CanSender(notifyWait,0.0%,335) CanClock(delaying,0.0%,342) TMC(notifyWait,0.0%,124) MAIN(running,97.4%,557) IDLE(ready,0.5%,30) AIN(delaying,0.8%,273), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:54 ago, cause: software
Last software reset at 2023-10-12 17:23, reason: HeatTaskStuck, GCodes spinning, available RAM 38252, slot 1
Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0000080f BFAR 0xe000ed38 SP 0x200134b0 Task ACCE Freestk 4294936825 ok
Stack: 2001948c 20012e5c 200014e8 e000e000 000000a5 00091d55 000905a6 6100f000 00000001 e000e000 00091d55 20019074 000000c8 20019088 0008ac65 bd0ae633 00000005 3e638e37 20019074 00000005 00000006 200135a0 0008ae6d 20019074 20023ad8 20023a50 00027ac6
Error status: 0x00
MCU revision 3, ADC conversions started 54608, completed 54608, timed out 0, errs 0
Step timer max interval 1489
MCU temperature: min 28.8, current 29.1, max 29.8
Supply voltage: min 1.3, current 1.3, max 1.4, under voltage events: 0, over voltage events: 0, power good: no
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: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 1: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 2: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 3: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 4: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 5: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 6: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2023-10-12 17:24:35
Cache data hit count 129047879
Slowest loop: 3.63ms; fastest: 0.08ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
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, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by 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
Code queue is empty
=== CAN ===
Messages queued 489, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 18), ts 273/0/0
Tx timeouts 0,0,272,0,0,215 last cancelled message type 4514 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 11189/2147
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x0f178
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.6
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 33.05, max time between full transfers: 95.2ms, max pin wait times: 34.0ms/2.5ms
Codes per second: 0.49
Maximum length of RX/TX data transfers: 3716/960

I tried downgrading to RRF 3.4.6 to see if a stable version improved things, but it didn't help.

I just installed the Duet3D accelerometer board, connected it to my Mini 5 and set it up with
M955 P0 I64 C"spi.cs2+spi.cs1". So far so good, but when I try to Record Motion Profile, it moves to the correct Z height, stops, and after a couple of seconds, the board resets and I get Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin) followed by Connection to Duet established and Warning: SPI connection has been reset.

The very first time I tried it, I did get results back (but with The selected motion profile contains overflows. It may not be accurate.), but every time since then, I get the reset.

SBC mode. RRF 3.5.0-rc.1.
Any ideas?

@T3P3Tony Thank you for that info!

I tried to get good photos of the area, but the lighting isn't ideal and U9 is really tiny.

I did however spray some some canned air around the area and the main processor as well as dab some blue tack around to catch debris. I'm not yet sure if that actually helped or if it's just a temporary fluke, but the steppers now work fine, the drivers report OK with no read/write errors.

I'm now successfully printing! Let's hope it continues working. Thank you for the help!

@jay_s_uk Good idea! Both fuses seem fine, though. Near zero resistance.