@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.
Thanks @dc42 I received the replacement in hand. So far none of the "sensor not working" errors I was seeing before.
I am seeing the error count go up even for the sensor thats not being used in a specific print. I am printing with E0 right now and this is the error counts:
Extruder 0: pos 159.26, errs: frame 18 parity 0 ovrun 0 pol 22 ovdue 0
Extruder 1: pos 358.24, errs: frame 0 parity 0 ovrun 0 pol 17 ovdue 0
(this is the M591 report for D0)
Duet3D magnetic filament monitor on input 11, enabled, sensitivity 25.00mm/rev, allow 20% to 150%, check every 40.0mm, version 3, mag 129 agc 99, measured sensitivity 25.74mm/rev, min 42% max 109% over 13439.1mm
What is the definition of those error categories (Frame, Parity, Ovrun, Pol) and is there a certain threshold that should be concerning?
@dc42 i swapped the cables last week and the errors stayed with sensor 0. I even moved sensor 0 to a different endstop on the duet and it still had issues.
Here is the readout immediately after a "sensor is not working" error just now:
M591 D0
Duet3D magnetic filament monitor on input 11, enabled, sensitivity 25.00mm/rev, allow 20% to 150%, check every 40.0mm, version 3, mag 130 agc 82, measured sensitivity 25.00mm/rev, min 100% max 100% over 80.1mm
M122:
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-917NK-F23T0-6J1F6-3SD6T-1GBWD
Used output buffers: 3 of 24 (22 max)
=== RTOS ===
Static ram: 25712
Dynamic ram: 95048 of which 0 recycled
Exception stack ram used: 520
Never used ram: 9792
Tasks: NETWORK(ready,628) HEAT(blocked,1232) DUEX(suspended,160) MAIN(running,3736) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 03:35:18 ago, cause: software
Last software reset at 2020-01-31 11:57, reason: User, spinning module GCodes, available RAM 9832 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 10
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 309.0ms, max retries 0
MCU temperature: min 41.2, current 42.6, max 44.6
Supply voltage: min 23.8, current 23.9, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 23/1023
Driver 1: standstill, SG min/max 130/1023
Driver 2: standstill, SG min/max 137/1023
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max 0/1023
Driver 5: standstill, SG min/max 122/1023
Driver 6: standstill, SG min/max 14/1023
Driver 7: standstill, SG min/max 16/1023
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-01-31 15:32:24
Cache data hit count 4294967295
Slowest loop: 209.79ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 160, MinFreeDm: 103, MaxWait: 448804ms
Bed compensation in use: mesh, comp offset 0.000
=== DDARing ===
Scheduled moves: 2456, completed moves: 2456, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
=== GCodes ===
Segments left: 0
Stack records: 3 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 309.55ms; fastest: 0.05ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
=== Filament sensors ===
Extruder 0: pos 0.00, errs: frame 1 parity 0 ovrun 0 pol 1 ovdue 0
Extruder 1: pos 124.10, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
and the line in the Error log:
2020-01-31 15:32:15 Extruder 0 reports sensor not working
2020-01-31 15:32:23 Printing paused at X26.2 Y17.2 Z1.8 U201.0
2020-01-31 15:32:50 Printing resumed
The Sensor on E1 seems to work fine, the one on E0 always errors like this now.
So I have verified that its not cable, its not the port on the board, I have one of my 2 rotating filament sensors errors out with a "Sensor not working" error. I've had to disable the sensor on all prints just to ensure it doesnt error out the print.
@dc42 @T3P3Tony I've posted about some of the errors here, and haven't seen any responses... So I just want to return/replace this one bad sensor for one that works. I am guessing I need your blessing to get Filastruder to do the return/replace.
For some reason the forum wont let me edit that post to fix a typo in the M591. :
M591 D0 P3 C10 S1 R20:150 L25 E40
M591 D1 P3 C11 S1 R20:150 L25 E40
So I am seeing continued issues with my new v1.7a Rotating magnet filament sensor. I have 2 of them installed and one of them seems to be constantly dropping out with:
2020-01-18 10:44:35 Resume state saved
2020-01-18 10:44:35 Extruder 0 reports sensor not working
2020-01-18 10:44:41 Printing paused at X3.7 Y-101.1 Z4.2 U3.7
2020-01-18 10:44:53 Printing resumed
2020-01-18 11:02:54 Resume state saved
2020-01-18 11:02:54 Extruder 0 reports sensor not working
2020-01-18 11:03:03 Printing paused at X10.2 Y-124.8 Z5.0 U10.2
This is regardless of if I even disable the sensor it seems.
This is starting to cause a lot of issues with my prints and almost not worth even using the sensor these days.
I ran M122 and i see this:
Extruder 0: pos 253.48, errs: frame 13 parity 0 ovrun 0 pol 8 ovdue 0
Extruder 1: pos 192.30, errs: frame 0 parity 0 ovrun 0 pol 37 ovdue 0
They are connected to the CONN_LCD port. I have tested the wires and the connectors are good... To me this seems like an issue with the sensors or the CONN_LCD endstops. I am running v2.05 firmware.
My M591 settings are: (I have the sample size huge and a big window for the ranges because I didnt want false positives)
M591 D0 P3 C11 S1 R20:150 L25 E40
M591 D1 P3 C11 S1 R20:150 L25 E40
@T3P3Tony or @dc42 any insight in if there is something I should be doing differently? Is interference or EMI potentially an issue? the filament sensor wires run near the extruder/hotend wire runs.
Also... what do each of the error names mean? Ovrun? Pol? OvDue?
Hi there,
So I have a management system setup to watch my 3D printer that is keyed on one of the LED outputs on the Duex5 to tell me via msg if the printer pauses for any reason.
I have this command in the Pause.g:
;Set Pause LED - for ESP8266 monitoring
M106 P5 S255
Then in Resume.g I have this:
;Clear Pause LED - for ESP8266 monitoring
M106 P5 S0
But I am seeing Resurrect.g kind of randomly it seems picks the values to put into the file for the fans. And regardless, even if it says M106 P5 S0 in the listing it still leaves the LED lit 100% when the print resumes.
; File "0:/gcodes/Test Camera Mount.gcode" resume print after print paused at 2020-01-12 18:11
G21
M140 P0 S55.0
G29 S1
T-1 P0
G92 X-57.854 Y8.159 Z8.500 U201.000
G60 S1
G10 P1 S0 R0
G10 P2 S0:0 R0:0
G10 P3 S0:0 R0:0
G10 P0 S210 R210
T0 P0
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 U0.000 R0
T-1 P0
T0 P6
G10 L2 P1 X0.00 Y0.00 Z0.00 U0.00
G10 L2 P2 X0.00 Y0.00 Z0.00 U0.00
G10 L2 P3 X0.00 Y0.00 Z0.00 U0.00
G10 L2 P4 X0.00 Y0.00 Z0.00 U0.00
G10 L2 P5 X0.00 Y0.00 Z0.00 U0.00
G10 L2 P6 X0.00 Y0.00 Z0.00 U0.00
G10 L2 P7 X0.00 Y0.00 Z0.00 U0.00
G10 L2 P8 X0.00 Y0.00 Z0.00 U0.00
G10 L2 P9 X0.00 Y0.00 Z0.00 U0.00
G54
M106 S0.93
M106 P0 S0.93
M106 P1 S0.00
M106 P5 S0.00
M106 P6 S1.00
M106 P7 S0.00
M106 P8 S0.29
M116
G92 E10.90090
M82
M23 "0:/gcodes/Test Camera Mount.gcode"
M26 S636096
G0 F6000 Z10.500
G0 F6000 X-57.854 Y8.159 U201.000
G0 F6000 Z8.500
G1 F4644.0 P0
G21
M24
But even with the file above showing the M106 P5 (the LED is on fan header 5), it still maintains the S255 state... I can't seem to programmatically clear it on a resume.
Since no one seems to have replied - yes if you enable the eventloging function in the firmware, it will state what caused the pause to occur. It will also show as a pop up notification on the web console. In the console itself it will just say it was paused though.
The full M122 is here:
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-917NK-F23T0-6J1F6-3SD6T-1GBWD
Used output buffers: 3 of 24 (21 max)
=== RTOS ===
Static ram: 25712
Dynamic ram: 95048 of which 0 recycled
Exception stack ram used: 480
Never used ram: 9832
Tasks: NETWORK(ready,628) HEAT(blocked,1232) DUEX(suspended,160) MAIN(running,3728) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 03:26:30 ago, cause: software
Last software reset at 2020-01-05 12:19, reason: User, spinning module GCodes, available RAM 9864 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 8
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 41.7, current 42.6, max 43.4
Supply voltage: min 23.9, current 23.9, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, SG min/max 40/1023
Driver 1: standstill, SG min/max 406/1023
Driver 2: standstill, SG min/max 401/1023
Driver 3: standstill, SG min/max 0/238
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: ok, SG min/max 15/1023
Driver 7: ok, SG min/max 29/1023
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-01-05 15:46:07
Cache data hit count 4294967295
Slowest loop: 6.28ms; fastest: 0.09ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 155, MinFreeDm: 97, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== DDARing ===
Scheduled moves: 86200, completed moves: 86160, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 1
Stack records: 3 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 X85.111 Y104.983 E1.2412" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 15.26ms; fastest: 0.05ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
=== Filament sensors ===
Extruder 0: pos 75.23, errs: frame 1 parity 0 ovrun 0 pol 0 ovdue 0
Extruder 1: pos 227.81, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
Hi there, I have 2 rotating filament sensors (the new 1.7a versions just received 2 weeks ago)
They are on the end of a Bowden tube so I expected some variance, but the readings are all over the place for a fast PLA print I am doing right now (Printing at 90mm/sec .4mm nozzle). I have an direct drive IDEX setup and don't want to put more mass on the extruders so the sensors are at the frame on the end of the bowden that feeds the extruders. Since I am printing with stiff PLA for this print I wasnt expecting such issues.
The sensors are wired to the CONN_LCD ports for Endstop 10 and 11.
Board info:
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-917NK-F23T0-6J1F6-3SD6T-1GBWD
Used output buffers: 1 of 24 (21 max)
Filament sensor reading off M122:
=== Filament sensors ===
Extruder 0: pos 302.34, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
Extruder 1: pos 228.52, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
Errors I am seeing in the eventlog.txt:
2020-01-05 14:17:05 Extruder 0 reports too little movement
2020-01-05 14:17:10 Printing paused at X-6.5 Y-95.0 Z11.1 U201.0
2020-01-05 14:18:15 Printing resumed
2020-01-05 14:18:29 Resume state saved
2020-01-05 14:18:29 Extruder 0 reports too little movement
2020-01-05 14:18:34 Printing paused at X-26.4 Y-95.0 Z11.1 U201.0
2020-01-05 14:19:02 Printing resumed
2020-01-05 14:39:41 Resume state saved
2020-01-05 14:39:41 Extruder 0 reports too little movement
2020-01-05 14:39:47 Printing paused at X97.9 Y-49.5 Z13.2 U201.0
2020-01-05 15:05:33 HTTP client 192.168.50.137 login succeeded
2020-01-05 15:07:19 Printing resumed
2020-01-05 15:14:43 Resume state saved
2020-01-05 15:14:43 Extruder 0 reports sensor not working
2020-01-05 15:14:48 Printing paused at X-89.0 Y-40.5 Z14.4 U201.0
2020-01-05 15:15:36 Printing resumed
The last error where it says the Extruder sensor not working was reported after I disabled the sensor with a M591 D0 S0 command!
The M591 D0 outputs I've been running between pauses are:
1/5/2020, 3:14:59 PM M591 D0
Duet3D magnetic filament monitor on input 10, disabled, sensitivity 25.00mm/rev, allow 20% to 150%, check every 15.0mm, version 3, mag 129 agc 83, measured sensitivity 25.62mm/rev, min 96% max 104% over 1557.6mm
1/5/2020, 3:16:24 PM M591 D0
Duet3D magnetic filament monitor on input 10, disabled, sensitivity 25.00mm/rev, allow 20% to 150%, check every 15.0mm, version 3, mag 129 agc 83, measured sensitivity 25.63mm/rev, min 98% max 104% over 181.1mm
1/5/2020, 3:15:52 PM M591 D0
Duet3D magnetic filament monitor on input 10, disabled, sensitivity 25.00mm/rev, allow 20% to 150%, check every 15.0mm, version 3, mag 130 agc 83, measured sensitivity 25.82mm/rev, min 99% max 101% over 60.5mm
1/5/2020, 1:36:22 PM M591 D0
Duet3D magnetic filament monitor on input 10, enabled, sensitivity 25.00mm/rev, allow 20% to 150%, check every 8.0mm, version 3, mag 131 agc 84, measured sensitivity 25.60mm/rev, min 97% max 104% over 81.1mm
1/5/2020, 2:17:36 PM M591 D0
Duet3D magnetic filament monitor on input 10, enabled, sensitivity 25.00mm/rev, allow 20% to 150%, check every 8.0mm, version 3, mag 131 agc 85, measured sensitivity 25.89mm/rev, min -43% max 107% over 10639.6mm
1/5/2020, 1:33:31 PM M591 D0
Duet3D magnetic filament monitor on input 10, enabled, sensitivity 25.00mm/rev, allow 40% to 150%, check every 8.0mm, version 3, mag 129 agc 84, measured sensitivity -27.51mm/rev, min 115% max 0% over 650.1mm
As you can see I kept moving the tolerances further apart, and even disabled the sensor and I am still getting these weird pauses/crashes.
Could this be an interference issues with the cable? CONN_LCD Endstop issue? The fact I am not seeing any error info out of the M122 for the magnetic sensor leaves me very confused.
Not sure what I should be doing here, now thats its pausing for even the "sensor not working" error... when the sensor is disabled. I am seeing consistent "green" on the sensor when printing is happening even in the instant that the pause happens.