Perspective Barcode Scanner Input: Bad Idea to use Regex on a Numeric Code?

If I have a regex barcode scanner input set to look for 14 digits of just numbers with a 14 character window, is this a bad idea? For example, what if a barcode scans improperly and only supplies 13 digits, this will not trigger a scan but it will hold those 13 in the buffer. Then when I scan it again, it will take the first digit of the 2nd scan and submit a scan with the wrong numbers.

I assume that the only way to fix this is by go to using a prefix and suffix scanning method?

In practice, I’d be pretty surprised by a failure mode of a barcode where you successfully scan some digits but not all.
Most barcode formats have a check digit - so even if one of the inner symbols is obscured, but the rest of the code is intact, the checksum won’t work and the whole barcode won’t scan.

2 Likes

If someone scanned a barcode on a drink or bag of chips goofing off, and that turned out to be only 9 digits, after a valid 14 digit scan, I would expect the scan to not be valid. The question is, would the extra digits be buffered after the matching regex holding it in a weird offset pattern?

I believe the buffer expires after a brief timeout…

1 Like

Hmm, I might be wrong after looking again at the code.

I just tested it, and as I suspected, the buffer is not flushed once a regex is matched. This seems like a bug to me.

For example:

regex: ([0-9]{14})$
window: 14

2 barcodes, 1 correct, 1 random

Rando: 765756931175
Correct: 80157122001012

1. Scan random 1st
2. Scan correct barcode
3. Scan correct
4. Scan random

>> 76575693117580
>> 15712200101280
>> 15712200101276

It seems if you get off on a regex that does not have a well defined structure, you can’t get back to correct state.

Wouldn’t it make sense to flush the buffer once a regex match is found?

Is this intended behavior, or should I contact support?

I would contact support. I think this is something we should handle better. A simple timeout would prevent a lot of frustration.

1 Like

I don't have anything to add on solving the issue but I just wanted to chime in on this bit. We actually run into this problem quite often. We scan a lot of UPC-A encoded barcodes (grocery items, etc) and we see a fairly significant number of misreads where the checksum works but the read result is incorrect. The most common issue is with barcodes that have a "04" in them that is read as "42" and vice versa. This just so happens to work out with the UPC-A checksum algorithm that the check digit is the same for both of these.

I haven't dug into this issue too much but I'm assuming the bar widths aren't all that different between the two. I should note that this is an image based barcode scanner and we probably could increase minimum confidence thresholds to reduce this type of misread. Our scanners are running multiple times per second so the misread typically is a non-issue as it reads the barcode on an item many times and the misreads are drowned out by good reads.

Anyways, I figured I'd share in case someone finds this interesting.

2 Likes

Was anything figured out here? I have a similar problem - if I scan an item that doesn't pass regex, it does seem to leave random stuff in the buffer.

I made my regex take almost anything and I parse it, but there are still some barcodes it doesn't take, and it ends up distorting the next scan afterward.

Thanks

Lately, I'm leaning towards using prefix/suffix and accepting all scans then script parsing the scan to see if it's valid.

1 Like

I'm thinking of doing this as well, but new to Ignition. Which event or where would you put the logic to parse the scan? Would you also remove the scan from the buffer once complete?

No need to worry with the buffer. I have a project script in my global scripting project that I can call from anywhere. Using the barcode scanner input component use a script action on the onActionPerformed event. Then you would do something like this.

lastScan = self.props.data[-1]
valid = myScipts.barcodes.parse(lastScan)
if valid:
    myScripts.shipping.processScan(lastScan)

This is just an example, myScripts can be any identifier you want. That is, the scripts could be organized by process names, area names, or some generic name.
Project Library | Ignition User Manual (inductiveautomation.com)

Note that you could move the barcode parsing/validiation inside the myScripts.shipping.processScan() instead of the onActionPerformed event. You want to keep your business logic in the project scripts and not in events themselves. It's considered an anti-pattern often referred to as a "magic pushbutton."

1 Like