Working on a format for filament identification codes.

3D Printing
, , , ,
1

Working on a format for filament identification codes. These would be on spools from the manufacturer in the form of QR codes, and transfered to an EEPROM chip on a reusable cartridge so that a printer can automatically adapt to new filament without mucking with slicer settings.

Originally shared by Whosa whatsis

WRT size of the codes, I think we should see if we can get a short-form version (possibly not including the version number, diameter and tolerance?) into 512 bits (64 bytes) so that it can be stored on and attiny85 that is also running a filament measuring apparatus as a drop-in replacement for the static memory, so that it can be used in place of the eeprom chip instead of in addition to it. 512 bits is also the size of a version 4 (33x33) QR code with medium error correction.

Failing that, 1024 bits is the number to shoot for to fit the cheapest eeprom chips, with additional features enabled by using a 4096-bit chip. A version 7 (45x45, low error correction) or 8 (49x49) QR code will be needed to match the 1024 size, though the code can be smaller if it doesn’t use the whole 1024, and I see no reason to enforce the use of certain QR code sizes, so long as the data is formatted to fit the length requirements once information not needed by the eeprom (like URIs) is removed.

What we need to pack in:
Version number (give it a byte for room to grow?)
Filament size (9 bits measuring 100ths of a mm would give us .01mm resolution and would be sufficient for measurements up to 5.12mm).
Tolerance in the same units? If so, 6 bits should be plenty? Maybe make it 7 bits to round out two bytes with the filament size?
Temperature up to 306 °C will fit in 1 byte if we add 50 to the value. Would adding 100 instead give a better range (100-356)?
Max temperature same measurement as above, temperature not to be exceeded, 1 byte
Platform temperature and Chamber temperature will fit in a byte each without the addition, leaving 0 available for unheated.
Color including transparency can be represented with plenty of resolution in 4 bytes

If we go with standard UPC codes for product identification, that will take at least 37 bits (which we might as well round up to 5 bytes unless we can squeeze something else into the other three bits)
Manufacturer’s serial number should have at least 3 bytes) to have room to grow (might get away with 2 if they count separately for each UPC and take the extra 3 bits.
Formula code will require a lookup table, which we’ll have to build before we know how big it needs to be, though depending on how specific we can get, I imagine it would fit in 1 byte, at least for version 1.
For amount of filament, we need a unit. I would suggest cubic centimeters, of which a 1kg spool has approximately 850-1000 depending on density, though we should be prepared to spools up to at least 10lb. Maybe measure 10ths of a CC and use 2 bytes?

That’s about 22 bytes so far out of 64 for our minimum spec. Figure 20 characters upper-case alphanumeric for a human-readable ID string, what will fit in 14 bytes with QR alphanumeric encoding, or 20 if we use UTF-8 or ISO 8859-1 (adds lower-case, and avoids confusing mixed encoding). Maybe another 20 for a short URL? That would make a total of 62. What else do we need to pack in? Any problems with my math?

2

Filament / tolerance, I’d go with 10/6 bits.

3

Btw, you have seen the KamerMaker? Ideally it should scale u to at least printers/extruders that size.

4

Would it be useful to add some basic physical characteristics of the filament in the code (like specific density) so printer can calculate it’s own temperatures based on filament characteristics and its own characteristics?

5

Well Well … Data formats, especially when they are supposed to stay are a tough area. I’m since 30+ years in that part of the industry (yes, I’m back from when punch card was the RFID of it’s days) and experianced quite some strange formats.

Before we come to content definition, there are several issues to think about

  1. Domain
    There are two different areas, which should be handeled seperatly.
    a) Storage
    b) Transmission

They may be the same, but they don’t have to be, so we need to be clar what we talk about. A QR is storage and transmission, while in a microcontroller (AVR you mentioned) representation in storage may differ from what it transmits on a read request.

  1. Error correction
    Stuff gets corruped. Thats not only true in politics but even more in communications, no matter if ongoing or stored. QR for exampel incooperates already a lot of redundancy information making it the stable storage/transmission system it is. Also it supports various encodings.

(Here is maybe also a little misconception in you ‘V4 equals 512 Bits’ asumption - V4 at correction level M (15% error recoverable) uses 512 Bits to store data, but as binary data (Bytes encoded) you’ll get only 62, not 64 characters. On the other hand it gives you 90 Alphanum or 149 decimal digits. The Format is way more efficient at storing numbers than traditional binary stuff.)

Similar within your AVR - how to handle data errors over time?

  1. Encoding (again)
    As QR already showed, a binary, bit orientated, design might not always be the best idea. One should rather think in application demand than geting cought in one storage paradigma. Think outside the binary box.

  2. Identification and Extensible Structure
    You already added a version number. Good. But without further included information it’s an either or thing. Maybe the most repeated problem in data definition. Just check SRAMS SPD where they later added checksums, magic numbers and whatsoever to make detection of extensions, while keeping compatibility. A way more upgradefriendly way has been for example used in TIFF. Here data is seperated into chunks of different purpose, each chunk versioned seperatly and defined by a length. That way unknow or unneded chunks can be ignored while still readign the stuff that matters.

If we finally add a rule that chunks can only be extended and each extension increases the chunks version number, existing software can handle future data without geting confused by newer additons.

So basicly:

Data := Protocoll, Version , total-length [,chunk*]
Protocoll := General Format Identifer
Version := General Version (Changed when it gets incompatible)
total-length := Total Lenght of the Message/Data (*1)
chunk := C-Id, C-Version, C-Length, C-Data
C-Id := Unique Chunk ID (*2)
C-Version := Version of this Chunk Definition
C-Length := Length of the C-Data following
C-Data:= One or more data fields defined due it’s C-ID and C-Version

*1 - I’d use it to make clear where the Data ends to handle valid data independant of transport requirrements - but as you like it.
*2 - Other Protocolls may reuse numbers - distinction via the protocoll number

Using this Infrastructure we now can looking foreward into a brite future and care about the data to be grouped and encoded.

(I’m just closing here and postpone that for a second comment - just in case G+ screws over again :slight_smile:

6

Data and Data content:
(These are less general comments, but rather my opinion on your suggestions)

Especially when thinking about QR as a main media, we should consider decimal representations instead of Binary. Beside the fact that Binary is always custom to decode, we get a way higher density using decimals - thats the format was made for in the first place.

The First Chunk (01)(*1) would be about physical parameters (Material Chunk). It would include everythin we need to know at handling the material while printing

Filament Size. Any specification less than 2% of what we expect to have does not make any senss - after all, everythin less will be as ridicoulous as specifiying a 20m steel beam down to a 1/10th of a mm. So considering filaments of 1-5mm, 1/100thmm sounds quite
good. I’d use 3 decimal digits (if binary thats almost exactly 10 bits) .

Tolerance I assume it’s abotu the tolerance the filament has? Anything outside the rage .5 to 5 times the base unit does not make any sense. That is, if the base unit is selected accordingly. So in our case 1 decimal digit (base 1/100th mm) is all we need - material more uneven would in eiter way result in real bad results - and serious, if someone produces such crap, do you realy think he would fill out hte data as supposed?

Temperatures Max and Usage and whatever: 3 decimal digits each. Just pain Celsius - heck, even Kelvin would work :slight_smile: In fact, thats not so much of a joke. Think of printers using chocolate or some other fats (butter etc.), some witt a melting point below zero. A standard like this should not focus too narrow on the ABS/PLA scheme.

Speaking of this, the Material Chunk needs some encoding for the stuff used. Your Formula Number would already work, but I’d go ahead and splitt it in two values, a Material Type and a Material Composition. Material Type is a 3 digit number defining a list of materials known. The list is defined externaly. At least one type has to be designated as ‘TBD’. Material Composition is a 2-3 Digit Number describing in what form the material is delivered - a wire doesn’t have to be solid, nor has it to be a wire at all (think of the stick printers). (*2)

A missing value is also the Maximum Possible Pull (maximum allowed force to transport the material). Some material might not be as durable as our beloved ABS, and tearing apart the filament isn’t a good idea. 3 Digit in N.

Colouris already more of a material propery definition that exeeds the simple physical part needed for the priinting process itself. But it is usefull to select the right head (or material feed) for multi material/colour printers. Also Colour allone won’t do the trick since parameters as transparency, ‘glossiness’ and such. So maybe an additional Chunk just for the visual (and textual) description might be useful.

Colour (2) - hard thing to do. I’m not sure if this is realy a matter we can handle so easy. For starters, I would just got with the colours that got HTML Names (143), but they do not qualify any So a 3 digit number will be quitte sufficient. In a single digit *Transparency could be useful.

If we want to do more than that, but less than having a seperate chunk, we might want to have a simple Base Colour (HTML as above) plus a Colour System ID plus Colour Number. The ID identifies a colour scheme like Pantone, Pantone+ or (good idea here) Pantone Plastic. Or other Systems like RAL, HKS or Natural Color. For most of them a 5 digit number should be sufficient, so CSID+CH will be 6 digits.

The second Chunk I’d see (02) is the Delivery Chunk describing the way the material got delivered. It includes everything ‘from tha back of the box’ that is not needed for the direct print.

UPC - the code the manufacturer assigned to this delivery -Already plain 12 decimals :slight_smile: Well 13 for EAN, which is standard today (even in the US). And since we do something new, GTIN (14 digits) is the way to go. Therefore I’d reserve 15 digits (blame it on QR to work best with decimals dividable by 3).

I’m not sure if one should go as far and include a serial number - 'cause if, then EPC instead of UPC/GTIN would be more usable. it already includes all necersarry structure - but uses from 64 to about 200 Bits … EPC is an defacto standard for large merchandise organisations and will get more and more important in global trade.

Amount - I would go with weight. Weight is not onla the Unit most raw plastic is sold, but also the only thing a customer (and some machinery) can easy doubleck. Just put it on a scale and suptract tha carrier. Volume is interesting in the building process, but not so easy to proof. Then again for printin it’s the volume delivered is defined by diameter and feed, not so much with what’s on the spool. For print preperation it’s easy to take the Material Type (and it’s implied specific weight - or should we add that explicit tehre?) to calculate the availabe amount from the total weight - resulting in a number way more exact than going from diameter and lenght, since the later is flawed by tolerance of filament. Units of 1g (5-6 digits) would be fine I guess. Length (and thus feed) can be calculated as easy from mass and diameter.

Maybe additional we need Tara weight
Tara - Weight (unit in 1g) of the spool (or whatever container)

Things liek Descriptions, URLs or whatsoever additional more or less readable stuff is something that could be packed into additional Chunks.

Your comment?

Thinking of all of this, You may want to take a look at some of the stuff developed arround RFID - for exampl PML - Physical Markup Language.

*1 - never start any numbering by 0 of its a transfer format - zeros are much too likely to be gererated by other means, so exempting them (and FF if Binary (And 55,AA in the old days) ) adds a real good level of error detection.

*2 - here additional, topic specific Chunks may be desirable

7

I like the chunking/TIFF suggestion from @Hans_Franke .

Instead of a “filament identification code” it might be useful to think of it as a “printer input identification code.” If you can achieve what you want for filaments, but not leave out all of the other printed materials, then that’s good. If being overly general and including other types of printer inputs means that you cannot achieve what you want for filaments, well, at least you examined that option before ruling it out. On the other hand, if you do come up with a more generic coding standard that satisfies many more use cases, that’s a win.

I guess the only other thing that I would say is that it would be annoying if the standard could not meet use cases because it was so focused on being small that it did not allocate enough bits for data formats. For example, encoding color with three numbers (digits?) seems very limiting. Maybe I am not in the proper, embedded programming frame of mind, but to me bits seem really, really cheap.

I like this initiative!

8

@Hans_Franke I started off trying to encode it that way, but there were two problems. First, we will want to have some text encoded within it for a human-readable identifier, and mixing 3 1/3-bit numbers with text is going to make it move difficult to decode. Second, the QR numeric format is NOT a more efficient way to store the numbers. The 3-digit numeric values you mentioned several times will take 10 bits to store values from 0-999, while binary encoding could store values from 0-1023 in the same bits. Furthermore, most of the values have been scaled to fit within 8 bits (0-255), so your numeric encoding idea would make those values take 1/5 more space to store. Unless the range can be reduced a I did with the temperatures, you just can’t improve on binary encoding for number storage for efficiency. It’s not compressible.

9

@Hans_Franke Thank you for your time. I appreciate your thoughts and experience with respect to data organization.

before we get into packaging the code I have a general question. Are we settled on the current data that needs to be stored? is it enough? I know we do have the ability to expand later, but lets not put the cart in front of the horse, if we don’t have a clear vision of what data is being packaged, we can’t build a package yet. I think we are there but I want to make sure we close discussion on initial data set before we move to packaging (it will save a lot on back tracking)

FTR I have no more input on content, but this is more or less a last call before moving forward.

10

@Lee_Lemay Colour is a real complex thing. In IT we tend to think of it as RGB, but there is no single scheme to be used. Even industries that work with colours since centuries like printing hasn’t come up with a unified way - in fact, they still operate with comparing prototype cards during design and production. Hence the Pantone charts. When it comes to ‘real’ material, like we use in 3D-printing a lot more parameters are involved. From transparency and reflection to texture and more. Pantone for example does offer a set of ‘chips’ to define colours/aperance of plastic.

So in our case the answer to the colour question is twofold:

a) If we want to have some kind of ‘exact’ description, we need to name the scheme used (and allow more than one) and handle a rather large amount of data within.

b) Such an ‘exact’ definition is way more than the average handling situation needs - also it includes a high hurdle for conversion. So for just seperating the blue filament from the red, a much more simple generalized colour description is all we need. After all, what we do with this information is to display it somewhere to the user, so he can doublecheck before handling. So to me even 16 colours would be sufficient for this purpose. Using a small rough pallete gets us all we need. And he, who prints in 12 shades of light blue, will have to be careful anyway.

11

@Camerin_hahn The system of packaging ( my first comment) is for most part independant of the data to be packed. If the packaging structure isn’t independant, a future point of failure is not a far fetched chance but a build in feature. If the packaging is well defined, like a system of flexible storage boxes, you may use it for anything from paper clips to cars.

12

@Hans_Franke I like the idea of a basic 16-color palette, plus an optional more specific designation, for which you would have to identify the standard (such as pantone) used to measure. We should probably make it 32 though, adding a bit to designate whether it is transparent or not.

13

@Whosa_whatsis Well, the loss between binary and decimal (packed as 3 digits per 10 bit) is about 2.4% - so if we take the a whole V4M QR, it comes down to about 12 bits wasted, but in fact, due the way the decimal encoding works on QR, it even gains almost a bit :slight_smile: (496 bits binary vs. 149 decimal digits), so not realy an issue. The argument ‘most of the values have been scaled to fit within 8 bits (0-255), so your numeric encoding idea would make those values take 1/5 more space to store’ isn’t conclusive, 'caus ‘fiting’ doesn’t tell how much of the 8-bit is on each value realy used. Eventually it may carry way more wasted encoding space. Wasted space is similar in every encoding scheme. Again, if everything is forced into 8 bit steps, every increase is a 256-fold - decimal it’s just a 10-fold. Way less, isn’t it?

It might be helpful to keep in mind that QR was first of all developed to transport nothing else than decimal numbers. Everything else has been added after that.

If theres a chance, that we end up at the same diner some day, I may show you some communication protocol encoding that relied heavy on variable encodings and workd so good, that even ziping the data of a whole CS-session couldn’t yield more than 40%. Anyway, different topic.

Also scaling is a rather dangerous thing, as the temperature example did show. 256 degree spread isn’t a good idea - if the format is to be used on more than your private machine, it hasto cover a wider range.

Last but not least, As soon as you want to include binary and ‘readable’ data in one QR, you break the format anyway. At least I assume, since you didn’t specify any escape mechanism to avoide that the binary (non textual) data will result in some wiered codes when read with standard readers, thus making it impossible to decode. Otherwise, if it’s only to be read by prepared software (aka applications made for this), then there’s no need to encode it in any standard charset. For exampel we could go ahead and encode each char as a 2 digit decimal number 00…99. Encoded as ASCII minus 32(d). In this case we would only need some 6 2/3rd Bits instead of 8 per char… eventually saving on text more than we may have wasted in other locations. And as far as it goes for our purpose I can’t see any need to include characters outside the classic 7-bit ASCII.

Additional, an all decimal format would be quite helpful in debugging, since all you need is a software to decode the QR and a pen. Yeah, I know, I’m one of the guys that print out the internet. Then again, there’s nothing better to meditate about than a 10cm thick core dump fresh from the line printer stack:)

Serious, debuging with hands and brain is the besst way.

Anyway. I would enjoy to get your comments on the other remarks if you like to.

14

@Whosa_whatsis Well, then rather with 4 or more levels of transparency - I got some real nice PLA here with different levels of transparency …

Another nice thing here id printable wood. definitly not transparent, but for sure to be handled special, since temperature controll is not only to melt it, but can also be used to darken the wood and create various effects.

15

great idea but it will be misused like the cube does to make you buy their cartridges.

16

I didn’t set out to break everything into bytes, it just seemed to work out nicely that way, so I stuck with it. Keep in mind that this data will not be only in QR form, but is also intended to be stored on an EEPROM chip, and breaking it into bytes should make that part a lot easier to implement. For all of the measurements like temperature and diameter, I added significant margins around all of the values currently in use by any FDM machine. If, in the future, we decide to extrude 10mm filament at 500C, we’ll have to update the format, but that’s why it has a version number.

I’m not the expert on QR codes that you appear to be, but what you’re saying doesn’t match the reference material I’ve been working from (for instance, that V4M is supposed to hold exactly 512 bits, which is 64 8-bit bytes). As for text encoding, 7 bits should be plenty, I’m just thinking that it may be easier to read and decode one byte at a time from EEPROM on a microcontroller.

17

@Addidis_no That’s why I want to develop it as an open standard. Everyone can read the standard and tag filament appropriately with it, and everyone can make machines to make use of the data. The cartridges are also designed to be reusable and DIY-able.

18

@Addidis_no Missused? To my understanding it would be a great idea if they also adopt it. This is not to crate an USP but ratehr an open standard where as many supliers should join. Even if they are producing for closed systems.

19

You know how lexmark printers shut down still full of ink? That kind of misuse. But aslong as it is open it should negate any issues just dont buy cube(like) printers. Unless you can hack it like the cube was.

20

Microcontrollers:
As far as I understand you intended to use an AVR, not just an eeprom (which is a logical choice, since there is no big difference in cost - at least for rather low volume). here you got two advantages - for one you may use the whole Flash for storage, and second you got the ability to convert data between storage and transport - no big deal here.

FDM-Machines:
As pointed out, 300C maximum might not be as much a problem then the 50C minimum is. I got an chocolate extruder, and here I need to go way below - even tried butter at some time (the whole machine had to go into a fridge :slight_smile: So 250 degree as range for a real standard is a bad choice. Margins have to be at least half a magnitude higher than what you want to handle. better one magnitude. This is best practice in engeneering since.

QR:
V4M holds a brutto storage of 512 Bits, but the first 16 Bit are reserved for information - for example the first 4 bits define the way of data encoding (Decimal, Text, Kanji, Binary).

And yes, 7 Bit is fine - and with 2 decimal digits we get more chars in then binary :))

Also, the all numeric format is something that is not only some weired japanees invention, but rather something most (large scale) ERP systems (reead SAP etc.) handle as standard.

But you’re right, the most relevance it has in our case for QR.