Not showing filament usage / history

[BigJoe1979]

Thanks for your work on this. This may be related to other open issues, I'm not sure.

P1P (lan only mode) with AMS 1
Running :dev branch and updated today to the newest build

I have OpenSpoolMan setup and talking to Spoolman. It's pulling filament info from my AMS and showing the 1 Bambu spool I have.

However I have no print history and it's not tracking filament usage. Per the Docker log It seems to be having issues downloading the 3MF. On my device, the 3MF is stored in the root folder with the extracted gcode files located in the cache folder. I do have an SD card.

I've attached the Docker log and mqtt logs from the beginning of the print as well as my config file. As I understand you don't have an AMS 1 and I think the others with issues have X1 or P2S printers I'm happy to help with any testing on a P1/AMS combo. Thank you!

Docker.log
docker-compose.yml
mqtt.log

[Xento]

Could you try this image: ghcr.io/xento/openspoolman:branch_fix-prints
I didn't merge it yet.

See #78

[BigJoe1979]

Thanks Xento, made progress with that branch! It's now able to successfully download the 3MF and it does populate print history but there are some oddities. I did two tests:

First I sent a print and cancelled it just to see how it started. In print history, it added it twice - first as a cloud print which immediately showed cancelled (I don't use the cloud) and then as a local which showed as failed when I cancelled. In both cases it's not mapping to the AMS slot and defaulting to the external spool in print history. Oddly the logs seem to indicate it first found the AMS mapping but then said it was unavailable? Attached logs and screenshot as test1.zip.

Second, I sent a print and let it finish. This time it reported it as only a cloud print (1 entry in history), the docker log said it successfully mapped the AMS slot, but print history still shows unassigned. But oddly the logs and Spoolman show it did correctly deduct the usage from the correct spool (#69). If I go back afterwards and assign the spool in print history nothing changes with the usage which is good since it already deducted. Attached logs and screenshot as test2.zip.

It's in a usable state I think? Just not quite looking right.

test1.zip

test2.zip

[BigJoe1979]

Well, next print and it did the duplicated cloud / local thing again and this time did not spend the filament even if I manually assigned the spool in print history :(

docker-test3.log

[Xento]

I set my printer to lan only mode now and I will test ist against it.

[Xento]

Can you test this image: https://github.com/users/xento/packages/container/openspoolman/675501633?tag=fix-filament-mapping

[BigJoe1979]

Thanks for this. Similar to before it's creating two print history entries for some reason, but now the last one is working correctly - showing finished with the correct spool and deducted the filament used. Both show 'lan' as the source rather than cloud/local.

docker-test4.log

[BigJoe1979]

As before, the next print job didn't work. It duplicated again, but one shows cancelled while the last one now does not show finished. The last job didn't pick the spool or deduct filament.

docker-test5.log

[B1ackCr0]

@Xento Just want to mention the "branch_fix-prints" solved the problem I was having. I am just setting up openspoolman and couldn't get the filament used amounts to deduct from spoolman after a print. I tried this branch and now they are deducting and I am getting print history now. Thank You!

One thing I'm curious about is the print status: it shows Billed and Total amounts. What do these totals represent? For example: I have a file sliced at 1.5g, but openspoolman show Billed as 1.2g and Total as 1.86g. The amount deducted from the roll was 1.2g. So I'm trying to figure out where these numbers are coming from exactly. If you would rather DM your response in order to keep this thread clean, that is fine. Thanks Again!

[Xento]

This branch has some issues with the filament mapping when multiple filaments are used.
Could you try this image, it is based on the other fixes and should fix the double start and download.
https://github.com/users/xento/packages/container/openspoolman/687269927?tag=fix-duplicate-prints

The total ammount is that what the slicer says.
The slicer calulates it from used length, diameter and grams per cm³ set in the filament profile.
The actually billed is what was read from the gcode commands and calulated from diameter and cm³ from spoolman for the assigned filament.

[B1ackCr0]

@Xento Just ran a quick multicolored test on the 'fix-duplicate-prints' branch: This branch gave me the duplicate print history, where branch_fix-prints did not for me. The bottom entry showed finished before the print even started. the Type is now correct me (other branch showed I was using cloud even though I am in LAN only mode/developer on) if it is supposed to show local; or is it supposed to be lan, i'm not sure, both are right. The biggest issue is the colors are mixed. It deducted from the green filament while white was being printed, and deducted the white filament while green was being printed.

[Xento]

Hmm could you provide the logs?

In my case it works.
In the second print I switched the filament before sending it.

[B1ackCr0]

@Xento I'll try to get the logs to you as soon as I can. In the mean time, one thing I noticed right off in your screenshots is you printed by layer. I printed by object with a different color per object. You have different colors within the same object. Might be the reason?

[Xento]

This one was printed by object, first the white and then the gray objects.
This time over cloud.

I refreshed the image, maybe I build it before I synced all changes.

[B1ackCr0]

@Xento I don't know why, but now the colors are working correctly. After my previous post, I did switch back to the "branch_fix-prints" image to perhaps fix another issue I was having but turned out to be unrelated (maybe) so I switched back to "fix-duplicate-prints" image. So it could have been the syncing issue as you said. However I am still getting the duplicate entry in the print history. I am running openspoolman in a docker stack on my HAOS machine, if that matters. Spoolman is running as an add-on/app. Here are the logs I've gathered.

spoolman.log

mqtt.log

mqtt_20260221_212149.log

Now, onto the 'unrelated' issue. After my previous post, I started getting errors from the printer about "System state is abnormal; please restore to factory settings." and the X1 touchscreen becoming unresponsive. It started after using the fix-duplicate image so I switched back to the branch fix image. But I concluded it was because I had too many clients connected to the printer, causing it to become unresponsive. Once I closed out almost everything except the HA connection & OpenSpoolman, and one copy of Orcaslicer, it seemed to go away so I switched back to fix-duplicate image. I've had no trouble at all until tonight when I was running the test print. I got the error message again, but the printer was still responding to the touchscreen. At this point, I have no idea if its related to the image or not, but I thought I would just pass along the info.

Edit: Of course I would forget the docker logs! I had to start a print again, but then cancelled it after I verified the 2 print history entries.

Docker.txt