Würth Elektronik Datamatrix Code Support

[mkne]

I tried to scan the Datamatrix Code on a Wuerth Elektronik Sample Delivery with the Part No. (1P): 875 105 242 006 and the Quantity (Q): 20 pcs and the Lot No. (T1): 317010012523270. The raw data our Eyoyo Barcodescanner enters in the input field are the following.
[)>06␝1P875105242006␝Q20␝1T317010012523270␝16D20250629

I can recognize the readable data from the label in the raw data, the last part is unknown to me and I also couldn't find it on the delivery documents (Lieferschein).
However part-db doesn't recognize the format. I hoped this is some of the standard formats already available.

[d-buchmann]

Hi,

I've also had a try at this.
I found out (and additionally had it confirmed by a Wurth employee) that their "16D" field is actually their date code. No idea why they don't use the standard field, though.
A while ago I added the 16D field into the constructor of EIGP114BarcodeScanResult and the following code in guessBarcodeVendor(), but I never felt like it was fit for a PR, also because I mangled several changes together (decoding odd EIGP114 headers, decoding for Schukat codes and tried to generalize the field handling a bit).
However, decoding WE barcodes worked for us since then.

     //WE has a "16D" field which is their date code
        if (isset($this->data['16D'])) {
            $this->dateCode = $this->data['16D'];
            $this->shipDate = $this->data['6D'] ?? null;
            $this->vendorSKU = $this->data['3P'];
            return 'wurth_elektronik';
        }

[mkne]

Thanks @d-buchmann I will have look into it when I'm back from Nürnberg. I didn't have the time to analyze the barcodes in more detail.

[mkne]

I had a closer look on this topic and apparently our Barcode Scanner Eyoyo EY-009P seems to remove the Record Separator (RS) at the beginning of the code (after [)>) and RS and EOT at the end of the code. This also happens with Mouser labels that I just tested today.

Result when uploading the image of the datamatrix code to Part-DB:

Result of the scan with the barcode scanner, which emulates a keyboard which types the recognized code into the input field:

I wrote an e-mail to the support of the Eyoyo to figure out how to setup the scanner properly. The manual doesn't mention a setting for "Format 06" of ISO/IEC 15434 which is referenced in chapter B.3 of the EIGP-114.2018 specification here: https://www.ecianow.org/assets/docs/GIPC/EIGP-114.2018%20ECIA%20Labeling%20Specification%20for%20Product%20and%20Shipment%20Identification%20in%20the%20Electronics%20Industry%20-%202D%20Barcode.pdf

[d-buchmann]

I see, so the issue is not Part-DB missing the feature to guess the right vendor (yet).
Generally, emulating a keyboard to enter a barcode is prone a multitude of weird problems, but it's the easiest, most common and most browser-friendly way to do it, so I guess we'll have to live with that.

[mkne]

I would also rather have a part-db instance that is accessible via smartphone that I could use for scanning and updating our stock.
I played around with the scanned codes and figured out that it still works if the EOT at the end is missing. The Record Separator (RS) however seems to essential. I thought about if it might be an option to make part-db a bit more forgiving here. But I think it's wrong to correct something in part-db that is not caused by part-db. The support of the manufacturer of the barcode scanner replied really quickly with a request for more information so I still have hope it will be fixed on this side.

[d-buchmann]

In fact, I've seen codes in the wild that definitely do not contain the <RS>, using image based scanning.
The trailer <RS><EOT> is not checked because many codes don't include it.
Moreover, some old Mouser 2D codes literally start with >[)>. Absolute madness.

If we want to have this kind of broad barcode support, I suppose we have to embrace these wild implementations by others.
Maybe a warning could be issued that the code is not standard compliant, but you would still be able to decode the content.

[mkne]

I got a response from the manufacturer's support and they don't seem to understand the problem. I think they haven't even looked at the information and screenshots of the expected result from Part-DB scanning a image of the Datamatrix code and the result of the input that their scanner delivers via USB-HID typed into to input field, I have provided them.

In the meanwhile I also had a look into the Part-DB code of the barcode scanner and I think it should be just a change in isFormat06Code() here:

Part-DB-server/src/Services/LabelSystem/BarcodeScanner/EIGP114BarcodeScanResult.php

Line 258 in 753ecee

if(!str_starts_with($input, "[)>\u{1E}06\u{1D}")){

I will give it a try with a PR. Maybe adding the above information for Würth.

[mkne]

@d-buchmann Just re-read your first answer. Now I understand what you meant with "decoding odd EIGP114 headers". Just found that you have a separate branch for this. So maybe doing a pull request from your fork to the upstream would be the right thing to do?

[d-buchmann]

Yeah I did, but as I mentioned I didn't think this was fit for a PR, mainly because several unrelated changes were thrown in the mix.
By now some of it might be stale as well (e.g. due to changes introduced by #1194). Feel free to cherry pick at look at the comments I added. I'd suggest to keep the header parsing and the vendor guessing separate (at least in separate commits).

One remaining issue is that the data fields are intended to be read only and are originally set in the constuctor.
But because some vendors assign different meanings to the same fields, that's not practical, so I diverged from that scheme.