RRF3.4 RC2 Filament/sensor error
-
@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 standbyIf you send those commands manually does it behave the same with with the chamber heater? And is it active state with 0 temperature?
-
@phaedrux Yes. Sending manually
M141 S0 R0manually causes chamber heater switch to active with temps 0*C -
What if you just use M141 R0?
-
@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.
-
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 A0which seems not to be the case.
-
@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?
-
@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 3state is unchanged
-
How about -273?
-
@phaedrux
-273 is set and state does not change
If executed on active, it stays active, of on off it stays off -
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.204Sensor 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 0Same 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 -
Alright, let's replace the sensor. When and where did you purchase it?
-
@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.
-
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...
-
Well at least you got it figured out.
What was the wiring like before, and what did you change it to?
-
undefined Phaedrux marked this topic as a question
-
undefined Phaedrux has marked this topic as solved
-
@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.
-
@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?
-
@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.
Otherwise, please start a new thread with your issue in the filament monitor forum.
