I want to place my printer in a narrow cabinet 50 cm wide. The filament spools will be in the dryer at the bottom. And the feeders will be moved to the mount behind the printer. Nothing new, I didn’t come up with this.
But there is one problem with this layout.
I plan to use RFID tags. But the side reading sensors become inaccessible, because the cabinet is narrow.
The question arises: how to make the sensors accessible?
The ideal option would be to install an external reader such as ACR 122U. But as far as I know, the firmware from Paxx12 does not support such a solution. There is another firmware from GitHub - DnG-Crafts/U1-ACR122U: Adding ACR122U to the Snapmaker U1 · GitHub . But I don’t want to install other firmware.
Are there any options for extending the RFID reading sensors or connecting the ACR122U?
That would be ideal! Maybe Paxx12 is planning to do something like that? Does anyone know anything about it?
Here is something to read:
I can’t remember what the existing sensors cable connectors look like but when I had the cabinet open I had to unplug them, and there is a video online about opening the U1 up…I suggest the simple idea of getting cable extensions and move the RFID sensors. Probably get a set of 4 or 6 for less than 10 on Amz.
If the standard firmware doesn’t offer what you want and another version does, use it or do without it. That’s the point of open source – to encourage community forks.
The issue with this is it risks affecting any resonant tuning of the coil characteristics. Might work, or might make the coils too insensitive.
That may be true but if I remember correctly the coil was taped to the side and basic power lines off if it running to the board - simple shielded black and red wire with a JST connector. Longer wire might make a change but I doubt it due to the coil design. Pretty easy to test and return to Amz if issues. For me that’s something I might try just to play around with it sometime…these are opensource in so many ways. 
Somebody tried it: How to extend RFID coils?
There are proven firmware versions: the standard one and the extended one from paxx12. If we were to create a fork for every idea, it would lead to various incompatibilities and errors. That’s why I’m against this approach.
So you don’t want to use the paxx12 either? It (reportedly) includes facility for external RFID (and widens the scope to OpenSpool).
I found this information. But to me, it’s like some kind of alien language. I’ll wait for a ready-made solution.
Very interesting - and here’s the good news: support for external RFID readers has already been officially merged into the main paxx12 firmware, without the need for a fork. But there is a nuance with the ACR122U in particular.
Chronology of what happenedInitially, wasikuss (the author of the ESP32+PN532 repository) filed PR #256 “Add support for remote update of filament info”, where he proposed transferring data from an external reader via the GCODE command: FILAMENT_DT_FIXED CHANNEL=0 DATA=‘…’. GitHub
Paxx12 did not adopt this approach via GCODE, but proposed another mechanism: I lean towards the webhook method, as shown here #303 - the webhook gives immediate feedback and does not depend on OpenSpool parsing, since the interface is well described in what can be used. The author of the PR agreed: no problem, I will update my implementation to use the webhook. GitHubGitHub
This was implemented in PR #303 “Expose RFID via filament_detect/set” and PR #314 “Support external RFID readers” - both are already officially merged into the main paxx12 repository, and it was with version v1.2.0 that the webhook mechanism appeared.
The release notes directly state: Starting with this firmware, external RFID readers are supported. An example is the @wasikuss project on ESP32-C3 with a PN532 reader.
Maybe I didn’t explain something clearly. I have paxx12 installed, but I don’t know how to use it on my own.
The misunderstanding is that you said you don’t want to install other firmware, but I interpret paxx12 as “other firmware” (ie alternative, not standard). I didn’t read the first post carefully enough to realise you were only talking about the DnG Crafts firmware.
As you should see from the other thread I referenced, there are significant challenges extending the cables to the RFID coils, although success is reported up to an extra 40cm. If I were trying to do this, I would experiment with the very thin co-ax used for connecting antennae to Wi-Fi modules in laptops (probably easily and cheaply available as made-up cables), but even that might not work due to the change in coil loading.
The only other possibility is to use an external reader, and there are limited ways to connect an external reader to a U1 – basically USB or network.
I found this in the paxx12 documentation for RFID Filament Tag Support:
Alternative Detection Systems
The OpenRFID detection system is an alternative to Snapmaker’s built-in filament tag detection, based on the OpenRFID project. It adds support for tagged spools from multiple manufacturers.
To enable it, navigate to the firmware-config web interface, go to Snapmaker Components > RFID Detection System, and select OpenRFID or OpenRFID (force generic vendor).
- OpenRFID - Filament is identified by brand and type. Spools unrecognized by Snapmaker Orca are hidden in Snapmaker Orca.
- OpenRFID (force generic vendor) - Same as OpenRFID, but spools are labeled as Generic so they always appear in Snapmaker Orca.
- External - Disables the built-in readers entirely, useful for external readers such as wasikuss/snapmaker-u1-remote-rfid-reader.
Following the wasikuss link, it’s not explicitly stated but reading between the lines I presume it connects to the U1 by USB (and is powered by USB). It comprises a PN532 NFC module wired to an ESP32 microcontroller board, programmed with the wasikuss firmware to provide the USB interface for the U1.
It seems obvious to me that there ought to be a way to have the ESP32 interfacing up to four NFC modules*; so far as I can see (currently) if you want RFID for four spools you would need four ESP32’s and four PN532’s (and a powered USB hub, probably), although it might be possible to get away with two (each sandwiched between a pair of spools).
* There is already an “issue” raised on GitHub for exactly that.
The other thing about the PN532 module solution is that there seems to be no option for an external coil – the sense coil is integrated into the board itself (so far as I can see). This means the tag on the spool would need to pass close to the PN532 to be read, whereas the large U1 coils should read the tag at any orientation of the spool. For information: RFID works by the coil emitting a signal, and the tag scavenges energy from the signal to power up and transmit back its ID data.
I don’t know why the ACR122U reader (or other existing USB NFC readers) is incompatible with the paxx12 extensions, but I presume it is otherwise we would not need the wasikuss solution (for paxx12 firmware) or DnG Crafts firmware (for ACR122U).
These are just my conclusions from limited reading – I stand ready to be corrected if anyone knows better.
Yes. If you’re not a developer, this all seems a bit too beta (if not alpha). I expect somebody will trail-blaze and write up some simple-to-follow proven instructions before too long.
And that’s weird because after reading that I found a spare JST cable from my laser engraver extension stuff I did last year and took 15 minutes to open’er up and added a 12" extension and literally held the case side as far away as the cable(s) permitted and fired up the U1 and rotated a snapmaker filament roll and the machine properly identified it. Took it back apart and put the covers on and stock worked as expected too. That’s just nuts and beyond my understanding of readers.
Why?
The problem is people want more than an extra 40cm.
Oh, yeah, that’s probably it. They are crazy simple piece of tech, but have a bunch more “problems” in application than I would’ve thought of.
You’re only thinking of the hardware you can see (a coil of wire). To transfer enough energy to the tag so that it turns on and sends back the data it’s been programmed with requires that the tuning is exact. This is RF engineering, a black art at the best of times. The “loop of wire” is a simple thing, but the sophistication in how it is operated is exquisite and leaves no margin for being cavalier with it.
Not unlike 3D printing itself: an FDM printer is simple enough, but it would do bugger all without the sophistication of slicer software to run it!
Can’t you stick the RFID tag on one of the hangers I’ve seen on Makerworld and put it next to the sensor?
the side reading sensors become inaccessible, because the cabinet is narrow.