Best posts made by clegg78

@dc42 I upgraded to the 3.4.1 RC that is posted and it seems to have remedied a most of the disconnections! I am seeing the max Output buffers go to 26, but in general no (or many less) crashes or reconnections like was happening before.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.1rc1 (2022-05-03 09:34:00) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-917NK-F23T0-6J1F6-3SD6T-1GBWD
Used output buffers: 7 of 26 (26 max)
=== RTOS ===
Static ram: 23868
Dynamic ram: 74972 of which 0 recycled
Never used RAM 9088, free system stack 96 words
Tasks: NETWORK(ready,203.0%,218) HEAT(notifyWait,5.1%,307) Move(notifyWait,209.7%,283) DUEX(notifyWait,0.0%,24) MAIN(running,149.4%,425) IDLE(ready,0.1%,30), total 567.3%
Owned mutexes:
=== Platform ===
Last reset 23:10:43 ago, cause: software
Last software reset at 2022-05-14 14:04, reason: User, GCodes spinning, available RAM 9256, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x0c
Aux0 errors 0,1,0
Step timer max interval 0
MCU temperature: min 42.8, current 45.7, max 46.8
Supply voltage: min 23.8, current 23.9, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/3, heap memory allocated/used/recyclable 2048/670/646, gc cycles 0
Events: 1 queued, 1 completed
Driver 0: standstill, SG min 3
Driver 1: ok, SG min 0
Driver 2: ok, SG min 0
Driver 3: standstill, SG min 0
Driver 4: ok, SG min 0
Driver 5: ok, SG min 37
Driver 6: ok, SG min 9
Driver 7: ok, SG min 10
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
Date/time: 2022-05-15 13:15:30
Cache data hit count 4294967295
Slowest loop: 350.13ms; fastest: 0.14ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 22.2ms, write time 10.3ms, max retries 0
=== Move ===
DMs created 83, segments created 54, maxWait 25947876ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 18853, completed 18813, hiccups 0, stepErrors 0, LaErrors 0, Underruns [356, 0, 0], CDDA state 3
=== 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 0 is on, I-accum = 0.0
Heater 2 is on, I-accum = 0.7
=== 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 doing "G1 X-24.463 Y21.930 E0.0324" 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
=== Filament sensors ===
Extruder 0: pos 2.11, errs: frame 1 parity 0 ovrun 0 pol 0 ovdue 0
Extruder 1: pos 328.01, errs: frame 0 parity 0 ovrun 0 pol 1 ovdue 0
=== DueX ===
Read count 1, 0.00 reads/min
=== Network ===
Slowest loop: 161.96ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
Interface state active, link 100Mbps full duplex

@bot said in New custom IDEX, but S3D and Duet tool changing issues.:

XYZU

Ohh interesting, yeah that is good info to have documented somewhere it is confusing because in the IDEX guide on the site, it has U on the Stepper Driver 3 as well, so it looks like it was just mapping to that stepper number. I'll fix my code now

I have noticed there are a lot of little nuances with the RR coding on Duet that takes some time to figure out!

I appreciate it!

@nhof said in Z-Max End stop? Printer ignoring it?:

he second line M574 Z1 S2 we are actually asking for the Z probe to trigger when the Z reaches min limit. Not what we really want to set up for the subsequent G1 move.
I imagine something like M574 Z2 S1 might serve you better, double check the home sensor state using M119 (or thru DWC) to ensure you have the proper S value

Awesome, I will take a look at these! The G1 syntax specifically could be the issue I was seeing.

Update on some testing @Phaedrux @dc42

I disabled both my filament sensors for some testing (Duet Rotating magnet sensors v1.7). 2x of them.

If I enable either of them, DWC constantly reconnects. if I enable both, it gets crazy.

If both are disabled the DWC instance is stable. You can see the sequence here, the system is stable, I enable one of the sensors, and DWC starts dropping and reconnecting.

My Tool 0 sensor: M591 D0 P3 C"e1_stop" S1 R40:140 L26 E60

My Tool 1 sensor: M591 D1 P3 C"connlcd.enca" S1 R40:140 L26 E60

This is crazy repeatable as well.

@gloomyandy

That was it!!

At some point I put that script in there as well. I didnt realize Stop.g gets called at the end of every job now.

@sebkritikel it was my slicer acting weird and specifically for the profile I use for the duplication printing, it was failing.

@owend

I ended up with this being my config for filament-error.g. Since a rotating magnet filament sensor, "tooLittleMovement" doesnt seem to be a "status" of the sensor, so I just made a config to filter out transient issues (sensorError and noDataRecieved) and only stop the printer if those 2 status conditions are not present.

if {param.D ^ ""} = "0"
	if sensors.filamentMonitors[0].status = "sensorError"
		echo "SensorError-0 Continuing to Print"
		
		M99
	if sensors.filamentMonitors[0].status = "noDataReceived"
		echo "noDataReceived-0 Continuing to Print"
		
		M99
	echo "Too Little Movement-0-Paused"
	M291 p"Filament Sensor 0 - Too Little Movement" S1
	M25 ;pause the print
	
if {param.D ^ ""} = "1"
	if sensors.filamentMonitors[1].status = "sensorError"
		echo "SensorError-1 Continuing to Print"
		M99
	if sensors.filamentMonitors[1].status = "noDataReceived"
		echo "noDataReceived-1 Continuing to Print"
		M99
	echo "Too Little Movement?-Paused"
	M291 p"Filament Sensor 1 - Too Little Movement" S1
	M25 ;pause the print

M99

DHT22 are easily available and far more accurate I've found. I used both but standardized on 22's for chamber temps and filament drybox humidity monitoring.