Problem with Magnetic Sensor
-
Thank you for getting back to me so quickly. Yesterday night I did a couple of test prints, and for the first time since I installed it, the sensor worked flawlessly. I used a different color of filament, but the material and brand were the same, so I doubt that's the reason. Also, for this sensor, the filament should be irrelevant, unless it's slippery of course.
Here is the full M122 output, there are a couple of errors, but the range is ideal. I will probably replace the wire from the Duet to the sensor with a shielded one and keep monitoring the output; hopefully, the issues were just transient.
14/10/2019, 22:35:07 M122 === Diagnostics === RepRapFirmware for Duet 2 Maestro version 2.04RC3 running on Duet Maestro 1.0 Board ID: 08DJM-956DU-LL3T0-6JTD8-3S86Q-1U2AP Used output buffers: 3 of 24 (15 max) === RTOS === Static ram: 19796 Dynamic ram: 93912 of which 0 recycled Exception stack ram used: 392 Never used ram: 16972 Tasks: NETWORK(ready,652) HEAT(blocked,1272) MAIN(running,3904) IDLE(ready,160) Owned mutexes: === Platform === Last reset 01:43:23 ago, cause: power up Last software reset at 2019-10-13 14:43, reason: User, spinning module GCodes, available RAM 17152 bytes (slot 1) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0400f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 15.0MBytes/sec SD card longest block write time: 81.2ms, max retries 0 MCU temperature: min 40.3, current 47.6, max 50.3 Supply voltage: min 23.6, current 24.1, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: standstill, read errors 0, write errors 0, ifcount 9, reads 36374, timeouts 0 Driver 1: standstill, read errors 0, write errors 0, ifcount 9, reads 36374, timeouts 0 Driver 2: standstill, read errors 0, write errors 0, ifcount 9, reads 36374, timeouts 0 Driver 3: standstill, read errors 0, write errors 0, ifcount 9, reads 36371, timeouts 3 Driver 4: standstill, read errors 0, write errors 0, ifcount 6, reads 36377, timeouts 0 Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 36378 Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 36377 Date/time: 2019-10-14 22:35:06 Slowest loop: 169.18ms; fastest: 0.07ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 0, FreeDm: 160, MinFreeDm: 112, MaxWait: 672759ms Bed compensation in use: mesh, comp offset 0.000 === DDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = 0, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.1 Heater 1 is on, I-accum = 0.5 === 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 lcd is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 86.83ms; fastest: 0.03ms Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 Interface state 5, link 100Mbps full duplex === Filament sensors === Extruder 0: pos 197.23, ok, measured sens 25.18mm/rev min 96% max 105% over 5199.2mm, errs: frame 6 parity 0 ovrun 0 pol 8 ovdue 0 -
I did some more prints, unfortunately the results have been consistently not good; I thought it might be noise, so I have changed the cable to a quality shielded one yesterday, but the issue remains. I get negative low ends of the range very quickly after starting a print. Here is the M122 output after a long print, with the shielded cable:
10/22/2019, 7:22:19 AM M122 === Diagnostics === RepRapFirmware for Duet 2 Maestro version 2.04RC3 running on Duet Maestro 1.0 Board ID: 08DJM-956DU-LL3T0-6JTD8-3S86Q-1U2AP Used output buffers: 3 of 24 (17 max) === RTOS === Static ram: 19796 Dynamic ram: 93912 of which 0 recycled Exception stack ram used: 396 Never used ram: 16968 Tasks: NETWORK(ready,652) HEAT(blocked,1272) MAIN(running,3904) IDLE(ready,160) Owned mutexes: === Platform === Last reset 09:35:17 ago, cause: power up Last software reset at 2019-10-13 14:43, reason: User, spinning module GCodes, available RAM 17152 bytes (slot 1) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0400f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 9 SD card 0 detected, interface speed: 15.0MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 47.9, current 49.0, max 49.7 Supply voltage: min 23.6, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: ok, read errors 0, write errors 0, ifcount 12, reads 9425, timeouts 0 Driver 1: ok, read errors 0, write errors 0, ifcount 12, reads 9425, timeouts 0 Driver 2: ok, read errors 0, write errors 0, ifcount 12, reads 9425, timeouts 0 Driver 3: ok, read errors 0, write errors 0, ifcount 12, reads 9420, timeouts 5 Driver 4: standstill, read errors 0, write errors 0, ifcount 6, reads 9425, timeouts 0 Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 9425 Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 9425 Date/time: 2019-10-22 07:22:17 Slowest loop: 70.00ms; fastest: 0.08ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 0, FreeDm: 152, MinFreeDm: 143, MaxWait: 0ms Bed compensation in use: mesh, comp offset 0.000 === DDARing === Scheduled moves: 132126, completed moves: 132118, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = 0, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.1 Heater 1 is on, I-accum = 0.5 === GCodes === Segments left: 1 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 doing "G1 X50.263 Y165.759 E0.2155" 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 lcd is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 5.89ms; fastest: 0.03ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 2 of 8 Interface state 5, link 100Mbps full duplex === Filament sensors === Extruder 0: pos 39.38, ok, measured sens 25.46mm/rev min -1% max 107% over 36407.4mm, errs: frame 148 parity 0 ovrun 0 pol 37 ovdue 0@themelle Do you have any idea of what the problem might be? The print quality is good and I am using a decent filament (eSun PLA+).
-
I am discussing with my colleagues whether we would like yo to return your magnetic filament monitor to us. We'll get back to you.
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 Thank you, I'll wait for further instructions.
-
We would like you to return your sensor. We will cover reasonable postage costs. Please email sales at duet3d dot com to arrange the return.
-
I also am experiencing these exact Issues, now with the second magnetic monitor I have tried. The first had the idler parts missing and was replaced. Other than more resistance while inserting filament, I have not seen any change in the results between the two monitors.
I created a mount that places the monitor 3 mm prior to the extruder and keeps it firmly in place. Through taglia doesn't mention it, based on how he has mounted the monitor, one could assume that the printer uses a Bowden tube, as does mine. I have a Duet 2 Wifi 2.03 and other than that the M122 report looks very much the same as taglia's..
In the documentation an 'A' parameter is mentioned and I haven't tried including that, but I will and report back. What is the default for that parameter?
I have noticed that prints with little to no retractions being made, reports much more consistent than a print with several.
Lastly, I am curious as to why the need for a mm per revolution setting. The hobbled wheel has a set circumference and as long as filament is not slipping, the mm per revolution should always be the same and thus the mm per degree of rotation. I ask because the L parameter is rather elusive. I get a sensitivity reported over 10 of meters of filament, change the L parameter to that number and the reported sensitivity changes greatly, most of the time much higher and a couple of times even negative. It is just not consistent. -
@DarylMcM, I'd like to install new firmware on your filament monitors so that we can get a readout of the strength of the magnetic field at the sensor. Which country are you in, and who did you buy the filament monitors from?
-
I’m in the US and bought the unit from Filastruder.
-
@DarylMcM please drop me a line (tony@duet3d.com)
-
Quick update while waiting for tools...I reconfigured the filament path so that it is pulled straight into the filament monitor from about 20 mm away. It had followed a path where is was pulled at a slight angle as it entered into the monitor. After the modification was able to run several meters of filament with a min 97% max 110%. I have only run this one print with these results. More testing to come, but this might be something for others to investigate.
-
@DarylMcM tahnks for the report. i will have a look at this. Our test rig has everything in a straight line and constrained by PTfE tubes.
-
well, as I reported to Tony, I ran 5 meters of filament on a small job and the monitor worked perfectly. No pauses and well within the 70%/130% parameters over 3mm.
ver 3 monitor firmware reported mag 132 agc 69. generic PLA 195c 0.4 nozzle.Now I'm running a 450 meter job wood PLA filament, 200c 0.6 nozzle. mag still 132 agc still 69. No love. can't get through a layer without a pause and the sensitivity and percentage number are not consistent. I had to disable the monitor in order to continue the job. the filament is laying down perfectly, no gaps, good solid layers. No grinding, no jumping on the extruder motor.
4:05:17 PMM591 D0
Duet3D magnetic filament monitor on input 3, disabled, sensitivity 25.74mm/rev, allow 30% to 130%, check every 3.0mm, version 3, mag 132 agc 69, measured sensitivity 27.15mm/rev, min 2% max 112% over 8897.1mm4:10:58 PMM122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917DA-G4MSJ-6JTD8-3S46L-TSPRB
Used output buffers: 3 of 24 (17 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 92736 of which 20 recycled
Exception stack ram used: 452
Never used ram: 12184
Tasks: NETWORK(ready,628) HEAT(blocked,808) MAIN(running,3808) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 01:42:00 ago, cause: power up
Last software reset at 2019-11-09 15:38, reason: User, spinning module GCodes, available RAM 12408 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 40.0, current 43.0, max 43.3
Supply voltage: min 23.7, current 23.9, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, SG min/max 367/1023
Driver 1: ok, SG min/max 286/1023
Driver 2: ok, SG min/max 0/1023
Driver 3: ok, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2019-11-10 16:10:57
Cache data hit count 4294967295
Slowest loop: 2.83ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 156, MinFreeDm: 144, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 4711, completed moves: 4703, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 1
Stack records: 3 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 doing "G1 X-40.873 Y-125.908 E124.08205" 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: 242.77ms; fastest: 0.08ms
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 2
WiFi firmware version 1.23
WiFi MAC address 80:7d:3a:3f:f6:0f
WiFi Vcc 3.39, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 23376
WiFi IP address 192.168.20.25
WiFi signal strength -44dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0: pos 97.38, errs: frame 8 parity 0 ovrun 0 pol 0 ovdue 0
- WiFi -
-
Changed length of measurement to 12mm and things improved somewhat. Updated sensitivity also.
Noted a fluctuation in the mag parameter being reported.5:57:31 PM
M591 D0
Duet3D magnetic filament monitor on input 3, disabled, sensitivity 27.21mm/rev, allow 30% to 130%, check every 12.0mm, version 3, mag 131 agc 69, measured sensitivity 27.31mm/rev, min 58% max 110% over 32428.9mm
5:56:25 PM
M591 D0
Duet3D magnetic filament monitor on input 3, disabled, sensitivity 27.21mm/rev, allow 30% to 130%, check every 12.0mm, version 3, mag 132 agc 69, measured sensitivity 27.31mm/rev, min 58% max 110% over 32039.7mm -
14 hours later and About 100 meters of filament to go on this 445 meter job. After tweaking sensitivity, ratios, extruder rate, print speed and closely visually monitoring print quality, I found the filament monitor setting that work with this less than satisfying wood PLA filament.
They are not ideal, but unless one is down with running about 75 % print speed, this is what worked. Slowing the print speed increased the min reported back up to upper 60s percentage.
Extrusion at 100%, speed at 100% (80mm/sec max), temp mid range of filament noted temp range (200c in this case) and the following:**8:23:33 AM
M591 D0
Duet3D magnetic filament monitor on input 3, enabled, sensitivity 28.02mm/rev, allow 20% to 130%, check every 12.0mm, version 3, mag 131 agc 70, measured sensitivity 27.91mm/rev, min 28% max 113% over 13183.3mm(From M122report)
=== Filament sensors ===
Extruder 0: pos 350.16, errs: frame 16 parity 0 ovrun 0 pol 2 ovdue 0**
The above was taken after reloading filament this AM.Note the agc has climbed to 70 while the mag has continued to fluctuate from 130 to 132. AGC usually stands for automatic gain control and my assumption of the mag number has to do with magnetic strength, but I'm just guessing. The need for a sensitivity setting I still find remarkable, but again assuming, it is probably due to reading a magnetic rotation instead of having a direct drive.
The monitor did save my job by detecting a very slight blockage in the nozzle, noted by the tell tail curving of the filament as it is extruded. The min reported was 19%. It also properly paused the job when the filament ran out.
My big takeaway from this job is Not All Filaments are Monitored Equally. Wood filament is a strange animal anyway. I have two more runs of this job to go on this printer and I am anxious to move on to some peg jobs to see how that goes.
All in all I am very satisfied with this monitor. It would be great to have the report to include the current measured percentage. This would allow one to note the current trend. A means of distinguishing a monitor pause from a button pause would also be a fine feature.
Like any other new trick, it just takes some training to get the dog to rollover and speak.
-
@DarylMcM said in Problem with Magnetic Sensor:
Note the agc has climbed to 70 while the mag has continued to fluctuate from 130 to 132. AGC usually stands for automatic gain control and my assumption of the mag number has to do with magnetic strength, but I'm just guessing.
That's correct. The 'mag' value is after agc is applied, so will always be around the same value until the gain runs out (indicated by agc=128 which is its maximum value). So it is the agc value that gives a better indication of magnetic field strength, lower values = higher strength.
To get good readings, it is critical that when the extruder retracts filament, the filament gets pushed back through the filament monitor and turns it backwards. This is best achieved by keeping the filament path between the filament monitor and extruder drive very short and straight, and constraining the filament in that region in PTFE tubing which is only just large enough for the filament,
-
dc42, I do have a minimal distance between the monitor and the extruder entrance. About 3mm. I do not have PTFE in that small area. I do have PTFE restraining the filament from the reel to the entrance of the monitor keeping it straight.
Does the 'A' parameter of the M591 entry need to be set in order for the retractions to be Taken into account? -
@DarylMcM said in Problem with Magnetic Sensor:
Does the 'A' parameter of the M591 entry need to be set in order for the retractions to be Taken into account?
No. The default is A0 which means that actual/commanded movement will only be compared during normal printing moves, not retraction or re-prime moves. You can try A1 if you like, but it will probably give worse results.
-
I seem to be having a simmer issue. I installed the mag sensor about a week ago recently purchased from Filastruder as well. It was working okfor a couple of prints then all of a sudden it started overrunning the set parameters of R60:130 L24.8 E3.0. When I swapped out the filament to Ninja Flex ( a very soft TPU) I stated seeing under runs of ~ 30 to 35%. I adjusted the "R" value accordingly and the remainder of the TPU prints finished off ok. I then swapped out my .04 nozzle for a .8mm nozzle with PLA+ and things went south. I'm now seeing under runs down to 10% and over runs up to 330% My last print was like so:
Duet3D rotating magnet filament monitor v2 on input 3, enabled, sensitivity 25.05mm/rev, allow 10% to 370%, check every 3.0mm, current pos 259.8, measured sensitivity 25.27mm/rev, min 94% max 179% over 9348.6mm
I replaced the the cable between the sensor the E1 stop input with a twister trio to cancel out any interference but this did not make any difference.
My diag output:
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917DA-G4MSJ-6JTF0-3S86M-T9NMA
Used output buffers: 1 of 24 (12 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94232 of which 16 recycled
Exception stack ram used: 540
Never used ram: 10604
Tasks: NETWORK(ready,524) HEAT(blocked,1236) MAIN(running,1668) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 01:22:56 ago, cause: software
Last software reset at 2019-11-18 13:58, reason: User, spinning module GCodes, available RAM 10652 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: 12.1ms, max retries 0
MCU temperature: min 28.5, current 29.3, max 31.9
Supply voltage: min 23.9, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/117
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max 0/107
Date/time: 2019-11-18 15:21:31
Cache data hit count 4294967295
Slowest loop: 59.42ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 121, MaxWait: 1366776ms
Bed compensation in use: mesh, comp offset 0.373
=== 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 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 0
Stack records: 3 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: 25.93ms; 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 ec:fa:bc:01:e0:39
WiFi Vcc 3.32, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25464
WiFi IP address 192.168.1.19
WiFi signal strength -53dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0: pos 250.31, ok, measured sens 25.28mm/rev min 94% max 179% over 10057.0mm, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
3:06:28 PMFinished printing file 0:/gcodes/rEX.gcode, print time was 0h 46m
- WiFi -
-
I just purchased a filament sensor from Filastruder and set it up. My mount is not ideal according to the directions because I do not want to mount the sensor on top of the bondtech extruder that is set up as a direct drive on a Railcore. This would add a lot of moving weight. So the sensor is mounted outside the printer and there is a long ptfe tube between the sensor output and the bondtech. I was able to run 3-4 12 hour prints without issue. Now though the sensor stops and says not enough movement was detected.
Is there a way to configure the sensor to simply detect any movement over x amount of time and not try to exactly sync the movements to the print? Should I be using the switch and the magnet sensor? I tried opening up the tolerance to work over a wide range but that did not help.
Settings:
Duet3D magnetic filament monitor on input 3, enabled, sensitivity 24.70mm/rev, allow 20% to 250%, check every 3.0mm, version 2, measured sensitivity 24.82mm/rev, min 91% max 105% over 160.8mmIf you need additional information please let me know.
-
@RandyL said in Problem with Magnetic Sensor:
I then swapped out my .04 nozzle for a .8mm nozzle with PLA+ and things went south. I'm now seeing under runs down to 10% and over runs up to 330% My last print was like so:
Duet3D rotating magnet filament monitor v2 on input 3, enabled, sensitivity 25.05mm/rev, allow 10% to 370%, check every 3.0mm, current pos 259.8, measured sensitivity 25.27mm/rev, min 94% max 179% over 9348.6mm-
How close to the extruder drive inlet is the filament monitor? It needs to be very close, especially for soft filaments such as TPU. Otherwise, when the extruder retracts filament, the filament will try to bunch up in the space between the extruder inlet and the filament monitor, instead of retracting through the filament monitor.
-
A 0.8mm nozzle has four times the filament flow of a 0.4mm nozzle. To get comparable performance from the filament monitor, you should increase the measurement length in proportion. So try 12mm instead of 3mm.
-
