TODO

[bofh69]

• Save the active filament variable after updating it.
• Finish write_tag - store the records, use index = self.cursor_line in actionHighlighted to find the record.
• Translate records to strings in write_tag.
• Add NFC writing to the connect code in write_tag.
• Add a systemd file to start nfc2klipper (https://www.shellhacks.com/systemd-service-file-example/)
• Put the gcode macros in its own file so it can be included
• Add info about custom gcode slicer config
• Keep other NDEF records, replace existing FILAMENT+SPOOL text records. If full, replace the last one?
• Allow "GCODE:" NDEF records as well, to be sent without further parsing.
• Update spools in write_tags' list if they are updated in Spoolman.
• Filaman uses "extra.nfc_id" field in spoolman to identify the spool in spoolman. Support it too?

[scoggins]

Random question, would it be a good idea to maybe borrow from OpenSpools idea and use JSON to store the data. This allows us to use similar format to them (it also makes adding Spool support easier later).

EG:
A record for nfc2klipper would look something like:

{
    "protocol": "nfc2klipper",
    "version": "1.0",
    "filament": "10",
    "spool": "20",
    "gcode": ".........",
}

This would make it easier for "Keep other NDEF records, replace existing FILAMENT+SPOOL text records. If full, replace the last one?" as you just look for the nfc2klipper record and replace it. It also means going forward it would be trivial to also add in a function to pull the data back from spoolman and write the OpenSpool information from spoolman if thats a feature that is requested more.

It would just mean updating the existing code so that it looks for old tags and uses them, but maybe does a rewrite to update them to the new format.

Or maybe thats just over complicating things? I'm happy to give the code a try if thats something you're interested in.

If you are interested I've done a first pass at it main...scoggins:nfc2klipper:feature/json_ndef

[bofh69]

@scoggins My initial impression is that this is a good idea, but @V-aruu has made an android app that can write the current format. I'm sure it is easy to update, but I don't want to add extra work unless we gain something concrete from the change.

If going this way, I don't think old tags should automatically be updated. Just support both formats. Read the new format if a tag contains both. Automatically updating it gains little for the user, but adds the risk of corrupting the tag. New tags can be written in this format. If one really needs to update a tag, one can just write to it again from the TUI and web interface. If it then fails to work, the user will at least know what they did and can try again.

Upon checking out the OpenSpool project again it is my impression that they want to move away from their current format and start using the OpenTag/Open 3D-RFID format when that's done. Its a rather different format so perhaps it is better to wait and how things are developing there?

I think things will have to work in a different way with OpenTag. The tags' data will probably be the same for all spools with the same filament. I think one will have to read the tag's serial number instead and use it to lookup the filament's & spool's ids from Spoolman. Perhaps a custom spool field that contains the serial number or maybe the new "external id" can be used for this?

[scoggins]

Totally understand. I wanted to learn more about the NFC side of the app and this was a challenge for myself (hence no pull request just a show and tell). It sounded like a good idea in my head, but as you've pointed out, there are dependancies I hadn't thought of.

[JekleFPV]

Don't want to open an isuue for just a question, so figured this would be the place...

I'm currently building an MMU, and was wondering to what extent I could potentially intergrate all the nice things that you're developping Sebastian!
Full intergration would be 4 readers built into the spool handlers, telling klipper which spools are on there, drawing from the selection available in Spoolman etc.

That already raises 2 main questions at this point:

• Would this lend itself to mupltiple readers on the same (MMU) machine?
• Given that the spools turn, do you suppose any unwanted consequences might happen if the NFC gets read every turn when a spool is being used?

[bofh69]

@JekleFPV the current programs only read one configuration file so nfc2klipper can only read from a single reader. Reading multiple times should however not be a problem.

It shouldn't be hard adding a command line argument to read from different configuration files (or simple override which NFC reader to use). But if you use a RPi, there are only two serial ports. You can perhaps connect a third with spi or i2c, but I'm not sure you can have four connected.

From what I've seen, people use a single reader, reading the tag when they mount the spool and somehow have the system remembering the spool per slot. I've seen some documentation about it on happy hare's site if I remember correctly.

[malaki86]

I'm wanting to integrate a tag reader into my printers, but in a different way.

Basically, I want the reader near the spool holder on the printer. This will let the reader detect which spool is attached. The "hmmm" part for me, though, is that I can't just plug the reader into just any printer. My Klipper'd Ender 3v2, running from a Rpi is a piece of cake. Not so much for my Creality K1, running its own hardware.

What I'm thinking is WiFi, like an ESP32/ESP8266, that can be set as "linked" to a specific printer. When you put the spool on the printer, the device would tell Spoolman directly what spool is being used. The problem now is that I don't see a way to inform the Spoolman Klipper integration what spool is mounted to that printer.