@fcwilt said in multiple Z-Probe trigger heights in config-override.g:
So you think that limiting customers to executing G-code commands will prevent them from messing things up?
Never underestimate the power of a customer to mess things up. Some of them seem to view it as a challenge
Well, the beautiful thing about my setup is, they need a password for it. But I'm sure someone will try hard enough to manage to mess something up 
Still I don't want to make it too easy
@jay_s_uk I know about those and the extruder driver was always on the same board as the filament monitor
I'd love to keep some (global) variables upon restart.
Figured in keeping variables (global) after reset .gco files could be used, but it will get complicated soon.
Would love to see a M*** command that writes all currently set globals to a file variables.g (or alike) in sys, which could then be called while startup. This way you could simply change the value of one variable, and write them all back to the variables file if needed. kind of like with config-override.g
@jay_s_uk I did and it should be working. At least I don't see anything obvious.
M915
Driver 0.0: stall threshold -50, steps/sec 200, coolstep f, action on stall: run macro
Driver 0.1: stall threshold -50, steps/sec 200, coolstep f, action on stall: run macro
Driver 0.2: stall threshold -50, steps/sec 200, coolstep f, action on stall: run macro
Driver 0.3: stall threshold -50, steps/sec 200, coolstep f, action on stall: run macro
Driver 0.4: stall threshold 1, steps/sec 200, coolstep 0, action on stall: none
Driver 0.5: stall threshold 1, steps/sec 200, coolstep 0, action on stall: none
Driver 0.6: stall threshold 1, steps/sec 200, coolstep 0, action on stall: none
@jay_s_uk thanks - I'll give it a try and get back to you if needed!
@jay_s_uk we're in contact and diagnosing the issue yes
@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.