I did some additional testing with 3.3 beta, it seams that it fails to trigger pause even for the first time, or it significantly delayed.

@dc42 it was a while since I posted. After I read thread you mentioned I mounted sensor as close as possible to extruder and since then I did not receive any failure or false alarm (printed couple spooles).

Thank you for help and patience. Issue solved.

@dc42

You are right, I was experimenting with StealthChop, and apparently I forgot to remove it from my other computers slicer's Start G-Code. StealthChop is not enabled in config.

I still did not give up, and other day was experimenting, my thought was that maybe sensor is to close to extruder. I have Hemera and stepper motor is right there and I thought maybe that was causing interference so I went from 4cm to 8cm long PTFE tube now sensor is mounted further away from stepper motor.

All other settings stayed the same, but this time I printed with PETG instead of PLA, still 0.8mm nozzle, diferent part. Absolutely nothing changed, exactly the same pattern as before.

@dc42

I did upgrade to RRF 3.3beta1, just to see if this will make any difference.
Errors are still there, but a bit less than yesterday printing the same file:

and .zip is not allowed to upload.

Uploaded to DropBox: https://www.dropbox.com/s/tnevy8i5yhnym6x/f119e32e-cf3a-46c6-97b3-237b4b389e3c_0.8n_0.4mm_PLA__3h34m.gcode?dl=0

@dc42

I did check the magnet and it sits firmly on the shaft.

So, I am out of ideas, what else I could do.

Duet 3 is probably the best 3D printer board available on the market, combined with Toolboard it offers unique functionality. I love it. It is so good that I have temptation to replace my CNCs Duet 2 with Duet 3, especially if I keep SBC mode in mind.

Magnetic Filament Sensor is exactly 65EUR of disappointment + wasted time and filament on failed prints, especially if it not clear where is the issue. Hardware, software, user error?
It defiantly has great potential, but it should be reliable, I guess I will try to return it and get the refund, and print out simple microswitch filament run out sensor.

Last print:

01/03/2021, 16:52:29
M122 B121
Diagnostics for board 121:
Duet TOOL1LC firmware version 3.2.2 (2021-02-11)
Bootloader ID: SAMC21 bootloader version 2.2 (2021-01-16b1)
Never used RAM 3540, free system stack 22 words
HEAT 86 CanAsync 89 CanRecv 83 TMC 56 MAIN 218 AIN 64
Last reset 04:19:02 ago, cause: power up
Last software reset time unknown, reason: OutOfMemory, available RAM 15440, slot 1
Software reset code 0x01c0 ICSR 0x00000000 SP 0x20003638 Task MAIN Freestk 796 ok
Stack: 20000d10 0001234f 20000d10 0001e5f1 00000000 00004008 20000d10 0001e565 20000d0c 00004000 a5a5a5a5 a5a5a5a5 00000000 0001e42d 00004000 000191b1 a5a5a5a5 000191cd a5a5a5a5 0001219d a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5
Driver 0: position 21862546, 409.0 steps/mm, standstill, SG min/max 0/28, read errors 0, write errors 0, ifcnt 14, reads 37736, writes 14, timeouts 0, DMA errors 0
Moves scheduled 183899, completed 183899, in progress 0, hiccups 0
No step interrupt scheduled
VIN: 24.2V
MCU temperature: min 32.6C, current 46.7C, max 57.0C
Ticks since heat task active 31, ADC conversions started 15480195, completed 15480195, timed out 0
Last sensors broadcast 0x00000002 found 1 35 ticks ago, loop time 0
CAN messages queued 194317, send timeouts 0, received 323864, lost 0, free buffers 36
=== Filament sensors ===
Interrupt 5 to 34us, poll 9 to 748us
Driver 0: pos 10.55, errs: frame 39 parity 0 ovrun 0 pol 0 ovdue 0

01/03/2021, 16:51:47
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2.2 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TJ-6J9DA-3SN6S-9AAUV
Used output buffers: 7 of 40 (39 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 63388 of which 172 recycled
Never used RAM 145484, free system stack 130 words
Tasks: Linux(ready,95) HEAT(blocked,272) CanReceiv(blocked,809) CanSender(blocked,339) CanClock(blocked,352) TMC(blocked,17) MAIN(running,675) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 04:18:19 ago, cause: power up
Last software reset at 2021-03-01 06:04, reason: User, none spinning, available RAM 145352, slot 0
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 38.1, current 39.4, max 40.2
Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
Driver 0: position 35000, standstill, reads 9594, writes 1 timeouts 0, SG min/max 0/1023
Driver 1: position -35000, standstill, reads 9594, writes 1 timeouts 0, SG min/max 0/1023
Driver 2: position 14397, standstill, reads 9594, writes 1 timeouts 0, SG min/max 0/1023
Driver 3: position 0, standstill, reads 9594, writes 1 timeouts 0, SG min/max 0/1023
Driver 4: position 0, standstill, reads 9595, writes 1 timeouts 0, SG min/max 0/1023
Driver 5: position 0, standstill, reads 9596, writes 0 timeouts 0, SG min/max not available
Date/time: 2021-03-01 14:51:46
Slowest loop: 198.42ms; fastest: 0.02ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 160ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 187795, completed moves 187795, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" 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
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause* is idle in state(s) 0
Code queue is empty.
=== Filament sensors ===
Extruder 0: no data received
=== CAN ===
Messages queued 229693, send timeouts 0, received 162403, lost 0, longest wait 3ms for reply type 6048, free buffers 48
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 1ms ago
RX/TX seq numbers: 8291/8291
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8a8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.2
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 44.04
Maximum length of RX/TX data transfers: 5076/1684

@o_lampe

According to MCU specs 56C is more than fine:

And it happened again!

@dc42 said in Magnetic Filament Sensor - false alarms:

• Filament slippage, as you suspect.

Could filament slippage actually increase max up to 115% as you can see in screenshot? And negative min, how could I achieve that due to slippage? correct me if I am wrong but negative value means that filament is traveling backward, correct? If so, slippage should not cause the issue.

• Severe interference pickup by the cable. Run M122 at the end of the print and look at the filament monitor error counts. That will indicate whether interference is a problem.

Changed wired to shielded cable, wired away from all possible interferers, did not help. In theory it still could be potential issue.

• We saw a small number of instances during inspection of the magnet not being held securely on the shaft, leaving it free to rotate on the shaft. So check that the magnet is secure.

Still have to check this, but again, could freely rotating magnet cause negative min, and 115% max?

• It could possibly be that a part of your print uses the extruder in a way that confuses the firmware. If that's the case then it should be consistent if you repeat the print.

Print is plain as it possible be, I do use 0.8mm nozzle, but print speeds are relatively low and retraction is set to 0.6mm 35 mm/s. Not sure that such a plain print could could cause confusion to firmware.

Before last print finished 99%, it was paused due to sensor error or something like that, even if filament monitoring set to disabled (S0)

Could it actually be firmware bug? Anything to do with the fact that I use toolboard? Is there any way to debug/log/view communication between sensor and firmware?

Apparently no difference with shelded cable routed as far as possible from stepper and stepper cable:

Next I will check the magnet.

Will give it a try: