Posts made by tomasf

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

I've been using my delta printer powered by a Duet 3 Mini 5+ for a year and a half. I made two successful prints yesterday, but today it suddenly wouldn't work.

Homing didn't work – motors didn't move and I eventually got "Error: G0/G1: insufficient axes homed". I tried rebooting things and upgrading the firmware, but nothing seemed to help. Then I noticed that all drivers in M122 were listed as "not present", which doesn't seem good.

I browsed this forum for a while trying to find similar issues when I heard the typical sound of energized stepper motors. After a few seconds, one of the motors seemed to move slightly spontaneously. M122 now reported drivers 1, 2 and 3 as "ok". After a short while, drivers 0 and 4 were now "ok" and 1–3 were "standstill".

The motors were now making louder noises than usual. I tried turning ATX power off and on, and I was now back to all drivers being "not present".

I haven't made any changes to my electronics or anything for months, so it was surprising to see this happen so suddenly. I don't see anything indicating failure on the board; no little burn marks on chip packages or anything like that.

Any ideas about what could be wrong? Anything I could try for troubleshooting purposes? Has my board destroyed itself? I've attached three M122 responses with the different driver states.

Thank you!

M122-nonepresent.txt
M122-threepresent.txt
M122-fivepresent.txt

I've always had unstable Wi-Fi with Duet, ever since my first Duet Wifi, regardless of where I put the printer relative to the router and with different channels, router brands, etc. Then I switched to using an SBC and let the Raspberry Pi handle the Wi-Fi connection and it's been rock solid ever since.

@garyd9 Oops. Yes, you're right.

@c310 The second part of the S parameter is supposed to be 255 minus the value. Try M672 S131:124.

I'm trying to setup my camera in DWC, but I'm having some issues.

The camera feed is a multipart/x-mixed-replace stream ("Motion JPEG"), so it doesn't need to be reloaded. I seem to remember earlier versions of DWC accepting 0 as the update interval to accomplish this, but that doesn't seem to work in 3.2.2. A zero value isn't accepted and saved, and reloading the page brings back the old value. I've tried to enter a really large interval, which it does seem to accept, but for some reason, it starts reloading every five seconds after a while anyway.

Also, the webcam URL I enter always seems to have a random (?) number appended at the end. With the "Do not append extra HTTP qualifier when reloading images" option turned off, it's a query parameter. Turned on, it's appended with an underscore. Can I turn this off completely? I just want to use the exact URL I entered.

Thanks!

@dc42 The pulldown resistor solved it. Brilliant, thank you.

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!

I had the same problem and solved it with a simple 7400 NAND gate chip: https://forum.duet3d.com/topic/412/inverting-ps_on

Hey, if I pass a T value to M453, it actually works now. That's nice, but not exactly obvious, especially since the T parameter isn't even documented (afaik).

Oh well, I'm happy for now. Thanks for your help!

@dc42 said in Missing spindles in M408 response?:

Please can you upgrade to 2.03beta2 and try again.

@dc42 Okay, done. It's still the same. PWM output works, but no "spindles" entry in M403 response.

{"status":"O","coords":{"axesHomed":[0,0,0],"xyz":[0.000,0.000,0.000],"machine":[0.000,0.000,0.000],"extr":[0.0]},"speeds":{"requested":0.0,"top":0.0},"currentTool":-1,"params":{"atxPower":0,"fanPercent":[0,100,0,0,0,0,0,0,0],"speedFactor":100.0,"extrFactors":[100.0],"babystep":0.000},"sensors":{"probeValue":205,"fanRPM":0},"temps":{"current":[2000.0,2000.0,2000.0,2000.0,2000.0,2000.0,2000.0,2000.0],"state":[0,0,0,0,0,0,0,0],"tools":{"active":[[0.0]],"standby":[[0.0]]},"extra":[{"name":"*MCU","temp":41.2}]},"time":196.0}