Film-Tech Forum ARCHIVE: Barcode scanner troubleshooting

This is topic Barcode scanner troubleshooting in forum Film-Yak at Film-Tech Forum ARCHIVE.

To visit this topic, use this URL:
https://ft-forum.com/ft/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=8;t=007077

Posted by Mike Blakesley (Member # 26) on 10-31-2014, 01:35 PM:

I know this is in no way theatrical related but...at my day job we have several barcode scanners. I just got a new one. It works just fine, but the computer system can't find the part number in our database UNLESS I scan the item, then "backspace" out the very last digit. Our other older scanners work fine. Is there a setting I'm missing? Of course the instruction sheet is vague and unhelpful. I'm sure there's a barcode scanner expert out there!

Posted by Mitchell Dvoskin (Member # 751) on 10-31-2014, 01:59 PM:

I am far from an expert, but the last digit is usually a check digit that is created by a mathematical formula using all the other digits. This is used to insure the scanner actually scanned correctly. As there are many different formulas for calculating check digits, I suspect that the new reader is using the wrong formula, or shouldn't be using one at all.

There are probably people here who are more knowledgeable about this than I.

Posted by Marcel Birgelen (Member # 6801) on 10-31-2014, 03:02 PM:

I think Mitchell is absolutely right. Most barcodes contain a check digit or checksum, to verify if the code was read correctly. Sometimes a simple formula like adding all previous digits and throwing away the first digit of the sum, but also much more complex schemes.

Depending on your barcode system, you either use this check digit as part of your ID number or not. You do not seem to use them, so it needs to be disabled. Usually this is either a setting inside the reader itself or in the software that comes with the reader. Look for something like "Check Digit" or "Checksum".

Posted by Mike Blakesley (Member # 26) on 10-31-2014, 05:08 PM:

Well there is a list of functions that you can enable or disable by scanning certain barcodes. Some are disabled by default.

The enabled ones are:
Code 39
Code 128
EAN-13
UPC-E

and the ones disabled by default are:
Code bar
Industrial 25
Interleaved 25
Matrix 25
Standard 25
Code 93
MSI
Code 11

....so I'm assuming I need to enable one of the disabled ones maybe? I don't see the word checksum or check digit anywhere.

This scanner is made by Inateck (model BCST-20) if that helps.

Posted by Rusty Gordon (Member # 2210) on 10-31-2014, 05:09 PM:

There will be a programming book which you can download from the manufacturer web site in a PDF. Scanning the correct programming barcode will make it scan in the same way as your existing readers. You just have to download it, print the programming pages and find the right one. There are dozens of combinations, so find a barcode to use as an example BUT NOT a programming barcode, scan it with your old scanners and program the new one to scan the same way.

Posted by Mike Blakesley (Member # 26) on 10-31-2014, 07:28 PM:

Welll.....here is the link to the instruction manual. This is the only documentation on the website (this also came with it).

Manual

I have tried most of the "setup" barcodes on this sheet and so far they all give the same results -- it reads all the digits.

I don't understand how I would program this scanner the same as the other ones. They're from a different manufacturer so their codes might not work....? I know we have a sheet around here somewhere that we used to program the odler ones, I'll see if I can find it.

Why does this crap have to be so $&#^@!%& complicated? [bs]

Posted by Marcel Birgelen (Member # 6801) on 10-31-2014, 10:40 PM:

Ah, some fancy newfangled thing with Bluetooth and all the works. Funny how you configure it by scanning barcodes... Maybe that's the standard way of doing it nowadays and I'm just a bit old-skool.

Do you know what types of barcodes you're scanning? Maybe the thing is misinterpreting your barcodes because the format is not enabled, or it is misreading the format for something else.

EAN-13, for example, one of the most used barcodes for product labeling, includes a single trailing checksum number. Usually, you can specify in either the reader or the software interfacing with the reader to either push the number or ignore it. Product numbers are usually stored in databases without the extra number.

Posted by David Buckley (Member # 2600) on 11-01-2014, 12:17 AM:

I wouldn't rate myself as an expert, but I've worked with barcodes a lot over the years.

What type ("symbiology") of barcodes are you scanning? If the answer is "I don't know, they're just barcodes", photo one and post it up. There are various schemes with various types of barcodes... Also, if you capture the scanner output into Notepad, what do you get?

quote: Marcel Birgelen
Funny how you configure it by scanning barcodes... Maybe that's the standard way of doing it nowadays and I'm just a bit old-skool.

Scanning funny barcodes out of the book has been the standard configuration method since, well, since before barcode scanners were affordable, and HP wands were what we used. So ninetys at least. Some readers could be configured serially, it was in the manuals, but I don't recall anyone actually doing that. What usually happened was there was a photocopy of the required setup codes on a single bit of paper so replacement or addional readers could be quickly configured.

Posted by Marcel Birgelen (Member # 6801) on 11-01-2014, 05:37 AM:

I'm no real barcode expert either. And like many around us, I have encountered them several times in several forms and most of them indeed were either configurable via serial or via USB and the included software. The first generation I used, were those horrible pens you needed to swipe over the code, at exactly the right speed. Maybe some of them were also configurable by scanning codes, and I didn't know that nor did I really care [Wink]

.

I've seen a similar (or maybe identical) problem Mike describes before though and this happened while scanning EAN-13 codes (nowadays the international standard for retail products) at a cashier. The last check digit was included in the output and as a result, the IDs didn't match with the database. The solution was disabling the check digit in the output. This all happened years ago, so memory isn't fresh. Those were Symbol scanners and they're usually pretty descent. They also specialize in those kind of products, whereas this Inateck seems to be some Chinese brand with a semi-German front, not particularly specializing on barcode readers, but on shiny accessories and peripherals.

The documentation of this particular scanner can hardly be called documentation. It's a single page and the English is broken. There doesn't seem to be an option to disable check digits. So I guess the only hope is that it's misreading those codes for something else and by either enabling the correct barcode type(s) and disabling all the others, the problem is fixed.

Posted by Mike Blakesley (Member # 26) on 11-01-2014, 08:35 PM:

quote: David Buckley

What type ("symbiology") of barcodes are you scanning? If the answer is "I don't know, they're just barcodes", photo one and post it up.

They are just typical UPC product barcodes like you would find on any product (at least, in the U.S.!) The format is 0-00000-00000-0. I'm not at work right now but if that's not enough info to let you know what's what, I can take a picture of one later.

Posted by Mike Blakesley (Member # 26) on 11-01-2014, 10:27 PM:

I did scan a code into Notepad and it just gives the same numbers that are on the barcode. So bottom line, I just need to figure out how to stop it from sending the list freaking digit. I guess I will email the support address (not going to hold my breath on that one). [Big Grin]

Posted by Randy Stankey (Member # 64) on 11-01-2014, 10:37 PM:

Stupid question... Could this be a carriage return vs. linefeed issue? e.g. The device is sending only a linefeed at the end of the character string when the computer/software expects a carriage return. (Or some permutation of CR>LF, LF>CR, LF+CR or some such thing?)

Posted by Mike Blakesley (Member # 26) on 11-01-2014, 11:12 PM:

It does send a carriage return but I don't think that would make a difference to the software we're using. The only issue is, the software does not want the very last digit of the barcode. (Unless those two are correlated somehow?)

If I scan an item on this new scanner into Notepad, it sends the whole 12-digit UPC code plus a carriage return. If I scan the same item on one of our older scanners, it sends the UPC code minus the last digit, but also with a carriage return.

Posted by Randy Stankey (Member # 64) on 11-01-2014, 11:53 PM:

The scanner shouldn't need to send the check digit. Should it?

Check digit = 10-MOD10[(sum of odd-position digits*3)+(sum of even-position digits)]

The scanner should do that calculation, not the software. If the check digit matches the scanner's calculation, it "knows" that it has a complete scan and no longer needs that digit. If the scanner does not get the right check digit, it keeps on trying until it either gets it or until it times out or until the user aborts the scan. In any case, the check digit is inconsequential to everything except the scanner. It does not need to be passed on.

I don't understand why the scanner would need to pass on the check digit unless the computer software wanted it for some silly reason.

There should be a way to shut that off. Shouldn't there?
(In the computer's software?)

Another stupid question...

Does the handset communicate directly via the computer's BlueTooth or does it need a little, USB doohickey?

Is the computer's software expecting input via one or the other?

Can that be altered in the software's settings?

Posted by Marcel Birgelen (Member # 6801) on 11-02-2014, 06:58 AM:

Most of those questions have been asked before and the answers are all in the posts above. Mitchell was already right on track with his first answer.

Some scanners (at least the few I worked with) allow you to enable/disable "check digits" for stuff like EAN or UPC codes. This one seemingly doesn't have that option, at least not easily located.

Another route, if the scanner's behavior cannot be altered, might indeed be checking if the software can be configured to accept the input including the check digit...

Posted by Carsten Kurz (Member # 5396) on 11-02-2014, 11:57 AM:

Right. Either this is a 'check' problem, the scanner 'reads' the code, but can not evaluate it against a common scheme, or the scanner is not configured to work with your software. You can configure scanners to end a successful read with either CR, CR+LF, TAB, etc, whatever the Software expects.

You can try to scan a different common product e.g. from a supermarket, to see if it accepts that code, or you can connect both this and one of your old scanners to any PC, open a text editor (e.g. Notepad), try to scan a code, and see which termination characters they output. Technically, these scanners are just keyboards with predefined phrase keys, so they work with any application supporting text input. Some applications may do their own checks on code numbers, some may rely on the scanner doing code break checks as well.

When you use the scanner e.g. with Excel, CR goes down one row, while TAB goes right one column.

- Carsten

Posted by Randy Stankey (Member # 64) on 11-02-2014, 02:12 PM:

There might be a reason for having a check digit get passed on. If the software accepts hand-keyed input, it might want the check digit.

Logically speaking, if a number sequence is keyed and it matches an entry in the computer's database, the check digit is inconsequential. If all of the other eleven digits match perfectly, then the twelfth digit must match. Keeping the check digit is redundant.

However, if software programmers ignore that fact they might just include the check digit as part of the number sequence without thinking. In which case, the check digit might be required.

Also, the software might perform the check digit calculation. If it does, it might need that digit. I don't understand why a program would do this. Like before, if it gets an 11-digit match, it logically must get a 12-digit match.

Yes, I heard you guys. Much of this has been covered in posts above. I'm just using a little Socratic thinking. Working things out as I talk. Since it has been covered and the problem still hasn't been solved, I don't see a problem with that. If I did, I wouldn't have posted in the first place. I would have let things resolve to their natural course.

Anyhow, I think the problem might not be in the scanner, per se. I think, maybe, the software is expecting different input than it is getting.

Some spitball ideas...
What would happen if you disabled all the bar code formats except for the one you need?

I read the instruction sheet. You're right. It's lame. Obviously transliterated from Chinese or something.

So, my idea would be to scan the bar codes on the sheet which disable all the formats except one. Then, re-enable them, one by one, until you come to a configuration that works.

Second, do check the connection method. If it is via USB doohickey or via BlueTooth directly shouldn't make a difference. As far as the OS and/or software is concerned, the scanner should appear to be a keyboard. Neither does it know nor should it care but, strangely, connection method might make a difference.

Try un-pairing the BlueTooth or disconnecting the USB doohickey then reconnecting/re-pairing the scanner.

The instruction sheet doesn't seem to be very clear on whether the scanner pairs via BlueTooth or needs the USB-thingy. Maybe the USB-thingy is included just in case the computer doesn't have built-in BlueTooth? Don't know. Just guessing, here.

I don't know what your software is or what it wants to receive in terms of data stream. Maybe it is interpreting the data stream one way but the scanner is sending data another way?

As discussed, CR/LF issues? But, you already have used NotePad and seen the data stream. There is a difference.

That's why I am wondering whether there is a setting or a parameter in the software that can be changed?

Again, I don't know. Just working it out as I go.

Posted by Mike Blakesley (Member # 26) on 11-02-2014, 11:13 PM:

Well the software is Carquest's Exploris point-of-sale system. So there's no way any of you guys could do any experimenting -- which is unfortunate, because I would love to see all your hilarious comments about how poorly-designed that software is. A more stupid piece of POS would be hard to find.

Just to give one example, to delete a purchase order you have to click on it to highlight it, then right click on it for a menu, then click "Delete" on the menu, then click "Yes" you really want to delete it, then click an "OK" after it has been deleted. (Pressing the "delete" key on the keyboard does nothing.) But I digress.

The scanner does include the li'l USB chip, which is the feature (wireless) I wanted it for. It also includes a real USB cable -- which I haven't used yet.

There is no way to make the software ignore that check digit. You can manually type in the UPC number (without the 12th digit) and that works, but if you include the 12th digit you'll get an "item not found" error.

Tomorrow I'll try Randy's suggestion of disabling all the code formats and trying them one by one. I did email the support folks for the scanner but haven't heard anything back yet.

Posted by Mike Blakesley (Member # 26) on 11-03-2014, 11:18 AM:

Update: I heard back from the scanner support people, who sent me an "addendum" to the instruction sheet that has a couple of "send checksum" and "do not send checksum" codes that are not on the main sheet. So... problem solved. Thanks for all the responses. I learned a lot about scanners!

Posted by Marcel Birgelen (Member # 6801) on 11-03-2014, 01:30 PM:

Maybe you can hint them to publish this addendum on their great support site. I'm wildly guessing you're not the only one having this problem, or they sold pretty few of those scanners up until now.

Posted by Mike Blakesley (Member # 26) on 11-03-2014, 01:40 PM:

It is a new model, but I'll pass on the suggestion.

Posted by Frank Cox (Member # 6258) on 11-03-2014, 02:53 PM:

I find it interesting that your software ignores the check digit. Checksums are there for a reason; you don't want to scan a transmission and have it come up with the price for a hubcap due to a crease or a shadow in the barcode sticker.

I'm a big believer in using checksums for things like part numbers and account numbers and whatnot. It can save you a lot of grief.

Posted by David Buckley (Member # 2600) on 11-03-2014, 04:56 PM:

The history of barcode applications on computers is murky. And the status of barcode checksums is even murkier.

Almost all of the time the barcode reader is set up as a "keyboard wedge". It's called that because prior to the USB revolution, most barcode readers are installed in-line with keyboards. With traditional RS232 terminals it was an RS232 wedge, and with PCs it was a PS/2 (or earlier, 5 pin) keyboard wedge. The barcode reader was configured to output the same as a person manually typing in the barcode.

And thus a whole several generations of shit software was built around this paradigm. Even today, with USB barcode readers, the readers are still almost universally used as keyboard imitators.

There are two problems with this approach. The first is checksum handling, where you want the barcode to have the checksum, but you don't want the checksum as part of the part number in the database.

The second is when the user reads a barcode and the cursor isn't in the right field to accept that data string. particularly funny when the program's menu choices are numbers and don't require the enter key to be keyed...

Ideally the barcode reader should be connected to the program through a connection way other than the keyboard. That way when someone reads a barcode, the program can act intelligently on what it gets, such as going to the right screen and field automatically, and checking the barcode format and checksums where present.

To misuse a local saying, barcodes done wrong.

/rant.

Glad OP has his reader working [Smile]

Posted by Marcel Birgelen (Member # 6801) on 11-03-2014, 05:08 PM:

It depends on your application and purpose. First of all, your scanner should use the check digit internally. If it doesn't add up, the scanner should not transmit any barcode, but either do nothing or indicate a scanning fault.

There's not so many that can go wrong between scanner and your application. As Randy already outlined, most are used to imitate keyboards. They hook up to your system like some virtual keyboard and send the barcode they scanned to your application as if you typed it yourself. USB uses several data integrity checks of its own, the same goes for several wireless protocols like bluetooth, Wifi, etc. There's really not that much in the process that needs error correction. As long as you do not interfere with your keyboard while the thing is scanning.

The more professional scanners usually come with direct API access. You can integrate your software with them, even have events triggered by "scan events" and act upon them accordingly. If integrity is really important, for example in medical solutions, you probably want to check your checksums several times. Maybe you even want systems with more sophisticated checksums than UPC and EAN codes.

Posted by Mike Blakesley (Member # 26) on 11-03-2014, 05:44 PM:

I do think the scanner checks the checksum internally. If things don't add up, you get the red light and the error beep. The only issue here has been whether that checksum digit is sent to the computer.

Posted by Randy Stankey (Member # 64) on 11-04-2014, 01:01 AM:

A scanner (in a grocery store) doesn't know whether it is looking at a carton of milk or a loaf of bread, nor does it care. It only cares whether the symbols it sends to the computer/software are the same as the ones that are on the he label. The checksum is the scanner's way of deducing that.

If the checksum calculation comes out correct, it stops trying to scan and passes it's data down the line via whatever interface it has been configured to use. If the checksum does not come out correct, it will keep scanning until it gets the right checksum, until it times out and gives an error signal (beep and flash a red light) or until the user aborts the scan. The scanner doesn't "think" beyond that.

Once the scanner has done its job, the computer/software takes over. If the data it receives matches something in its database, it proceeds. If not, it activates an error subroutine. Check digits may or may not be included in that process. It doesn't matter unless the programmer(s) decide that it does.

The only thing that really matters is whether the scanner and the computer/software behave consistently with respect to each other. In our case, they were not consistent. That was the crux of the problem and, once solved, everything worked.

Even though the software in question is a POS (piece of shit) I think the scanner manufacturer was more at fault than the software programmers. The peripheral should be easily configured to match software and not including the information to do that is bad practice, IMO.

I think that the instruction manual should include the necessary codes and information for the user to configure it to his needs. Judging by the "Pidgin English" the manual was transliterated from another language, probably
Chinese.

I think this whole problem and a lot of future problems could be solved if they just hired somebody fluent in the target language(s) to rewrite the manual so that it makes more sense and gives the information needed to solve problems like this in the future.