Magnetic Filament Sensor - false alarms

gunrak

According to MCU specs 56C is more than fine:

gunrak

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

gunrak

@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.

dc42

@o_lampe said in Magnetic Filament Sensor - false alarms:

@dc42
Maybe it's not the right place to discuss it here, but a optical mouse sensor reading the surface of a rough idler roller would have a much higher resolution than a magnet&hall combo. And the rough surface of the roller avoids slipping, too.

Just my 2 Cent

Have you seen https://forum.duet3d.com/topic/18497/indirect-laser-monitor-remix-ii-working ?

dc42

@gunrak said in Magnetic Filament Sensor - false alarms:

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

Please post the GCode file you are printing. I have a machine using a tool board with magnetic filament monitor, so I will try printing your part on it.

gunrak

@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

Hobby-Store

Hi,

Please help our client or do you accept the sensor under warranty?

dc42

I am trying to run your client's print, but it's too large for the bed of my printer. I will try a workaround tomorrow.

dc42

@gunrak, I see the following command in your print file:

;Enable Stealthcop Tuning move

G1 E0.2 F100

Does this mean that you have configured the extruder driver in StealthChop mode? I advise against that, because StealthChop can't adapt to rapid fluctuations in load.

gunrak

@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

@gunrak, have you see this thread https://forum.duet3d.com/topic/21958/magnetic-sensor-reports-negative-min-value ?

The sensor should be as close to the extruder as possible. Otherwise, when the extruder retracts, the filament tends to bunch up in the bowden tube between the sensor and the extruder, instead of back-feeding through the sensor.

gunrak

@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.