Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TODO #1

Open
7 of 10 tasks
bofh69 opened this issue Mar 6, 2024 · 3 comments
Open
7 of 10 tasks

TODO #1

bofh69 opened this issue Mar 6, 2024 · 3 comments

Comments

@bofh69
Copy link
Owner

bofh69 commented Mar 6, 2024

  • 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.
@scoggins
Copy link
Contributor

scoggins commented Jan 3, 2025

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
Copy link
Owner Author

bofh69 commented Jan 3, 2025

@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
Copy link
Contributor

scoggins commented Jan 3, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants