Spoolman Idea 2: Store RFID Tag ID in Spoolman database when selected via AFC-Lite#364
Spoolman Idea 2: Store RFID Tag ID in Spoolman database when selected via AFC-Lite#364paxx12 wants to merge 19 commits into
Conversation
paxx12
force-pushed
the
afc-spoolman-auto-register
branch
from
8102ff0 to
b7de35b
Compare
✅ Build ArtifactsVersion:
|
✅ Build ArtifactsVersion:
|
paxx12
force-pushed
the
afc-spoolman-auto-register
branch
from
b7de35b to
1134b31
Compare
✅ Build ArtifactsVersion:
|
paxx12
force-pushed
the
afc-spoolman-auto-register
branch
from
1134b31 to
ce1d074
Compare
✅ Build ArtifactsVersion:
|
paxx12
force-pushed
the
afc-spoolman-auto-register
branch
from
ce1d074 to
2c03278
Compare
✅ Build ArtifactsVersion:
|
✅ Build ArtifactsVersion:
|
paxx12
changed the title
|
Problem: Idea: |
paxx12
force-pushed
the
afc-spoolman-auto-register
branch
from
a3fa713 to
a0a708e
Compare
✅ Build ArtifactsVersion:
|
|
Running this latest build, and RFID detection and spoolman are working great together. Swaps spools for tracking on each tool change. As soon as this current print is done, i'll test actually swapping to different filaments to make sure everything updates as expected. |
|
Same here as from Benk, everything works fine, I added the suggestion to have the contents of any loaded rfid tag printed to console for debug reasons but thats already in paxx's mind as i think this doesnt add any work / problem sources but can help see and log exactly what is being loaded in case somethging goes wrong down the line (or someone missclicks) Other than that i havent had any problems in the newst build |
|
OK Swapping spools, it does not auto detect the filament. Once loaded I have to manually select the spool for the lane, and once that is done, it keeps track of it. Is that the expected behavior? (I think the initial run I had was actually using what I had set manually previously and not auto detected like I thought) Unloading and loading a new spool, The printer UI shows all the details of the spool, but in the klipper interface, spoolman says no spool selected, and the AFC section shows the correct color spool, but "Unknown" for the actual filament type. I have been using spoolpainter to choose the spool from spoolman inventory and writing that to the tags. |
|
@benk016 Was the spool mapped already via fluidd? The Spoolpainer at this point does mapping in a different way that is not compatible with this work. This works depends on storing the mapping directly in |
|
Got it! I thought setting the spool number via RFID would map it. Is there a supported way to use an RFID to auto map? If not, not a big deal as I can easily select the spool when I load. Keeping track during tool swaps was main thing I was wanting and that part works great. |
|
@benk016 You should only have to map spool once via fluidd for each side of the spool, and that spool should be auto mapped each time when loaded. You can see what happens in a Console. If the mapping of the spool was there, or whether the new one was created. |
|
OK that makes sense! I haven't tried re-loading a spool I assigned already so I'll try that next. |
|
If we settle on specific solution this would be then implemented in every app. I might also prepare a migration app to scan the tag on mobile and auto-migrate all. |
|
@matissrapsa I understand the idea, but also: this means there are two ways that has to be maintained and tested. I want to avoid having unnecessary implementation that can break. I'm more inclined that you perform migration once and you use a expected system moving forward. |
|
I have no issue with a one time migration. I've just been setting all this up and learning as I go so I already expected to need to re-do some of it. I have plenty of spools in spoolman that I can test any migrations on as well. I think I've only mapped 6 of the around 45 or so spools so far. |
|
@benk016 The thing is that in this model proposed by this PR, it is possible to extend it to not program tags at all. Just anything random as an unique identifier, like a barcode or serial number. In spoolman you create a spool, and configure this identifier. This is enough, and you never really have to program NFC tags. |
|
I've already put an RFID tag on all my spools. I started with just a QR code but after moving to your firmware that opened up the RFID, and it only wanting to use the printer camera to scan, I decided to label everything with RFID. |
|
Sure, it just matters that you have any RFID tag on the spool, as ultimately this is identification mechanism. |
✅ Build ArtifactsVersion:
|
|
3DMRP v0.4.0 is out! We fixed a ton of issues and also created a mobile browser SPA (single page app) that syncs with the 3DMRP docker host in real time (not trying to compete with SpoolPainter, this just seems easier to start with and allows for local features, downside is it will never work with iPhones (RFID locked down)). This is based on the latest #364 artifact. I'm still on board with that approach, but my workflow also writes the spool_id for a source of truth. RFID Onboarding a spool will also populate the lot field in Spoolman ahead of it going onto the U1 or any other printer. AFC lite will recognize that spool as what it really is in Spoolman as soon as its loaded physically (no need to load it from the ops panel). Testing PR364 so far has been mainly load/unload cycles, I haven't printed much with them yet (2 out of 3 of my U1 printers are running it for AB testing). Give that a shot if you like, I appreciate any feedback I can get. |
|
I have the same problem as benk016. The spool is correctly recognized during loading, but is subsequently marked as "unknown." |
|
The detected filament reverting to unknown after the filament load operation is still present in build 78a6865. |
|
I made some big progress with all of this. Everything works as expected, starting to print on this release. |
|
I'm starting to do production print testing with 78a6865 and am seeing what benk016 already hinted. 
The next filament was lane 2 and it did the same thing again, dropped the association on 4 and stopped with a runout on 2. I wasn't able to recover from that one by re-loading. My next best course of action is to go back to 2d07846 and try to run the same job again. 
|
|
After downgrading the machine to 2d07846, it prints again without any major issues. Some AFC lanes still lose assignment but at least the printing continues without any runout errors. 
|
|
The only issue I have had on this latest release is the filament assignment getting lost after toolhead loading 100% of the time. I have 2 U1s now and both experience this exactly the same way. The only time filament run-out has not worked for me was when I didn't have a matching filament in another lane and was trying to use a similar filament. Even when selecting which lane to use on run-out, it just errors out about running out of filament. The AFC lane going back to unknown happens if you have a 2nd spool inserted but not all the way loaded as well. When filament run-out detects it's ran out it will switch so the other lane and do a load operation and it still clears out the assigned filament on AFC. A potential work around might be to either re-detect filament after a load operation, or force another spool ID set at the end of loading an extruder. |
|
I can confirm what benk016 said now. Running on 2d07846, it's the same thing. On insertion into the feeder, AFC lite recognizes the filament and assigns it a Spoolman identity. Everything settles and Moonraker reports everything correctly on the API as well. It also reports "Loaded" status, which isn't quite true, because the filament is only 80% down the PTFE feeder tube at that point. The only way to get a job started I have now is to walk up the printer, go the loading screen and actually load filament on the slots it already recognized, which then activates each tool head and feeds it into the respective extruder. What I observed so far is that exactly at that point, AFC lite blanks out the filament information from the Spoolman assignments one by one that were just still there. It does it as soon as it picks up the respective tool head. So, what we have now is a couple of problems:
@paxx12 I can make a video if you want to see it, it's quite repeatable now in my environment. |
… RFID cards - Move filament config methods from AFC_lane to AFC_lane_spoolman - Auto-detect RFID cards and bind to Spoolman spools via lot_nr field - Support comma-delimited card_uid values in lot_nr (card_uid:XXX,card_uid:YYY) - Add SET_SPOOL_ID and REFRESH_SPOOL gcode commands per lane - Implement webhook callbacks for Spoolman proxy integration - Remove card_uid from other spools when binding to new spool
- Update afc-lite.md with comprehensive Spoolman auto-binding documentation - Document RFID card detection flow and lot_nr format - Add gcode commands reference (SET_SPOOL_ID, REFRESH_SPOOL) - Add respond_info notifications for card binding/unbinding actions - Update limitations section to reflect now-supported features
- Add automatic card_uid removal from spoolman when unbinding via SPOOL_ID=0 - Add unbind_spool_callback webhook endpoint for unbinding flow - Add gcode.respond_info notifications for bind/unbind actions - Add notification when RFID card is missing but spoolman is available - Fix SPOOL_ID parsing to handle empty string values
Adds `24_settings_tweaks_spoolman.yaml` to enable/disable Spoolman via firmware-config, prompting for the server URL on enable and validating it is a reachable Spoolman instance before writing the moonraker config. Extends firmware-config to support `inputs` on settings options: each entry defines a named form field (label, placeholder, regex) rendered in the confirm modal, validated client-side, and injected as named env vars into the option `cmd`.
paxx12
force-pushed
the
afc-spoolman-auto-register
branch
from
96f399a to
46eed4e
Compare
8 participants
Summary
This PR introduces automatic RFID card-to-spool binding for the AFC-Lite system, enabling automatic spool detection and management via Spoolman when an RFID card is present on a lane.
Key Differences from PR #285
The #285 requires usage of
spool_idand only works withOpenSpoolprogrammed spools. This PR instead stores the RFID to spool mapping in a Spoolman, allowing to support any type of spools as long as they are RFID detected.Behavior
This PR does update
lot_nrof spool in Spoolman depending on the user action:lot_nrif Spool is assigned to Spoolman via Fluidd (AFC-Lite)lot_nrif Spoolman is unassignedlot_nrfrom other spools if spool is assigned to another Spool in Spoolmanlot_nrwill store thecard_uid:XXX,card_uid:YYYwhich will be used to map the tag to spool_id each time the spool is inserted into printer