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

Ignition
,
1

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?

2

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
3

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?

4

I believe the buffer expires after a brief timeout…

1 Like
5

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

6

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?

7

Is this intended behavior, or should I contact support?

8

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

1 Like
9

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