@dc42 If that's the case I will put all my duet printers into a self extinguishing cabinet right away. From my understanding this would mean a heater that might be at full power with no temperature rise will not trigger a heater fault?
The end is truncated because the printer is still on 3.4.6 where the maximum length of the string is limited and needs to be passe don to RepetierServer.
as discussed in https://forum.duet3d.com/topic/37009/parameters-on-toolchange I would love to see the option to pass self defined parameters into the tool change macros. Specifically I'd like to easily control weather a wipe and/or purge is called while changing tools.
@dc42 I was hoping there would already be a way to do so. But thanks! I will create one.
@droftarts Thanks!
It's an option yes, but quite a complicated one. If I have i.e. the purge option turned on for a print, but while preparing everything call the purge1 macro it will purge once because of the tool change and once because of the macro call. Not really elegant. Changing the global variable before calling the macro would be possible, but also not really elegant as there are quite a few occasions this would need to be done and another variable to store the state to switch back to afterwards would be needed.
Any other ideas?
Never mind the error message and the fact that it is cut, but can someone please explain where a negative expected temperature rise is coming from?
Does duet monitor the falling temperature if the bed is i.e. at 100°C and is then set to 60°C?
Bed heater with "normal" PID values from an automatic tuning and firmware 3.4.6
Hello everyone,
I'm trying to optimize the tool change and would like to make calling the clean and/or purge macros optional.
For the macros themselves this is easy to do with a parameter in the M98 P"0:/sys/purge0.g" call.
But for the tool change called by T0 / T1 I did not manage to pass a parameter. Is there a way I am not seeing?
thanks for any hints and/or ideas.
@dc42 any chance this is not just 3.5.0 and delta related?
We've one printer (Cartesian / IDEX) that's somewhat randomly (but mostly) also producing leaning prints.
For a long time we thought it is ClosedLoop or Hardware related, but running normal steppers etc. now.
Happens both with 3.4.6 and 3.5.1 and always in X-direction.
Kind of sure it's not hardware related by know, but somewhat special setup by now due to all the tests we did.
Let me know if you need any information, or want me to move it to a new thread. Or maybe it's the same error not jet fixed for a different kinematic?
FYI had something similar happen this night on a machine running just closed loop motors.
Just installed the RC2+ and will see if it happens again.
Already sent this to @dc42 directly as well.
@dc42 thanks for the quick reply! The reason we're asking is a spurious phenomena we have on two printers right now (duet2 and 3.4.1). It appears one command does not get an ok which in return blocks around half the buffer butting the printer into a kind of ping pong mode with roughly one command per second.
Sometimes this appears to happen again which results in a timeout and the print continuing fine afterwards.
You can see it happening in the below screenshot quite nicely in the highlighted part.
Hers an M122 while it was stuttering.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.1 (2022-06-01 21:05:28) running on Duet WiFi 1.02 or later + DueX5v0.11
Board ID: 0JD0M-9P6B2-NJ4S8-6J1D8-3SJ6R-TB4QK
Used output buffers: 3 of 26 (20 max)
=== RTOS ===
Static ram: 23860
Dynamic ram: 77504 of which 12 recycled
Never used RAM 9840, free system stack 88 words
Tasks: NETWORK(ready,1822.3%,242) HEAT(notifyWait,38.9%,308) Move(notifyWait,663.8%,282) DUEX(notifyWait,0.0%,24) MAIN(running,1279.0%,440) IDLE(ready,9.0%,30), total 3813.0%
Owned mutexes:
=== Platform ===
Last reset 44:36:32 ago, cause: software
Last software reset at 2023-12-05 11:48, reason: User, GCodes spinning, available RAM 10232, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 0
MCU temperature: min 25.3, current 33.1, max 34.5
Supply voltage: min 23.3, current 23.5, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
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 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min n/a
Driver 5: standstill, SG min 0
Driver 6: standstill, SG min 0
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10:
Driver 11:
Date/time: 2023-12-07 08:24:36
Cache data hit count 4294967295
Slowest loop: 6.92ms; fastest: 0.12ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 4.1ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 36, maxWait 54387006ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 1165291, completed 1165291, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 1, 38901], 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 3 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== DueX ===
Read count 12, 0.00 reads/min
=== Network ===
Slowest loop: 19.20ms; fastest: 0.00ms
Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address 48:3f:da:a6:c0:61
WiFi Vcc 3.38, reset reason Power up
WiFi flash size 2097152, free heap 25272
WiFi IP address 192.168.186.225
WiFi signal strength -50dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
Maybe you have an idea and ideally a suggestion / a fix as well.
Since I could not find anything just a quick question:
We're printing from RepetierServer on multiple machines running either 3mini's, 6hc's or 2wifi's using USB.
What is
a) the maximum buffer size we can use for the usb communication
and
b) the recommended buffer size should it be different from the above
Should it be different for the different boards, please let us know for each.
@CR3D FYI
@jay_s_uk we're in contact and diagnosing the issue yes
@timoschuett please be aware it does not really work yet.
@chrishamm That's the M122. DWC shows disconnected so I ran it over USB. So I assume the error is also sent from the firmware and not DSF
What are you thinking about if talking about "slow IO"?
Recv:16:47:15.911: === Diagnostics ===
Recv:16:47:15.911: RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-rc.1 (2023-08-31 16:16:56) running on Duet 3 Mini5plus WiFi (SBC mode)
Recv:16:47:15.911: Board ID: 4YP38-PR6KL-K65J0-409ND-JSW1Z-RWVQQ
Recv:16:47:15.911: Used output buffers: 1 of 40 (34 max)
Recv:16:47:15.911: === RTOS ===
Recv:16:47:15.911: Static ram: 102836
Recv:16:47:15.912: Dynamic ram: 106008 of which 0 recycled
Recv:16:47:15.912: Never used RAM 28348, free system stack 66 words
Recv:16:47:15.912: Tasks: SBC(2,nWait,7.3%,434) HEAT(3,nWait,0.3%,323) Move(4,nWait,26.9%,255) CanReceiv(6,nWait,0.0%,939) CanSender(5,nWait,0.0%,337) CanClock(7,delaying,0.1%,342) TMC(4,nWait,3.4%,74) MAIN(1,running,58.1%,822) IDLE(0,ready,0.0%,29) AIN(4,delaying,3.9%,264), total 100.0%
Recv:16:47:15.912: Owned mutexes: USB(MAIN)
Recv:16:47:15.912: === Platform ===
Recv:16:47:15.912: Last reset 06:04:11 ago, cause: software
Recv:16:47:15.912: Last software reset at 2023-11-05 10:43, reason: User, Platform spinning, available RAM 28460, slot 0
Recv:16:47:15.912: Software reset code 0x2000 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Recv:16:47:15.913: Error status: 0x00
Recv:16:47:15.913: MCU revision 3, ADC conversions started 21852847, completed 21852845, timed out 0, errs 0
Recv:16:47:15.913: MCU temperature: min 35.6, current 61.1, max 65.0
Recv:16:47:15.913: Supply voltage: min 23.4, current 23.8, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Recv:16:47:15.913: Heap OK, handles allocated/used 99/8, heap memory allocated/used/recyclable 2048/120/0, gc cycles 0
Recv:16:47:15.913: Events: 0 queued, 0 completed
Recv:16:47:15.913: Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 42, reads 33239, writes 19, timeouts 0, DMA errors 0, CC errors 0
Recv:16:47:15.914: Driver 1: ok, SG min 0, read errors 0, write errors 1, ifcnt 42, reads 33237, writes 21, timeouts 0, DMA errors 0, CC errors 0
Recv:16:47:15.914: Driver 2: ok, SG min 0, read errors 0, write errors 1, ifcnt 42, reads 33236, writes 21, timeouts 0, DMA errors 0, CC errors 0
Recv:16:47:15.914: Driver 3: ok, SG min 0, read errors 0, write errors 1, ifcnt 42, reads 33236, writes 21, timeouts 0, DMA errors 0, CC errors 0
Recv:16:47:15.914: Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 36, reads 33239, writes 19, timeouts 0, DMA errors 0, CC errors 0
Recv:16:47:15.914: Driver 5: not present
Recv:16:47:15.914: Driver 6: not present
Recv:16:47:15.915: Date/time: 2023-11-05 16:47:14
Recv:16:47:15.915: Cache data hit count 4294967295
Recv:16:47:15.915: Slowest loop: 67.66ms; fastest: 0.11ms
Recv:16:47:15.915: === Storage ===
Recv:16:47:15.915: Free file entries: 20
Recv:16:47:15.915: SD card 0 not detected, interface speed: 0.0MBytes/sec
Recv:16:47:15.915: SD card longest read time 0.0ms, write time 0.0ms, max retries 0
Recv:16:47:15.915: === Move ===
Recv:16:47:15.916: DMs created 83, segments created 57, maxWait 1480432ms, bed compensation in use: none, height map offset 0.000, ebfmin -1.00, ebfmax 1.00
Recv:16:47:15.916: next step interrupt due in 1059 ticks, enabled
Recv:16:47:15.916: Moves shaped first try 3252, on retry 15564, too short 426412, wrong shape 1142318, maybepossible 389406
Recv:16:47:15.916: === DDARing 0 ===
Recv:16:47:15.916: Scheduled moves 2936143, completed 2936103, hiccups 0, stepErrors 0, LaErrors 0, Underruns [340521, 0, 1], CDDA state 3
Recv:16:47:15.916: === DDARing 1 ===
Recv:16:47:15.916: Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
Recv:16:47:15.916: === Heat ===
Recv:16:47:15.917: Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Recv:16:47:15.917: === GCodes ===
Recv:16:47:15.917: Movement locks held by null, null
Recv:16:47:15.917: HTTP* is idle in state(s) 0
Recv:16:47:15.917: Telnet is idle in state(s) 0
Recv:16:47:15.917: File is idle in state(s) 0
Recv:16:47:15.917: USB is ready with "M122" in state(s) 0
Recv:16:47:15.917: Aux is idle in state(s) 0
Recv:16:47:15.917: Trigger* is idle in state(s) 0
Recv:16:47:15.917: Queue* is idle in state(s) 0
Recv:16:47:15.918: LCD is idle in state(s) 0
Recv:16:47:15.918: SBC is idle in state(s) 0
Recv:16:47:15.918: Daemon is idle in state(s) 0
Recv:16:47:15.918: Aux2 is idle in state(s) 0
Recv:16:47:15.918: Autopause is idle in state(s) 0
Recv:16:47:15.918: File2 is idle in state(s) 0
Recv:16:47:15.918: Queue2 is idle in state(s) 0
Recv:16:47:15.918: Q0 segments left 1, axes/extruders owned 0x0000807
Recv:16:47:15.918: Code queue 0 is empty
Recv:16:47:15.919: Q1 segments left 0, axes/extruders owned 0x0000000
Recv:16:47:15.919: Code queue 1 is empty
Recv:16:47:15.919: === CAN ===
Recv:16:47:15.919: Messages queued 196649, received 0, lost 0, boc 0
Recv:16:47:15.919: Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 26 (min 26), ts 109257/0/0
Recv:16:47:15.919: Tx timeouts 0,0,109256,0,0,87391 last cancelled message type 30 dest 127
Recv:16:47:15.919: === SBC interface ===
Recv:16:47:15.919: Transfer state: 0, failed transfers: 0, checksum errors: 0
Recv:16:47:15.919: RX/TX seq numbers: 0/1
Recv:16:47:15.920: SPI underruns 0, overruns 0
Recv:16:47:15.920: State: 0, disconnects: 1, timeouts: 1 total, 1 by SBC, IAP RAM available 0x0dadc
Recv:16:47:15.920: Buffer RX/TX: 0/0-0, open files: 0
We recently got an error message
lost connection to sbc due to remote timeout
on a duet 3 mini 5+ running in SBC mode. Never saw this error before and found nothing - can anyone (@dc42) point me in the right direction?
@chrishamm Thanks! I know it's not the first option to chose, but at least it works for now. We'll still try to make an actual SBC setup work, but that's something for another day.
@chrishamm no worries!
To narrow things down we originally wanted to go back to a usb connection but stopped in the middle.
The Duet was still connected via SBC (so no SD card in the duet) but also had a usb cable from the pi running RepetierServer (the external printing source) to the duet.
We noticed that this appears to work just fine and ran a few test prints.
So basically what we have now ist the duet connected via SBC to the pi and RepetierServer communicating with the duet via USB for status updates and printing (instead of the server being connected to the duet SBC socket on the pi). Obviously this would not make sense if the commands the duet receives over usb get sent back and forth trough the SBC connection, but as it has been going fine so far I assume they are not.
@chrishamm
Can you confirm that a USB print does not go trough the SBC connection back and forth?
@dc42 then we'll switch to the 6HC as we need the drivers for the extruder and see how it goes there.
@infiniteloop Interesting. I'll take a look, but I think not what we are aiming for right now.
@jay_s_uk @dc42 can you confirm this? Also can anyone advise if it would be better if we i.e. used a 6HC board?