Universal Filament Identification System/ua

From RepRap
Revision as of 06:43, 23 May 2023 by Edlab (talk | contribs) (Cons)
Jump to: navigation, search

This is an attempt to recreate/restart the UFIS project on RepRap.org in order to protect it from being lost on external sources such as abandoned domains, discontinued online services or otherwise.

The idea of UFIS is to add different data about the filament type, colour, printing temperature range and other data to the filament spool itself so that the firmware of the 3D printers and multi-filament systems can act on their own when receiving print requests. For example, a g-code file should do a change material request by specifying a CMYK value, not "change to filament 3 on multi-filament unit 2". The multi-filament units could also to talk to the slicer software to tell it which colours are currently available and to give a preview of the end results when trying to decide which colours to use as a replacement. For example, what would the print look like with the light blue filament available to the printer instead of the dark blue used in the 3D model?

With the current wave of multi-filament systems (Mosaic Palette, Prusa Multi-Material Upgrade, Bambu AMS, 3DChameleon, ERCF, etc) this idea should be brought back to automate and simplify the setup of 3D printers.

It would also make it easier for new 3D printer users if even single-filament printers could set up the filament parameters by themselves. If g-code files could give temperature control to the firmware instead of being hard set in their code, we could print the same parts with different filaments using a single g-code file instead of needing a specific file for each material. After all, we all know that even printing the same type of material between different filament colours and/or different companies can require different temperatures. Having the firmware know the filament temperatures automatically would add convenience to the printing process.


Data Storage method

The original UFIS project suggested using either QR codes or RFID tags.

RFID tags

Переваги

  • RFID reader modules require a minimum of space between them and the spools.
  • Even low-cost RFID tags can store hundreds of characters.

Недоліки

  • Requires an RFID scanner on the printer or the multi-filament system.
  • Having multiple RFID readers and multiple RFID tags in close proximity could result in false readings or conflicts.
  • RFID tags are not biodegradable, or at the very least are less environmentally friendly than some extra ink for a 1D or 2D barcode.
  • Adds extra cost per spool for the manufacturer.
  • May require manufacturers to add an additional step in their packaging process.
  • The added cost/complexity for manufacturers could hold back support for the standard.

QR Code

Переваги

  • Basically free as it only requires something to be added to the labels.
  • No additional step in the packaging process for manufacturers.
  • As recyclable/biodegradable as the label/cardboard spool itself.
  • There should be no conflict of reading the QR codes of other nearby spools.
  • Version 2 QR code (25x25 modules) can store from 20 to 47 bytes/alphanumeric characters depending on the ECC level.

Cons

  • Requires a 2D barcode reader on the printer or the multi-filament system.
  • A 2D barcode reader module takes more room than an RFID reader module, if only for the space required for the camera to be able to focus on the code.

For all these reasons, a QR code should be used for UFIS.

Physical size and location on the spool

The size and location of the QR code should be close to the inner edge of the center hole of the spools, to allow the standard to be used with spools of smaller diameters. The distance should take into account the various standards of spools currently on the market and add a small margin from that edge. A quick search seems to indicate that Hatchbox has the biggest inner diameter of 56mm, so having the bottom of the QR code sit at ~30mm of the center of the spool would cover all cases. The size of the QR code should be big enough for a Version 2 using even low-end 2D scanner modules. Most documents about QR codes seem to indicate a minimum of 2×2 cm.

Data format

The data should be kept as compact as possible in order to simplify firmwares implementations and also to keep the physical QR code size as small as possible. Using look-up tables with pre-defined values will also prevent manufacturers from mistakes such as different spellings, lowercase/uppercase differences, using different or non-standard separators, etc which would make firmware implementation more difficult and error-prone.

Notes:

  • While the look-up tables are incomplete, their values given should not be changed.
  • Keep the lists as unordered bullets so that modifying them cannot accidentally change their assigned numbers.

Bytes 0, 1, 2, 3 and 4: UFISx header

Since some manufacturers now add QR codes to their spools for various reasons, we need a header on our QR code so that the reader knows it is reading an actual UFIS code.

  • Byte 0: 55h (letter "U" in ISO 8859-1)
  • Byte 1: 46h (letter "F" in ISO 8859-1)
  • Byte 2: 49h (letter "I" in ISO 8859-1)
  • Byte 3: 53h (letter "S" in ISO 8859-1)
  • Byte 4: 01h (UFIS version/revision, starts at 1, maximum 255)

Byte 5: Material Type

  • 0 = ABS (Acrylonitrile Butadiene Styrene)
  • 1 = PLA (Polylactic Acid)
  • 2 = PET (PolyEthylene Terephthalate)
  • 3 = PETG (Polyethylene Terephthalate Glycol modified)
  • 4 = PETT (PolyEthylene Trimethylene Terephthalate)
  • 5 = Nylon
  • 6 = ASA (Acrylonitrile Styrene Acrylate)
  • 7 = HIPS (High Impact Polystyrene)
  • 8 = TPE
  • 9 = TPU
  • 10 = PVA (Polyvinyl Alcohol)
  • 11 = PC (Polycarbonate)
  • 12 = PP (Polypropylene)
  • 13 = POM (Polyoxymethylene)
  • 14 = PEI (Polyetherimide)
  • 15 = PEEK (Polyether Ether Ketone)

Note: composite filaments such as PLA-CF should not be added, see Byte 7: Material Modifier.

Byte 6: Material Sub-type

If applicable for the Material Type, there will be a specific table of values for the Material Sub-Type except for the value zero which is always unknown / not specified.

  • 0 = unknown / not specified (for all material types)

The Material Sub-Type tables for each Material Type is still to be determined, but here are two examples:

  • For material type 1 (PLA), a byte value would be reserved for Ingeo 3D850.
  • For material type 5 (Nylon), a byte value would be reserved for Taulman3D Nylon 645.

If possible, ranges should be reserved for the biggest manufacturing companies of each Material Sub-Types to keep the lists tidy, ex: reserve values 1 to 25 for Taulman3D while keeping Byte 7: Material Modifier in mind.

Some firmwares may decide to only support Material Type and ignore Material Sub-type, or only support Material Sub-type for the most common Material Types (such as ABS, PLA, PETG, Nylon), etc.

Byte 7: Material Modifier

If there is another material added to the base material, then it is specified with the following values:

  • 0 = None (no modifier added)
  • 1 = Wood
  • 2 = Carbon Fiber
  • 3 = Glass Fiber
  • 4 = Aluminium
  • 5 = Brass
  • 6 = Bronze
  • 7 = Copper

Please note that while this list is incomplete, the order of the material modifiers listed above should not be changed.

Byte 8: Material modifier percentage

Stores the percentage of the modifier added to the material type. For example, if a filament is PLA-CF with 20% carbon fiber, then Byte 5 will have a value of 1 for PLA, Byte 7 will have a value of 2 for Carbon Fiber and Byte 8 will have a value of 20.

Bytes 9 and 10: Visual/Specialty filaments

Bytes 9 and 10 are reserved for visual filaments such as rainbow, glitter, marble, glow-in-the-dark, etc. To be determined later, but could be bit flags for each visual aspect so combinations would be possible (ex: both glitter and marble). This would, of course, limit us to only 16 distinct visual/specialty types.

Byte 11 and 12: Minimum and Maximum nozzle temperatures

Stores the recommended minimum (Byte 11) and the maximum (Byte 12) printing temperatures for the filament, divided by 5. This is done in order to save one byte and still store temperatures higher than 255C which are required to print with materials such as PEI and PEEK. For example, a value of 38 means 190C. Using multiples of 5 gives us a range from 0C to 1275C which is more than enough. The 3D printers should display a warning if the requested temperature is not within their limits.

Byte 13 and 14: Minimum and Maximum bed temperatures

Stores the recommended minimum (Byte 13) and the maximum (Byte 14) temperatures for the heated bed, divided by 5. This is done in order to save one byte and still store temperatures higher than 255C. The 3D printers should display a warning if the requested temperature is not within their limits or if it does not support a heated bed and the ambient temperature is outside the requested range.

Byte 15 and 16: Minimum and Maximum enclosure temperatures

Stores the recommended minimum (Byte 15) and the maximum (Byte 16) temperatures for the heated enclosure, divided by 5. This is done in order to save one byte and still store temperatures higher than 255C. The 3D printers should display a warning if the requested temperature is not within their limits or if it does not support a heated enclosure and the ambient temperature is outside the requested range.

Byte 17, 18, 19 and 20: CMYK

Being a physical object, filament needs to use the CMYK colour model instead of the RGB colour model. Also, given the litigious nature of the colour space industry, colour names will not be used and raw CMYK percentages will be used instead. This will also make it easier for the firmware to decide which filaments to use to colour match as closely as possible the colours used by the 3D model.

  • Byte 17 stores the cyan percentage value of the filament colour (from 0 to 100)
  • Byte 18 stores the magenta percentage value of the filament colour (from 0 to 100)
  • Byte 19 stores the yellow percentage value of the filament colour (from 0 to 100)
  • Byte 20 stores the black percentage value of the filament colour (from 0 to 100)

Bytes 21 to 47: Reserved

Bytes 21 to 47 are reserved for future expansion.

Note: the total number of bytes available depends on the ECC level of the QR Code Level 2.