|
|
This topic comprises 2 pages: 1 2
|
|
Author
|
Topic: Barcode scanner troubleshooting
|
Carsten Kurz
Film God
Posts: 4340
From: Cologne, NRW, Germany
Registered: Aug 2009
|
posted 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
| IP: Logged
|
|
Randy Stankey
Film God
Posts: 6539
From: Erie, Pennsylvania
Registered: Jun 99
|
posted 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.
| IP: Logged
|
|
|
|
|
|
|
|
|
|
|
|
David Buckley
Jedi Master Film Handler
Posts: 525
From: Oxford, N. Canterbury, New Zealand
Registered: Aug 2004
|
posted 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]](smile.gif)
| IP: Logged
|
|
Marcel Birgelen
Film God
Posts: 3357
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012
|
posted 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.
| IP: Logged
|
|
|
|
Randy Stankey
Film God
Posts: 6539
From: Erie, Pennsylvania
Registered: Jun 99
|
posted 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.
| IP: Logged
|
|
|
|
All times are Central (GMT -6:00)
|
This topic comprises 2 pages: 1 2
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|
Home
Printer-friendly view of this topic