tardy agate
All of a sudden everytime I change filament during a print, the printer shuts down...
I did update Kalico to most recent, along with Mainsail and AFC Klipper Add On
TLDR; ramming setting in slicer were enabled, once disabled successful changing filaments
livid thistleBOT
<@&1304550334839918672>
Please run this debugging script when not printing and post the resulting link in chat.
tardy agate
Line 67282 in klippy log states: Filament Sensor tool_end: runout event detected, Time 8621.38
which I think cascades to cause the issue...
Heater extruder approaching new target of 265.000
Filament Sensor tool_end: runout event detected, Time 8621.38
Toolhead runout detected by tool_end sensor, but upstream sensors still detect filament.
Possible filament break or jam at the toolhead. Please clear the jam and reload filament manually, then resume the print.
AFC debug: setting error state True
Filament Sensor tool_start: runout event detected, Time 8621.83
Toolhead runout detected by tool_start sensor, but upstream sensors still detect filament.
Possible filament break or jam at the toolhead. Please clear the jam and reload filament manually, then resume the print.
AFC debug: setting error state True
Stats 8621.9: gcodein=0 mcu: mcu_awake=0.003 mcu_task_avg=0.000005 mcu_task_stddev=0.000008 bytes_write=1027260 bytes_read=874222 bytes_retransmit=17 bytes_invalid=0 send_seq=43215 receive_seq=43215 retransmit_seq=3 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=40 upcoming_bytes=0 freq=400014990 toolhead: mcu_awake=0.020 mcu_task_avg=0.000019 mcu_task_stddev=0.000040 bytes_write=887144 bytes_read=843960 bytes_retransmit=9 bytes_invalid=0 send_seq=69478 receive_seq=69478 retransmit_seq=2 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=11999661 adj=11999209 Turtle_1: mcu_awake=0.000 mcu_task_avg=0.000002 mcu_task_stddev=0.000002 bytes_write=164013 bytes_read=147941 bytes_retransmit=9 bytes_invalid=0 send_seq=5227 receive_seq=5227 retransmit_seq=2 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=41 upcoming_bytes=0 freq=399988937 adj=399974051 sd_pos=101486 heater_bed: target=110 temp=110.0 pwm=0.345 beacon: mcu_awake=0.000 mcu_task_avg=0.000000 mcu_task_stddev=0.000000 bytes_write=115104 bytes_read=1080411 bytes_retransmit=0 bytes_invalid=0 send_seq=10545 receive_seq=10545 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=31998728 adj=31997502 coil_temp=68.8 refs=0 mcu_temp=68.33 supply_voltage=3.002 Raspberry_Pi: temp=42.4 mcu: temp=43.3 toolhead_mcu: temp=60.9 Chamber: temp=45.7 Turtle_1: temp=50.3 sysload=1.03 cputime=252.367 memavail=7252204 print_time=1620.949 buffer_time=3.919 print_stall=0 extruder: target=265 temp=252.7 pwm=1.000
Stats 8622.9: gcodein=0 mcu: mcu_awake=0.003 mcu_task_avg=0.000005 mcu_task_stddev=0.000008 bytes_write=1027522 bytes_read=874646 bytes_retransmit=17 bytes_invalid=0 send_seq=43232 receive_seq=43232 retransmit_seq=3 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=400014974 toolhead: mcu_awake=0.020 mcu_task_avg=0.000019 mcu_task_stddev=0.000040 bytes_write=887576 bytes_read=844562 bytes_retransmit=9 bytes_invalid=0 send_seq=69527 receive_seq=69527 retransmit_seq=2 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=11999660 adj=11999210 Turtle_1: mcu_awake=0.000 mcu_task_avg=0.000002 mcu_task_stddev=0.000002 bytes_write=164088 bytes_read=148045 bytes_retransmit=9 bytes_invalid=0 send_seq=5230 receive_seq=5230 retransmit_seq=2 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=399988949 adj=399974102 sd_pos=101486 heater_bed: target=110 temp=110.0 pwm=0.345 beacon: mcu_awake=0.000 mcu_task_avg=0.000000 mcu_task_stddev=0.000000 bytes_write=115110 bytes_read=1080767 bytes_retransmit=0 bytes_invalid=0 send_seq=10546 receive_seq=10546 retransmit_seq=0 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=31998727 adj=31997500 coil_temp=68.8 refs=0 mcu_temp=68.33 supply_voltage=3.002 Raspberry_Pi: temp=42.8 mcu: temp=43.2 toolhead_mcu: temp=60.8 Chamber: temp=45.8 Turtle_1: temp=50.2 sysload=0.95 cputime=252.495 memavail=7254656 print_time=1620.949 buffer_time=2.919 print_stall=0 extruder: target=265 temp=254.8 pwm=1.000
Exiting SD card print (position 101515)
Macro PAUSE called recursively
Macro PAUSE called recursively
Unhandled exception during run
Restarted firmware and it shows tool start and end empty
And lane is trying to unload but it’s not moving
using jabberwocky toolhead, tested tool start and end switches by running a piece of filament through and its registering detected/empty
sharp latch
Did filament actually run out in your toolhead then? Or was filament still present for both sensors? If this happened during a lane change then it should not have called pause
tardy agate
filament did not run out
i assume it was pulling it back to perform the filament change, and it thinks it a runout?
and called a pause and then another pause?
sharp latch
Looking at a log it was not even in a toolchange when the error was thrown
To me this seems more like your switches are not seated all the way causing the switches to bounce, or divots in your filament causing this. Its just really weird how start and end sensors are basically triggered at the same time. You can add a debounce of 1 or 2 as this might help
tardy agate
how do I add a debounce?
sharp latch
you set debounce_delay: True in AFC.cfg(this would be for all sensors) or just add it to your AFC_extruder section, more about the debounce logic here
tardy agate
let me explain whats happening...
i have a filament change at layer 5.
printer starts, load lane 1, does the poop, starts print job, prints the skirt, prints the tower, starts the print job, prints 5 layers, then goes to th tower and then starts to pull the filament back and then shutdowns dowjn
testing to see if this error ocurs when i do a munual change using t0, t1, t2, t3...
sharp latch
Well setting the debounce to 2 would help with the toolchange, but I should see something like CHANGE_TOOL: cmd-T0 in the log when the change happens, I am not seeing that but instead the pause logic because the runout logic is being triggered
Before 8621 timestamp I should see the printout
tardy agate
thats what i saw, not sure whats causing the runout login?
sharp latch
We already have an issue to fix the recursive logic error, just have not found a good way to replicate it. But your log now gives me a good way to hopefully replicate so I can fix this, but still does not explain whats causing the sensors to go false before the toolchange has even started
tardy agate
so doing a manual change works, t0->t1->t2->t3->t1
let me add debounce and see if it helps...
is there a way to disable filament runout?
sharp latch
tardy agate
ok let me try debounce settings then if that does not work, i'll start another print job then disable the prep sensor while it starts and see if its able to sucessfully perform the change
i add debounce_delay=True to afc.cfg and its saying unable to parse option debounce_delay in section AFC
sharp latch
oh duh, my bad. It should be something like debounce_delay: 2 where the number is number of seconds to delay
tardy agate
ok that worked...let me test print again
tardy agate
OK debounce paused the print but the runout still happened...
disabling runout to see behavior
sharp latch
still happened at the tool change?
sharp latch
Oh looks like you have ramming on in your slicer, thats could be causing it
tardy agate
it did the same thing even though i disabled the tool start switch...
sharp latch
tool end is still enabled, gotta disable them both
tardy agate
in orca?
sharp latch
I think so
sharp latch
normally toolhead just moves to tower and then a change happens, that purging at the tower is not normal
tardy agate
so far so good, 1 filament change successful!
2nd filament change success!
looks like we're good now...thank you so much for your help!
sharp latch
Nice, no problem that video really helped. You still have debounce set as well?