This one is a bit out of left field but given 3D printer manafacturers (eg Bambu Labs, Anycubic and more) are using RFID chips on rolls of filament that automatically tell the printer what filaments are installed in the multi-material system, consider developing a 2D barcode/RFID standard that fully describes the tool. The basis of this could be borrowed from the field of logistics where the global standard is the GS1 2D barcode standard and its RFID variant. https://www.gs1.org/standards/barcodes/2d Here hundreds of attributes are folded into a single QR code or Data Matrix code. Companies like Walmart will not accept products from their suppliers unless it has an embedded RFID chip compliant with this standard. It would not be necessary to create the barcode as that's done on the barcode label printer but the nomenclature needs to be able to parsed. eg functions for barcode_create, barcode_read and hooks that a user could implement to extend the system in his machine environment to act on the data. You will know the project has been widely adopted when you can scan a 2D barcode on manufacturer's packaging to enter a new tool into your library and when manufacturers start embedding RFID chips into their tools. There would also be opportunities to monetize the project (GS1 do very well here) to ensure it is resourced into the future. On 2025-11-09 02:42, Stuart Stevenson <[email protected]> wrote:
On 2025-11-09 05:40, rod <[email protected]> wrote: > This one is a bit out of left field but given 3D printer manafacturers (eg > Bambu Labs, Anycubic and more) are using RFID chips on rolls of filament that > automatically tell the printer what filaments are installed in the > multi-material system, consider developing a 2D barcode/RFID standard that > fully describes the tool. > > The basis of this could be borrowed from the field of logistics where the > global standard is the GS1 2D barcode standard and its RFID variant. > https://www.gs1.org/standards/barcodes/2d Here hundreds of attributes are > folded into a single QR code or Data Matrix code. Companies like Walmart will > not accept products from their suppliers unless it has an embedded RFID chip > compliant with this standard. > > It would not be necessary to create the barcode as that's done on the barcode > label printer but the nomenclature needs to be able to parsed. eg functions > for barcode_create, barcode_read and hooks that a user could implement to > extend the system in his machine environment to act on the data. > > You will know the project has been widely adopted when you can scan a 2D > barcode on manufacturer's packaging to enter a new tool into your library and > when manufacturers start embedding RFID chips into their tools. There would > also be opportunities to monetize the project (GS1 do very well here) to > ensure it is resourced into the future. > > > On 2025-11-09 02:42, Stuart Stevenson <[email protected]> wrote: > > Why not expand the LinuxCNC tool call to alphanumeric symbols of longer > > length? > > > > On Fri, Nov 7, 2025 at 4:04 PM Brad Collette <[email protected]> > > wrote: > > > > > Thanks Andy, > > > I've looked through that wiki page and I think there's a pretty good > > > concept map so it should be compatible. > > > I'm trying to stay pretty close to the ISO 13399 spec to avoid the XKCD > > > 927 > > > <https://xkcd.com/927/> problem. Other than the notable lack of > > > 'sets' of > > > tools, > > > the standard seems reasonably flexible. > > > > > > Tool items work well for an abstract catalog items like "5mm end mill" > > > but > > > can also be as specific as "Harvey tools, 3mm 4 flute, unobtanium > > > endmill, > > > part number 8675309" > > > > > > Assemblies let you put tool items together and be as exact or as loose > > > about what 'together' means as you wish. > > > > > > Instances are oriented at tracking real world artifacts. Again, the spec > > > is loose about exactly what gets tracked for an instance. > > > > > > Presets have inherent expectation that the tool is used in the context > > > of a > > > machine and that relationship may be data-rich. > > > > > > My current working schema > > > <https://github.com/loobric/smooth-core/blob/master/docs/DATA_MODEL.md> > > > also has 'usage'. This was an earlier experiment and I'm rethinking > > > it.. > > > It was meant to be a place to collect use information over time but I now > > > believe this is either an attribute of the instance or the preset > > > (lifetime use of the tool vs usage of the tool in a machine). I'll > > > probably drop 'usage' > > > > > > I already mentioned 'sets' before. I think the tagging system would > > > allow > > > mapping machine+spindle <-> set. > > > > > > > > > > > > On Fri, Nov 7, 2025 at 10:21 AM andy pugh <[email protected]> wrote: > > > > > > > On Fri, 7 Nov 2025 at 15:26, Brad Collette > > > <[email protected]> > > > > wrote: > > > > > > > > > This is still pretty early and the data schema is likely to > > > change. > > > > > > > > I think you were in the meeting so have probably seen this, but I > > > will > > > > repeat it: > > > > > > > > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolDatabase > > > > > > > > This describes a tool database that I developed in discussion with > > > > Tormach. It considers the possibility of a machine having a number of > > > > tool carousels, for example. > > > > > > > > Some of the mappings may seem backwards, but it is this one-to-many > > > > mapping that suggests the mappings. > > > > > > > > One thing that is worth considering is that (in G-code at least) the > > > > programme can only pick a tool with a single integer. It makes sense > > > > that this could be one of several tools, with the least-worn (or just > > > > an unbroken replacement) being chosen by external processing. > > > > > > > > -- > > > > atp > > > > "A motorcycle is a bicycle with a pandemonium attachment and is > > > > designed for the especial use of mechanical geniuses, daredevils and > > > > lunatics." > > > > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > > > > > > > > > > _______________________________________________ > > > > Emc-developers mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > > > > > > > > > -- > > > Brad Collette > > > 573-427-7132 > > > > > > _______________________________________________ > > > Emc-developers mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > > > > > -- > > Addressee is the intended audience. > > If you are not the addressee then my consent is not given for you to read > > this email furthermore it is my wish you would close this without saving or > > reading, and cease and desist from saving or opening my private > > correspondence. > > Thank you for honoring my wish. > > > > _______________________________________________ > > Emc-developers mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
