Prusa Connect and Filament Management (Spoolman)
I am new Core One owner and as so many other users I want to track my filament usage. Previously, I used a Klipper based printer with Spoolman. I was exploring options to use that with my Prusa printer and it turns out that this is harder than I expected.
This is exacerbated as my printer seems to stop responding to ethernet (and wifi) periodically. I so far had three support sessions on that with no progress except trying wireless hotspots, different routers, switches etc without success. At the same time other devices and the Buddy cam work well. Guess that is another topic.
I found those options:
1. Use FilaBridge. It connects to PrusaLink and updates Spoolman. You select the current spool in the UI. You have to do that before the end of the print. It will not warn you if your spool does not contain enough filament. By design it is somehow racy. If downloading the Gcode fails (or is too slow) it won't update Spoolman. If you start the next print to fast and it did not see the FINISHED state it will not update. With my somehow broken network on the printer this is not reliable at all. Also it neither will manual filament changes (via G-Code) or filament runouts. It cannot handle canceled job (will assume all filament has been used). Plus: It does not care how your print started (USB, PrusaConnect, PrusaLink)
2. Use Octoprint. This works pretty well in general. When printing via the Web UI you get a nice filament selection dialog and it will warn you if your spool does not contain enough filament. However, there seem to be serious limitations and numerous bugs between xBuddy and Octoprint. Buddy cam also requires some additional hacks to work. While this is more reliable (since ethernet and wifi on the RPi is super stable) it caused other issues and overall seems fragile. It will not work for prints directly via PrusaConnect/PrusaLink or via USB.
3. There are a few ESP32 based approaches with NFC readers which also use PrusaLink and suffer from similar issues as (1).
4. If you know any other option please let me know!
So how could we do better? What if we could get all the data we need from Prusa Connect? I looked into that and it seems possible. Here is how:
1. We can get the print history for each printer
2. For each job we can get events to see if any filament runouts/changes occured (code #31829) and when
3. Via the material_quantity api we can get the used material from start to changed and change to end (or even with between multiple changes). That also allows us to get an accurate filament usage for canceled jobs (unlike the PrusaConnect UI).
With that we can compile a list of jobs with filament usage (including manual changes and runouts). We can either select the spool in advance (like FilaBridge) or render a list where you can choose the used spools afterwards. Personally I would like to choose the spool in advance but to be able to correct mistakes later on (and it should fix that in Spoolman for me).
Downsides for that approach:
1. It only works for prints via PrusaConnect (PrusaLink, USB and serial are ignored).
2. PrusaConnect API is not officially documented/versioned and we rely on it. It might change and break stuff.
3. This probably won't work for toolchanger/INDX printers. The material_quantity API clusters by material. For the XL or INDX we would need on value per extruder.
I wrote a proof of concept script for this and based on my 176 prints it works extremely reliably and seems to be very accurate. Performance seems to be fine too. I will turn this into a small python web app for my personal use. Let me know if you are interested.
Ideally this would be part of PrusaConnect somehow (if you know how to make that happen let me know).
RE: Prusa Connect and Filament Management (Spoolman)
Hi @jobda
I'm having similar issues with the Core One constantly dropping off from PrusaLink and PrusaConnect and the only thing that can be done at that point is reset the printer (which I unfortunately need to do manually and be near the printer for that) -
It's a real pain - I would love to know if you manage to solve this (I too tried adding routers, hotspot, relocating my printer - nothing worked)
but on the main topic, I'm also trying to better integrate and automate my spoolman with Prusa ecosystem, every solution suffer it's own issues and in general it requires a lot of tinkering - I much rather implement an extension to Prusa slicer and have Prusa dev team approve that
RE:
Hi @jobda
I'm having similar issues with the Core One constantly dropping off from PrusaLink and PrusaConnect and the only thing that can be done at that point is reset the printer (which I unfortunately need to do manually and be near the printer for that) -
It's a real pain - I would love to know if you manage to solve this (I too tried adding routers, hotspot, relocating my printer - nothing worked)but on the main topic, I'm also trying to better integrate and automate my spoolman with Prusa ecosystem, every solution suffer it's own issues and in general it requires a lot of tinkering - I much rather implement an extension to Prusa slicer and have Prusa dev team approve that
I solved the connectivity issue in the meantime. I was using ethernet on my printer and it periodically dropped out. It turns out this was caused by Wifi. Even if you switch to ethernet that Wifi module stays connected and it seems to have issues with my network. They are currently sending me a new module. I guess this is more of a software problem but I get that they want to rule out any hardware defects. Without wifi its 100% stable for me. Steps to take: Reset network config and then do not setup Wifi.
I started to implement some Prusa Connect extensions (see https://github.com/jabdoa2/prusaconnect-essentials ). I also looked into all the available APIs. It seems out best call is the following:
1. Get jobs + gcode from PrusaConnect
2. Setup syslog via ethernet on the printer (can be done in G-Code from the Slicer)
3. During print listen to syslog + metrics
4. We will see filament runout (as injected G-Code) and can react accordingly.
4a) We account this filament change
4b) We either get the used filament from G-Code (straightforward to parse). Getting the exact position is a bit tricky but possible.
Option 1: We use the metric "sdpos" which gives us the current bytes in the file. We got the file so we should be able to find the line. This is easy in theory but I did not yet find a way to reliably jump to a specific byte in compressed "bgcode". In normal gcode files that is almost trivial. This would require some engineering for bgcode but would be possible.
Option 2: We use the metric "cmdcnt" which gives us the index of the executed command since printer start. We need to store the offset when the print start to get the current one but with that its easy for gcode and bgcode. We might be off by a few commands due to injected commands (i.e. filament runout) but that does not matter in reality.
Alternatively we use the PrusaConnect material_quantity API. Currently only works for one extruder though.
5) All we would need now is a GUI. I personally don't like to build GUIs. Maybe we can hook into PrusaConnect via a userscript in the browser and just extend the existing UI there. I don't like to jump to a separate tool. Should not be very hard to do.
Even if this is not a solution for eternity (what is anyway) it will at least show how this could look in PrusaConnect.