Simple plugin to fix Prusa MK4 not reporting back filamant run out

Development
1

As far as I know, the Prusa Mk4 does not report back to Octoprint that the filament has run out and it needs changing. The Prusa Mk3 does and its really helpful on long prints.

Prusa is not making any attempt to fix this issue, despite it been raised as a defect. I have no confidence they will do.

So I started thinking about what the options are here:

  1. I could try and update the firmware but discarded that as a stupid idea. A lot of effort to learn it and no guarantee that it would work/
  2. Pressure on Prusa to implement the right command. That's still underway.
  3. Put a camera on it and train some tool or bot to recognise when the head is in more or less the right place and has been there without moving for a minute or so. No reason why it can't be done. My knowledge of bots and visual AI is limited, but a small model to train it could be done.
  4. Query the printer every 30 secs or so and see if 1. The printer has a job to print. 2. has anything extruded for 30 secs OR/AND the extruder head hasn't moved for 60-120 secs. If so send an alert out using Octotext or whatever.

The easiest option appears to be the last one, a simple plugin that checks if something is printing, something is moving (X,Y,Z) in the last 90 secs OR extruder has done something in last 90 secs.

To my mind, if the extruder is in the same position on the right of the printer (Mk4) and not moved, then its worth an alert.

So a simple plugin, that runs every 60 secs, checks if something is printing, if so it then checks what the X, Y and Z positions are, checks what the positions were 60 secs ago, if within 1% or something of those positions, then pings an alert out using the yet-to-be-found alert framework within Octoprint

So I had a look around, I have no idea how to write a plugin, but we'll cross that bridge if and when I come to it. I had a trawl through the API and I couldn't see if that information exists but I can see that a marlin code M114 returns some information. Tried in a shell and got

[...]
Send: M114
Recv: X:1.38 Y:200.00 Z:52.60 E:47.80 Count X: 0.00 Y:200.44 Z:52.57 E:47.80
Recv: ok

Looks about right as I glance at the Mk3. No idea if it works on a Mk4 as thats six hours into a 12 hour print and I am not messing that up :slight_smile:

This is all a bit high level, but does my logic stand up?

All views welcomed

Rob

2

Did you read the release notes for the firmware version 5.1.0 for the MK4?:

Scroll down or Ctrl-F for "Improved Octoprint support" Read and follow the instructions there. The filament runout sensor on my MK4 has been working for me with OctoPrint since that version was released.

3

Yes I did read those notes, yes I did add M601, no the Prusa Mk4 does not send any indication that a job has paused due to being out of filament, yes I did contact Prusa support, no they offered nothing to help me.

If you know better and an alert is sent or can be captured or something to tell Octoprint and Octotext or any other mechanism for alerting, then please let me know.

Thanks

Rob

4

If you expect some kind of remote filament runout alert via OctoPrint or its plugins, I am afraid I cannot help you. Usually I am sitting in the room next to the room with the printer and can hear the printer beep when it wants me to change the filament. The printer pauses (even for longer periods of time) until I change the filament via the display controls on the printer. OctoPrint seems to notice that the printer is paused and does not continue to stream g-code while the printer is paused. I have not lost one print because of filament runout since version 5.1 came out. This is just the same as I use my MK3S+, where I also do not rely on any filament runout alert via OctoPrint.
You probably could make an automation with Home Assistant that springs into action if the printer integration shows "paused" as status or something like that. I have not tried or checked that yet, because I did not need it. But it is something you could try.

5

I'm curious if there is anything reported over serial (shown in the terminal tab) when this filament runout occurs? If there's anything that is consistent, like "waiting on user input" or the like, then that could be used to hook with a plugin. If it doesn't report anything, then the approach of watching the response of an M114 command for changes isn't a bad idea as a workaround. Especially if you're just trying to achieve some form of alert or even pause action within the OctoPrint interface.

6

@walterlayher Hi, just reread this again and wanted to check what you said.

The filament runout sensor on my MK4 has been working for me with OctoPrint since that version was released.

So are you getting an alert in Octoprint that the filament has run out? What exactly is the Mk4 doing here? The MK4 filament sensor seems to work OK and it moves to the right side of the printer, pauses and requests me to change the filament. Octoprint stops sending gcode, which is good, so I suspect (but don't really know) that there is a transfer protocol between Mk4 and the Octoprint about when to send data. Is that what you mean by the MK4 is working and no prints lost?

I do not sit next to my Prusa's all the time and do long print runs. Some of my runs are 30+ hours and I don't want to put a new roll of filament each time just to make sure it doesn't run out.

@jneilliii

That's a good idea and I will do that now. I have an eight hour print starting so will cut the filament and see what happens in Octoprint's terminal window and report back.

7

Not a lot of interesting stuff comes back when I cut the printer. I get a single line. I seem to get the same line each time and

Recv: X:241.00 Y:-3.00 Z:20.20 E:122.39 Count X:24111 Y:-295 Z:8079

&

Recv: X:241.00 Y:-3.00 Z:20.20 E:623.97 Count X:24099 Y:-288 Z:8081

Once I have that single line above, nothing else appears in the terminal window. So suspect this is it.

The X, Y and Z are the same, but the Extruder, Count of X, Y and Z change. Not sure what the second X Y and Z counts are.

This looks like it :slight_smile:
Rob

I have removed temperature status and other sending messages.

8

I am getting no alert from OctoPrint. The printer pauses and beeps, prompting me to change filament.
Before firmware 5.1 the printer did not pause and just kept moving without filament.
I'll have to remember to look at the status of OctoPrint during the change next time, on the web page as well as in Home Assistant, to see if there is a changed printer status there that could be used for an alert mechanism. I do not interact with the printer via OctoPrint for the filament change, just via the display on the printer.

9

@walterlayher

Thanks for the prompt response. I am occasionally getting the MK4 not detecting end of filament, not had it for two weeks and just had this morning :frowning:

I couldn't see anything else in the Octoprint interface but other people are probably significantly more experienced than I am and there may be plugins that provide a little more information.

Just tried again and got

Recv: X:241.00 Y:-3.00 Z:21.50 E:48.70 Count X:24100 Y:-301 Z:8599

The Z parameter has changed.

Also sending M114 doesn;'t get a response when the printer is waiting to change filament so that idea doesn't work. I can't get the terminal window to get any response to any type of informative GCODE such as M31, M115, M114 so the only info is the RECV message

Rob

10

The above actually does look like a response to an M114, which OctoPrint should parse automatically. Please do the following.

  1. Go into the serial settings, enable the serial.log.
  2. connect to the printer, start a print, simulate a filament runout, stop the print, disconnect from the printer
  3. download the system info bundle
  4. disable serial.log

Share the bundle here (just upload the zip right here). That will give us a full log of all the communication that happened between the printer and OctoPrint and will hopefully shed some light on what might be possible and what not.

11

@foosel

Nice to talk to you :slight_smile:

I hadn't actually sent the M114 and when I the printer paused, sending an M114 didn't elicit a response the Mk4.

I've done what you have suggested but have NOT restarted the MK4 printer as I'm 4.5 hours into a print I need tonight.

I attach the ZIP file, but have I do have a copy and I am absolutely going to have a look at the serial.log myself. I'm a ex-developer, phrases like do not unpack are like a red rag to a bull
octoprint-systeminfo-20240705145310.zip (192.7 KB)

12

Ok, so, this could indeed be handled by a plugin.

The printer doesn't send a pause event, but it does send busy:processing messages and sends an M114 report on its own.

So a plugin could watch for busy:processing in the incoming messages, and query the current print head position from OctoPrint (which will have parsed that M114 response whether it was you who sent that command or the printer just auto reporting) and if matches the park position of (X,Y) = (241,-3), notify the user.

I'm a ex-developer, phrases like do not unpack are like a red rag to a bull

You may of course inspect it all as you want, the problem is that a lot of people will then zip it up again but with a wrong hierarchy (e.g. suddenly everything is in a sub folder), which means the bundle viewer won't work as well as with the proper file hierarchy. So, in a nutshell, once more a case of reducing the overhead of lending support, which helps everyone.

1 Like
13

Based on Gina's response, the plugin implementation bit you want to work with is gcode received hook.

14

I took a copy of the zip and looked through and came to much the same conclusion, though somewhat slower than you. I did miss the busy:processing though, so thats good information.

Ah, didn't know about the bundle viewer. I opened it in Emacs and checked timestamps to see what matched. Nice idea.

I'll look at whats needed to develop a plugin, never used Python, but the Octoprint pages look thorough. I might be tempted to pay somebody to do the work as I have a lot on my plate so anybody interested in doing this let me know.

Rob

15

Based on previous comments, not sure what the limitations of Octotext is, but the actual plugin to monitor for this situation would be pretty trivial for someone very familiar with the plugin ecosystem. DM me and let me know what you think this plugin would be worth to you.

EDIT: took a quick look at Octotext and it supports other plugins the ability to send message, so think that would be pretty easy to do too.

16

For reference, the counts are stepper motor steps from 0,0,0.
I noticed you have 3 different counts when you are at -3.01 in Y, that may indicate slippage or possibly rounding errors on your step per unit for your axis.

17

Thanks for this. I hope there's no slippage, the printer is new from Prusa.