RRF3.4 RC2 Filament/sensor error

BoA

@phaedrux Yes. That is the only error. If there is a way to enable some debug logging I can do that to get more info.

And... probably not related completly, but I noticed that my stop.g causes chamber heater to go into active state, which was not the case with 3.3

stop.g:

T-1
M104 S0 T0
M104 S0 T1
M140 S0 R0
M141 S0 R0 ; disable chamber heater
M144 S0 ; put heatbed on standby

M106 P0 S0
M220 S100
M221 S100 D0
M221 S100 D1

M84
M300 P300

Phaedrux

@boa said in RRF3.4 RC2 Filament/sensor error:

                                                                                                                            T-1                                                                                                                                                                            M104 S0 T0                                                                                                                                                                            M104 S0 T1                                                                                                                                                                            M140 S0 R0                                                                                                                                                                            M141 S0 R0 ; disable chamber heater                                                                                                                                                                            M144 S0 ; put heatbed on standby

If you send those commands manually does it behave the same with with the chamber heater? And is it active state with 0 temperature?

BoA

@phaedrux Yes. Sending manually M141 S0 R0 manually causes chamber heater switch to active with temps 0*C

Phaedrux

What if you just use M141 R0?

BoA

@phaedrux said in RRF3.4 RC2 Filament/sensor error:

What if you just use M141 R0?

This way it stays off. Thanks. However... what it is active, sending M141 R0 does not switch to off state. I wonder how DWC makes chamber heater off.

BoA

I just opened Object Model and...

I was expecting values from M591 command

M591 D0 P3 C"io5.in" S1 L25.4 R50:150 E12.7 A0

which seems not to be the case.

Phaedrux

@boa said in RRF3.4 RC2 Filament/sensor error:

I wonder how DWC makes chamber heater off.

What happens if you set the temp to -274?

BoA

@phaedrux said in RRF3.4 RC2 Filament/sensor error:

@boa said in RRF3.4 RC2 Filament/sensor error:

I wonder how DWC makes chamber heater off.

What happens if you set the temp to -274?

M141 R-274
Error: M141: Temperature too low for heater 3

state is unchanged

Phaedrux

How about -273?

BoA

@phaedrux
-273 is set and state does not change
If executed on active, it stays active, of on off it stays off

BoA

I updated to official 3.4 release, and the issue is still reproducible.

20.03.2022, 19:17:00 	Resume state saved
20.03.2022, 19:16:57 	Error: Filament error on extruder 0: sensorError
20.03.2022, 12:27:04 	80 points probed, min error -0.085, max error 0.175, mean 0.098, deviation 0.050
Height map saved to file 0:/sys/heightmap.csv
20.03.2022, 12:24:44 	Leadscrew adjustments made: 0.322 -1.414, points used 2, (mean, deviation) before (-0.494, 0.579) after (0.000, 0.000)
20.03.2022, 12:23:29 	Connected to 192.168.0.204

Sensor reported after about 6h 50m of printing.
After resuming, works just fine.

M122 shows nothing disturbing

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0 (2022-03-15 18:57:24) running on Duet 3 MB6HC v1.01 or later (standalone mode)
Board ID: 08DJM-956L2-G43S8-6J1D6-3SJ6R-KA0YG
Used output buffers: 1 of 40 (40 max)
=== RTOS ===
Static ram: 151000
Dynamic ram: 98868 of which 0 recycled
Never used RAM 80884, free system stack 118 words
Tasks: NETWORK(ready,13.6%,193) ETHERNET(notifyWait,0.6%,166) HEAT(notifyWait,0.6%,321) Move(notifyWait,18.1%,248) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,356) CanClock(delaying,0.1%,333) TMC(notifyWait,102.1%,58) MAIN(running,210.0%,1016) IDLE(ready,0.0%,30), total 345.1%
Owned mutexes:
=== Platform ===
Last reset 07:00:42 ago, cause: power up
Last software reset at 2022-03-14 16:09, reason: User, GCodes spinning, available RAM 85252, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,1,0
Step timer max interval 195
MCU temperature: min 23.6, current 45.3, max 45.7
Supply voltage: min 9.2, current 27.3, max 27.5, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 8.4, current 12.2, max 12.5, under voltage events: 1
Heap OK, handles allocated/used 99/8, heap memory allocated/used/recyclable 2048/240/0, gc cycles 0
Events: 1 queued, 1 completed
Driver 0: ok, SG min 0, mspos 166, reads 30928, writes 47 timeouts 0
Driver 1: ok, SG min 0, mspos 120, reads 30928, writes 47 timeouts 0
Driver 2: stalled, SG min 0, mspos 498, reads 30943, writes 33 timeouts 0
Driver 3: standstill, SG min 0, mspos 8, reads 30950, writes 26 timeouts 0
Driver 4: ok, SG min 0, mspos 248, reads 30938, writes 38 timeouts 0
Driver 5: ok, SG min 0, mspos 103, reads 30938, writes 38 timeouts 0
Date/time: 2022-03-20 19:20:04
Slowest loop: 78.87ms; fastest: 0.05ms
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 4.5ms, write time 1.4ms, max retries 0
=== Move ===
DMs created 125, segments created 31, maxWait 203567ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 358986, completed 358977, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 4], 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 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters 3 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.7
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X171.425003 Y45.29912 E.186246311" 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: pos 142.03, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
Extruder 1: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
=== CAN ===
Messages queued 227184, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 126215/0/0
Tx timeouts 0,0,126214,0,0,100968 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 18.39ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- Ethernet -
State: active
Error counts: 0 0 0 0 0
Socket states: 5 2 2 2 2 2 0 0

Same thing with M591 D0

M591 D0
Duet3D rotating magnet filament monitor v3 on pin io5.in, enabled, sensitivity 25.40mm/rev, allow 50% to 150%, check printing moves every 12.7mm, version 3, mag 131 agc 64, measured sensitivity 26.03mm/rev, min 95% max 104% over 625.4mm

Phaedrux

Alright, let's replace the sensor. When and where did you purchase it?

BoA

@phaedrux I bought it from Hobbystore, around IX.2020

I have 2 of them, and can swap to check if this issue is still there.
In fact I have no idea why I did not do that already.

I will test 2 cases:

use second one and second wiring, just adjust the config to completly eliminate path from the board to sensor and sensor itself
swap the seonsors only, so the wiring will be the same.

BoA

I did a lot of testing, printing and now from denial I moved to acceptance. The actual cause of the problem was the wiring harness. Not sure why and how, once per few hours it has to loose connection somewhere.

I swapped sensor, ioport, and... wiring.
So I guess, as @Phaedrux stated somwhere here, 3.3 was not very good at reporting this type of error. Apparently 3.4.... is much better in this area

Heh...

Phaedrux

Well at least you got it figured out.

What was the wiring like before, and what did you change it to?

BoA

@phaedrux I just used second harness. Identical as the previous one. Movement propagated from extruder through reversed bowden tube to the sensor causes it to move very slightly and during the long time the wire start breaking. I see no other explanation.

WapuraRalf

@boa I have the same issues. I also have two sensors on a dual extruder. I understand that too little or too much movement is an issue to to stop the print. However the Sensor errors I saw until now are happening after a few hours but after resume the print runs fine for hours again. So why isn't there a way of ignoring those single errors and only trigger a stop if it is keeping reporting errors?

Phaedrux

@wapuraralf Take a look at this thread for a way to use conditional gcode to gain further control over what happens on errors you think may be spurious.

https://forum.duet3d.com/topic/27847/filament-error-g-usage-help-avoid-pausing-on-sensorerror/5?_=1654287075525

Otherwise, please start a new thread with your issue in the filament monitor forum.