[BUG] MK4 Filament Runout - Filament Sensor won't reset and cannot be bypassed

[rianweaver]

Printer type - MK4

Printer firmware version - 5.12 Original or Custom firmware - Original

Optional upgrades - none

USB drive or USB/Octoprint USB Drive

Describe the bug On occasion when filament has run out (not during a color change from what I've seen), the filament sensor will not detect that the filament has been removed, and there's no way to force past that. It just says "Changing Filament" Remove filament from sensor.

I've tried several troubleshooting steps (magnets near the inlet, blowing air into the hole on the top of the extruder), and in the past, blowing air worked once, but it hasn't much any more.

Ideally, if the sensor doesn't detect the filament has been removed, a manual input from the user on the click wheel would allow moving past that. I think this is a firmware issue rather than hardware issue, as when the machine was reset, it did not detect any filament loaded.

How to reproduce Start a print, let it print for some time, then cut the filament just above the extruder to trigger a "runout".

This doesn't happen every time, but has happened more than once, causing a loss of print.

Expected behavior Machine detects that the filament has been removed, and if not, there's a way to push forward regardless Top_0.3mm_PETG_MK4IS_6h56m_139.837g.zip

G-code It has happened on several files, but most recently with this file

Crash dump file Please send the crash dump file to Prusa by emailing it to reports@prusa3d.com. Sharing this file is important and helps us investigate the bug.

Do not share the file publicly, as the crash dump contains a raw snapshot of the printer's memory and may include unencrypted sensitive information.

Video Please attach a video. It usually helps to solve the problem.

[alexsporn]

This happened to me too and I had to disconnect the filament sensor and reconnect it to be able to continue with the filament change and not loose the print. I agree that there should be a manual user override on that screen and maybe even display the state of the sensor.

[rianweaver]

My same machine was having issues today changing filament outside of a print, so I'm less sure it's just a software issue.

Can this "Bug" be moved to a feature request to allow bypassing the "remove filament" block when the sensor is misbehaving?

[TechnoSwiss]

I'm not sure how much similarity there is between the firmware on the XL and the MK4, but I've had this exact same issue on the XL 4 times now.

[bkerler]

This is a mechanical issue and I assume it might need a redesign of some nextruder parts. This shouldn't happen if the sensor was calibrated correctly and there are no filament strings in the filament sensor channel. Lowering the temperature to reduce the filament tip string might help. This "bug" happens especially with a lot of toolchanges / filament changes and the Prusa Devs are aware of it (see MMU3 blog entry).

I will have a look if there is indeed a fw bug anyways, but I don't think so as it seems that can't be reproduced easily.

[bkerler]

@rianweaver you could try disable the filament sensor for that. Adding a "skipping" function would be counter-productive as filament strings entering your nextruder gears might damage them, so cleaning is highly recommended. However I fully agree skipping might be helpful in order to prevent loosing a print if there is just a "misinterpretation" of a filament sensor value.

[TechnoSwiss]

I've pulled the reverse bowden tube out of the Nextruder when this has happened to me, opened up the idler so I could shine a light up through the filament path, run filament through both directions to verify there's nothing left in there to trigger the filament sensor. The sensor doesn't appear to be clogged, catching on anything, or facing any other physical issues. It acts like it's not functioning, but looks clear, and as soon as the printer is reset normal function returns without any physical clearing/cleaning of the sensor. That really feels like a firmware bug to me, unfortunately I haven't found a way to reproduce it, other than each time it's happened to me my printer had been on (not printing, but powered up) for several days.

[bkerler]

@TechnoSwiss the behaviour of the XL is different as it is being a ToolChanger setup. I'm not totally familiar if the filament sensor setup is similar on the XL but I highly doubt that.

[TechnoSwiss]

The toolhead is different between the two because of the tool changer, but also since they're both using the Nextruder are also very similar. They don't have instructions for the filament sensor in the toolhead for the XL yet and Prusa support sent me to the MK4 page because "take a look at the filament sensor in the toolhead using this guide (The toolheads on the XL are largely alike with the MK4 nextrudder)". From the information I've gotten from Prusa support and their apparent shared code base, I suspect this issue is probably common between them. Maybe I'm wrong and miss-understood how much of the firmware is shared.

[i0n0s]

Hello, I've the same problem as described above. The printer doesn't detect the filament removal and is stuck. This has only happened on filament runout, never when changing/unloading filament. It prevents me from printing with a near empty spool since most filament runouts will result in an unfinished print.

[jwatson5]

I've had this issue happen several times on the MK4. It seems to happen more when I have the printer enclosed and the ambient air temperature is warmer. This may be a hardware issue, but it is most certainly a firmware issue (either bug or feature is not relevant to me). I've lost large prints that cost money. The firmware needs some way to recover from the hall sensor not working properly. I agree you may not want a complete skip, but something needs to be available to simply avoid the printer being unresponsive if the sensor thinks the filament is still loaded when everything is clear. A printer reset ruins the print. Prusa has always been good at this and not sure why this is being discussed so much when the firmware team just needs to make the change process a little more robust to handle abnormal sensor states. Please work on this.

[bkerler]

@jwatson5 In order to fix a possible fw bug, it's important to know on whether the problem is hardware or software related.

If the sensor does return a value indicating that the filament is loaded, there is nothing that could be fixed in the firmware unless the firmware doesn't read out the sensor value anymore, which likely shouldn't be the case. That's why the support should be contacted first, so they can rule out hardware issues.

So in order to sort out this problem, it would be helpful to see the actual sensor value when the runout error happens vs the normal sensor values with and without filament to see if the filament sensor value is being updated at all.

[bkerler]

This is for later reference:

1. Read out the sensor value via adc, check if within span which has been set up upon self-test calibration https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/src/common/filament_sensor_adc.cpp#L52-L54

2. Handled within cycle process in ToolHasFilament, then being checked in GetSideFSensor (extruder_state): https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/acf08f978f5480478de77de98cd22502aefea348/src/common/filament_sensors_handler.cpp#L421. Important state values here: fsensor_t::HasFilament and fsensor_t::NoFilament

3. Processed in PrintPreview::check_extruder_need_filament_load, which is adressed in check_extruder_need_filament_load_tools_mapping: https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/acf08f978f5480478de77de98cd22502aefea348/src/common/marlin_print_preview.cpp#L229 Returns false if Filament needs to be loaded

4. If print has ended on the extruder, filament sensor runout won't be handled, checked in queue_filament_load_gcodes: https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/acf08f978f5480478de77de98cd22502aefea348/src/common/marlin_print_preview.cpp#L291-L317

5. Check in a loop if the filament has run out while extruding in PrintPreview::stateFromFilamentPresence: https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/acf08f978f5480478de77de98cd22502aefea348/src/common/marlin_print_preview.cpp#L282-L285

6. Main state machine: https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/acf08f978f5480478de77de98cd22502aefea348/src/common/marlin_print_preview.cpp#L261-L290

[bkerler]

Maybe also related: issue #3776, but here physical issue

[i0n0s]

This problem just happened for me during a manuel filament change. There I could see the status of the sensor which stayed at "filament inserted". With some reinserting filament and removing, I could move the sensor to "filament removed". Long story short: This was a physical issue on my side too.

[jwatson5]

@bkerler - Thank you for the response and the specificity. I don't think I explained my thought process very well in the above post. I think it may benefit to describe it a little more abstractly.

The problem isn't so much the interaction between the firmware and the hardware, but the interaction between the firmware, hardware and human operator. From my perhaps simplistic understanding, the filament sensor is used in one of the following operational conditions:

1. The extruder has no filament and needs it loaded
2. The filament has reached the end during a print and needs to be loaded
3. The operator for whatever reason would like to change the filament (unloaded and loaded)

I was pleased to see these acknowledged in the much improved firmware interface provided by the buddy board. The only conditions above where the operator is not directly involved is step 2. In that case, if the hardware sensor has failed, the firmware could do nothing about it. The extruder would simply continue to operate in a not ideal state.

For conditions 1 and 3, the operator is directly involved with the firmware and indirectly involved with the hardware sensor. Therefore, the firmware should acknowledge this and give the operator alternative options in the event of a failed sensor (because then the operator can act as the sensor). Thought not directly related to the filamant hall sensor, the current buddy firmware UI does a good job at asking the question about additional purging during a filament change.

What the firmware currently does not do is allow for the operator to recover in the event of a filament sensor mis-read. I just tested this today and it is tricky to get the printer back operational. In this case, the filament sensor correctly detects condition number 2 above during a print. The printer then enters the wait state until the operator ineteracts. The operator interacts and proceds to condition 3 above (because of the small amount of filament left in the extruder). During this process, the buddy firmware UI heats and unloads the filament and asks the operator if the filament unload was successful. There is still filament in the extruder and the sensor is reporting the presence of filament. The operator can choose to remove the filament either before or after pressing yes (this does seem to provide different results with my printer, but that does not matter as what happens next). If the filament sensor does not read the removal of the filament correctly, the firmware UI is stuck at waiting for the filament to be removed (even though it is removed). I can open up the extruder and see that there is no visible debris in the gears and do a number of things to verify there is indeed no filament in the extruder. In this condition, I have followed some sugesstions on posts around that say just keep sticking filament in and taking it out and the sensor will finally read it and the firmware will respond. Sometimes, nothing has worked and I was forced to reset the printer and lose my print job. This is my point above about it being a firmware issue... however, it is within the realm of the firmware/operator interaction and not with the firmware/sensor. The operator need an options to tell the firmware that the filament is removed in the case of unload (and conversely in the case of loading) when the sensor is not reporting correctly. Because the operator is present, the firmware can and probably should allow for the operator to act as the filament sensor.

I browsed through the code you sent and those source files seem to only be gathering states from the sensor. I didn't have time to do an extensive review of the firmware code, but the proper location to address the issue I point out would probably be somewhere around the handing of the comment description here:

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/acf08f978f5480478de77de98cd22502aefea348/src/gui/screen_menu_filament.cpp#L52C1-L68C2

Again, I think this would likely be a firmware issue allowing the operator a little more control so as not to unnecessarily lose a print (especially a large one when this circumstance is even more likely to occur). In this way, the firmware enables the operator to operate. I am aware of the obvious risks involved with having the firmware continuously try to load filament when there is filament stuck, but I personnally have always benefited from more control and accepted those risks. I also think that fits with the Prusa way better.

This may have not helped at all and I do appreciate you looking at this. I'm not dissapointed with the buddy board because of the many updated features, but I do feel this would be an improvement. This only happens to me somewhat frequently and may be related to heat, but it is annoying enough for me to post.

[bkerler]

@jwatson5 I will closely monitor and once I get the filament sensor for my dev board, I will do some tests to ensure that the state machine isn't causing trouble here. Yes, for this issue I won't have a look at user interaction based things, as these work just fine. The fw does handle a "runout" condition, but that requires that the filament sensor detects that no filament is there and also that the print hasn't stopped (means gcodes are still queued). This will of course fail if the filament sensor (hall sensor) for what reason thinks that there is still filament loaded even though the filament did run out, which can easily happen with the current design of the nextruder and hall sensor (be assured that the Prusa Devs are already aware of it and worked on similar issues for the MMU3). Especially the filament tips being stringy cause here some trouble.

[jwatson5]

@bkerler Thank you. I understand that if the sensor and nextruder design were improved, it would certainly solve the problem. I also agree that there is inconclusive data on if there are user interaction problems. I am an HCI researcher and print as a hobby, but I would love to coduct user studies to provide data to support your conclusion that the UI works just fine. I'll look for the proper place to submit that and hopefully someone will be able to interact with the firmware developers if the study data suggest there could be issues with the interface.

Again, thank you for helping me navigate these issues.

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.