constant pause
-
@Monster-Delta said in constant pause:
causing resets when i click to resume print.
You mean the Duet is resetting? If so, please run
M122 after one of those resets and post the reset data here. -
Ok here's the result
20/09/2019, 20:46:01: M122: === Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04RC1 running on Duet WiFi 1.02 or later
Board ID: 08DGM-9T6BU-FG3SN-6J9FL-3S46J-1SYMD
Used output buffers: 3 of 24 (23 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 93640 of which 284 recycled
Exception stack ram used: 312
Never used ram: 11156
Tasks: NETWORK(ready,652) HEAT(blocked,1172) MAIN(running,3756) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:00:26 ago, cause: power up
Last software reset at 2019-09-20 20:43, reason: User, spinning module GCodes, available RAM 11444 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 24.7, current 26.0, max 26.1
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2019-09-20 20:46:01
Cache data hit count 78608853
Slowest loop: 5.02ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 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: 15.43ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 84:f3:eb:41:59:80
WiFi Vcc 3.35, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25592
WiFi IP address 192.168.0.43
WiFi signal strength -35dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0: pos 0.00, no data received, no calibration data
it seems to be that once the print has been paused and resumed the next time i try to resume print it causes dwc to become unresponsive and a manual reset is required to obtain a connection again
- WiFi -
-
its also worth noting that when the print gets paused i get the error M25 printing is already paused repeated over and over until i click cancel or resume
-
ok so im getting somewhere now. i can start a print but but every few minutes i get an error sensor not working sometimes there is a red flashing led no code just constant slow flash, other times there is nothing at all but then it willflash green 4 times and i can resume the print but a few minutes later it happens again. and then sometimes the duet will restart all by itself heres an m122 reort from the last instance
22/09/2019, 18:01:21: M122: === Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04RC1 running on Duet WiFi 1.02 or later
Board ID: 08DGM-9T6BU-FG3SN-6J9FL-3S46J-1SYMD
Used output buffers: 3 of 24 (21 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 93640 of which 284 recycled
Exception stack ram used: 320
Never used ram: 11148
Tasks: NETWORK(ready,652) HEAT(blocked,1204) MAIN(running,3756) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:00:16 ago, cause: software
Last software reset at 2019-09-22 17:56, reason: Unknown, spinning module Platform, available RAM 10808 bytes (slot 0)
Software reset code 0x40b0 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f80f BFAR 0xe000ed38 SP 0x20001eac Task 0x5754454e
Stack: 0040611d 00406122 01000000 00000000 40e9f000 449ba533 00000000 3331bb4c c311e7c6 43d8eb1a bc000000 c00805c0 41f85a48 00000000 4762bd00 37d33333 4354c416 00000000 40b4c000 80000010 00406107 2001789c 00407001
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 30.7, current 31.1, max 31.3
Supply voltage: min 24.0, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2019-09-22 18:01:14
Cache data hit count 44407538
Slowest loop: 1.47ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 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: 15.54ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 84:f3:eb:41:59:80
WiFi Vcc 3.35, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24632
WiFi IP address 192.168.0.43
WiFi signal strength -36dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0: pos 0.00, no data received, no calibration data
when i get the sensor not working error and i do m122 this is the data for the filament monitor
Extruder 0: pos 234.14, ok, measured sens 25.61mm/rev min 97% max 101% over 18.1mm, errs: frame 18 parity 0 ovrun 0 pol 0 ovdue 0
even if the sensor is disabled i get this issue
- WiFi -
-
Any one.
-
is it a probem with logic of fliment sensing or a conection issue just speculating
-
@poohzaza what do you mean by logic of filament sensing?
-
@Monster-Delta said in constant pause:
t do you mean by logic of filament sensing?
you mention before that it triggered constantly maby invert that logic or the sensor is broken or recheak you config.g resume.g and pause.g -
For an issue like this I would start by either copying the data from the SD card and re-formatting it or just get a new SD card and copy everything over from the old one. a 16gig class 10 microsd card is rather cheap.
-
Please see the other thread about a similar issue experienced by another user with a magnetic filament monitor.
I intend to take a detailed look at issues with magnetic filament monitors later this week.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 did you get chance to look into this
-
What wiring are you using? I think the advice is to use shielded twisted pair cable, as the sensitivity of the sensor can be influenced if it runs near stepper motors and/or other cabling. There's a couple of other threads that might be worth checking:
https://forum.duet3d.com/topic/12182/magnetic-sensor
https://forum.duet3d.com/topic/3371/filament-monitor-working-well
https://forum.duet3d.com/topic/12005/magnetic-filament-monitor-calibrationIan
-
@Monster-Delta said in constant pause:
Any one.
I had quite similar issues with the rotating magnet filament monitor (see https://forum.duet3d.com/topic/11591/rotating-magnet-filament-monitor-frame-errors/22).
Turned out to be a faulty monitor, which I got replaced by Duet3D. The new one works as expected, throwing no more errors and putting out way more reliable data.As for the wiring I can - for my setup - confirm that braided but otherwise unshielded wires do work very well. But be sure to double check the crimp connections, and redo them in case of slightest doubts.
-
Its not the wiring as it worka fine with the laser version. Im just about out of ideas i think I'll send it back and see if the folks at duet can figure it out
-
I just installed our magnetic filament monitor and about 4 layers into a 400 layer print, I was optimistic, it started pausing. Tried a bunch of things but nothing worked. It would pause within seconds of resuming. I ended up setting the R parameter to 1/330 and it started printing again. Realizing that almost defeats the purpose of the monitor, I ran the 591 reports every few minutes.
They showed a somewhat smaller sensitivity then the 28.4 I started out with and a min variation of 2% while the max variation was around 113%.
I reset the L parameter on the fly with the gcode console to a value close to what it was reporting, 26.4 I believe and immediately got a pause, which I immediately resumed. Within a few layers the min variation was up to 28% and the max was 117%. After a few more layers the sensitivity was reading 27.13 and kinda holding there so again I set the L parameter on the fly and again got a pause and resumed.
The print is 75% done and I just changed the L parameter to 27.88 and now the min variation is 48% and the max is 112%. So it is really close to the 60% spread of the original 70/130.
The print show some impact at 4-6 layer area because of the the stuff I was trying, but it is not a wasted print.
I think the big problem is crap filament that the customer supplied and is the reason for the filament monitor purchase in the first place.
I guess the takeaway is patients and insist on buying your own filament.
I do notice that the monitor we received blinks red and green, one flash each constantly if filament is not moving. This behavior is not mentioned anywhere in the documentation, but it dose not seem to indicate anything other than no motion.
Don't know if this applies to the original posting, but it may help someone. -
@DarylMcM said in constant pause:
I do notice that the monitor we received blinks red and green, one flash each constantly if filament is not moving. This behavior is not mentioned anywhere in the documentation, but it dose not seem to indicate anything other than no motion.
That is the expected behaviour when the filament monitor detects no motion, and the filament monitor is running version 2 firmware. The green flashes are position reports, the red ones are status reports.
-
replacement received and all is working as it should now
