Topics created by Diamondback

@Diamondback You certainly call a lot of different macros in there. Stack overflows typically occur if the nesting becomes too deep. Can you please attach a USB terminal to your Duet, run M111 P3 S1, and capture the output you get when you try to change the filament? That should make it easier for us to identify the underlying cause.

No, i'm not using G92 during my print at all. It's being used for the homing process of the coupler axis once, but that's about it.

@chrishamm said in Custom Heater Colors:

@Diamondback Colors are defined here. At the moment you'd have to build a custom DWC version to change the colors but I'll probably make that configurable in v3.6.

That would be much appreciated! 🙂

@gloomyandy

=== Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.5.0-beta.4 (2023-06-08 23:41:30) running on Duet 3 MB6HC v1.02 or later (standalone mode) Board ID: 08DJM-9P63L-DJ3T0-6J1F4-3S06S-9A1V9 Used output buffers: 3 of 40 (40 max) === RTOS === Static ram: 155012 Dynamic ram: 133920 of which 0 recycled Never used RAM 27692, free system stack 117 words Tasks: NETWORK(1,ready,136.5%,165) ETHERNET(5,nWait,19.8%,115) ACCEL(6,nWait,0.0%,348) HEAT(3,nWait,6.3%,323) Move(4,nWait,187.8%,210) CanReceiv(6,nWait,10.3%,769) CanSender(5,nWait,1.8%,326) CanClock(7,delaying,1.7%,349) TMC(4,nWait,128.2%,59) MAIN(1,running,47.7%,137) IDLE(0,ready,0.4%,30), total 540.6% Owned mutexes: === Platform === Last reset 196:22:54 ago, cause: power up Last software reset at 2023-07-27 13:42, reason: User, Gcodes spinning, available RAM 27548, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x04 MCU temperature: min 20.8, current 44.6, max 48.0 Supply voltage: min 23.3, current 23.6, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.3, max 12.5, under voltage events: 0 Heap OK, handles allocated/used 495/415, heap memory allocated/used/recyclable 24576/24092/1072, gc cycles 90579 Events: 0 queued, 0 completed Driver 0: standstill, SG min 0, mspos 456, reads 20344, writes 403 timeouts 0 Driver 1: standstill, SG min 0, mspos 200, reads 20344, writes 403 timeouts 0 Driver 2: ok, SG min 0, mspos 382, reads 20340, writes 407 timeouts 0 Driver 3: ok, SG min 0, mspos 275, reads 20341, writes 407 timeouts 0 Driver 4: standstill, SG min 0, mspos 520, reads 20193, writes 555 timeouts 0 Driver 5: standstill, SG min 0, mspos 456, reads 20345, writes 403 timeouts 0 Date/time: 2023-08-08 15:06:55 Slowest loop: 221.89ms; fastest: 0.04ms === Storage === Free file entries: 13 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 3.2ms, write time 147.5ms, max retries 0 === Move === DMs created 125, segments created 29, maxWait 87145020ms, bed compensation in use: mesh, height map offset 0.000, ebfmin 0.00, ebfmax 0.00 next step interrupt due in 125 ticks, disabled === DDARing 0 === Scheduled moves 89768, completed 89743, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 5], CDDA state 3 === 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 Heater 0 is on, I-accum = 0.0 Heater 4 is on, I-accum = 0.0 === GCodes === Movement locks held by null, null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 3 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 doing "M150 R0 U0 B0 P0 S64 F0" in state(s) 0 0 0 0 0, running macro Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 File2 is doing "M0" in state(s) 0 0, running macro, sync state 1 Queue2 is idle in state(s) 0 Q0 segments left 1, axes/extruders owned 0x10000007 Queue 0 has 'M150 R0 U0 B0 P0 S64 F0' for move 89751 Queue 0 has 'M150 R0 U0 B0 P0 S64 F0' for move 89757 Queue 0 has 'M150 R0 U0 B0 P0 S64 F0' for move 89763 Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === Filament sensors === Extruder 0: no data received Extruder 1: no data received Extruder 2: no data received Extruder 3: no data received === CAN === Messages queued 9605379, received 14701227, lost 0, boc 0 Longest wait 2ms for reply type 6013, peak Tx sync delay 24761, free buffers 50 (min 48), ts 3534871/3534870/0 Tx timeouts 0,0,0,0,0,0 === Network === Slowest loop: 3684.59ms; fastest: 0.03ms Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 = Ethernet = Interface state: active Error counts: 0 0 0 1 0 0 Socket states: 5 5 2 2 2 0 0 0 = WiFi = Interface state: disabled Module is disabled Failed messages: pending 0, notready 0, noresp 0 Socket states: 0 0 0 0 0 0 0 0 === Multicast handler === Responder is inactive, messages received 0, responses 0

@Diamondback thanks! lets hope a pattern does not appear!

@Ethelred please start a new issue. That is a different issue to the one being discussed

@achrn said in Rotary axis/spinny thing with no limits:

I think motor steps are in a signed 32 bit variable

Correct (that's motor microsteps, not full steps). Bear in mind that absolute positions are stored as 32-bit floating point numbers, so accuracy will suffer when the number of microsteps doesn't fit in about 24 bits.

@chrishamm Alright, I will cut some names down in length then and see if I can make it work. As mentioned, at some point this issue should solve itself for me since I then can simply convert a lot of the x4 globals into an array and do some other cleanups.

Thank you 🙂

@dc42 perfect, thanks 🙂

@dc42 happy to report, no further resets over the day 🙂 Many thanks!

@dc42 This seems to fix it the memory leak 👍 Now it only resets after a while due to the issue mentioned here (same behavior as without using the local arrays all the time)
https://forum.duet3d.com/topic/31168/3-5b1-reset-reason-stuckinspinloop

@Diamondback not yet...

@dc42 Thanks for adding this in 3.5 rc2 🙂 Very useful 👍
(The sensor here is almost 1m away from the extruder, so in case the signal looks too noisy, that's why)
2023-12-27_00-38-25.png

cc @herrtschaefer

@T3P3Tony Thank you very much! 🙂

@Diamondback you are correct: the switch should be closed when filament is present.

@dc42 Good news 🙂 With 3.5rc2, all my sensors appear to work for now 🙂 They collect data that seems right, they change status when inserting filament etc.
I haven't tested yet what happens if they actually detect an issue, but so far so good. Will keep you posted if anything weird comes up. Many thanks 🙂

@dc42 Hmm, I wish I remebered which tool I printed the prints with issue with....
Two of my tools use extruders on a slave Mini 5 board while the other two tools are connected to the 6HC... Maybe it has to do with the extruders not being on the main board?

I just went back to older builds (specifically the one where you fixed the Mini 5 Slave OoM error) and I can see hints of the issue appearing again when I use one of the tools with an extruder on the Mini 5. It's not as bad as before, but maybe other things play a role.

I'll keep experimenting...

@dc42 After a few consecutive prints without resets, it still sits at 28076. So I guess this is fixed! Awesome work, thanks a lot! 🙂

@chrishamm Oh well, it happens 🙂 Not the first time, not the last time 😄

@dc42 awesome, will test soon! Thanks a lot! 🙂