Symbol FZ barcode scanner not reading properly in LV7.1

[Alias user name here]

I too am seeing this problem with a USB POSX Barcode scanner. Firstly, I DO NOT WANT a keyfocused string control on the diagram, that's a pretty poor and brute for implementation - and not desireable for my application. This device works as a keyboard wedge - sending characters from the barcode scanner into the Windows Keyboard buffer message system.

I created a 'background' keystroke/barcode scanner detection using the LaBVIEW Input Device routines - accessing the keyboard. I too am seeing the LV keyboard function return missing or duplicate charaters from the barcode scanner. Opening Notepad or Word - properly captures the barcode scan with no dups or missing chars. It would be nearly impossible to filter dup chars - as some barcode actually have repeated chars.

Setting a delay in the keyboard input polling loop seems to improve the problem (I am NOT USING THE EVENT STRUCTURE) - but it does not go away. Also, this is not an effect cure - as loop poll timing is effected by CPU loading, other apps running,etc.

I am going to chalk this up to a bug in the LabVIEW keyboard routines - as it should not return duplicate or drop characters. It would appear this function is not doing any housekeeping - it appears to be destroying unread chars in its buffer, or rereading chars in its buffer it already read.

I don't know why the function written this way would be useful or desireable for any application - Can NI Tech Support issue a CAR for this issue?

[rolfk]

A popup dialog with a string control with keyfocus is NOT a brute force or bad approach. It is IMO the way to solve barcode scanner applications where you want to use a keyboard wedge scanner. After all it gives the user the possibility to input a barcode identifer of some sort even if the barcode scanner is broken, so that production won't stand still while you have to wait for the spare barcode scanner to arrive.

By configuring a barcode scanner to terminate each barcode with carriage return or line feed you can program your dialog window in such a way that it automatically dismisses itself after seing that character. Gives your user a GUI with feedback that the barcode should be scanned now, avoids any extra mouseclicks to be done by the user and allows him to still enter a barcode through the keyboard eventhough the barcode scanner may be not available at the moment.

If you really need to go with a hidden barcode scanner procedure, the only reliable way is to use a serial port barcode scanner. For new USB scanners this is usually an extra driver you can install which installs as COM port driver.

Rolf Kalbermatter

[Dennis_Knutson]

I agree with Rolf. If I didn't provide a manual entry or a way for the operator that the correct bar code was scanned, I would have every production person down my throat in about 5 minutes. As I mentioned, I have no problems with my USB bar code scanner using a string control. Since you are using the Input Device functions, why don't you post your VI to see if someone can reproduce the problem or see if there's a problem in your code. There could very well be a bug in NI's routine. I haven't heard of anyone using them in the manner you are so it may be a condition that was never tested. NI would be as interested in fixing something as you are but a bug needs to be confirmed and reproduced before it can be fixed.

[Alias user name here]

Don't assume all barcode scanners are held in human hands, or every application is written for human interaction.

Putting the barcode scanner issue aside: the fact the keyboard input function does not return the correct character string is bad. Notepad a free program is able to perform this task flawlessly.

I problem with the response - is that its not helpful to my situation. It's like asking for directions to Disneyland and being told "Ah, you don't want to go to Disneyland"

I've been programming in LabVIEW for awhile, I get my hackles up when I run into a problem with a function that does not work right. Of what possible use or under what circumstances is a keyboard polling routine USEFUL if it drops characters or adds duplicates?

"Ah, don't you worry about duplicates...."

I though this NI forum was for help - not redirecting me to a kinder and gentler path.

[Dennis_Knutson]

Like I said, post your VI so the problem can be analyzed. You say the function doesn't work. If you want it fixed, you have to demonstrate that. No reason to get your hackles up (whatever a hackel ist). If someone tells you there's a bug in one of your programs, don't you ask the same thing?

[Underflow]

1. hackles The erectile hairs along the back of the neck of an animal, especially of a dog.

[rolfk]

Well, for barcode scanners not held by humans I have always used serial port scanners in the past. They give you the kind of control you need for such applications.

As to notepad working: A LabVIEW string control is most probably working just as well, isn't it? The difference is that the string control and the notepad application see the key scan codes after it has been translated into actual characters and placed in the application message queue by the Windows operating system. The keyboard VIs on the other hand have to hook into low level system functions to receive the keys without eating them up and there they are still the scan codes and as such not necessarily what you will see in the higher level functions. If the problem is similar to what was happening to the original poster, the scanner is placing some special scan codes into the stream for whatever reason. Could be an initialisation sequence problem of the scanner when the computer starts up and scans for keyboard devices, or it might just be a buggy scanner.
The keyboard VIs however will likely encounter new problems in the future with new Windows versions since they interface on such a low level to the Windows system that any number of small changes to the working of Windows may result in new behaviour on such a low level. So relying on those VIs for production type applications is IMO not a good idea, I wouldn't do it unless I own the C source code of the interface DLL with which I had done these functions.

Rolf Kalbermatter

Message Edited by rolfk on 07-01-2005 11:04 AM

[Alias user name here]

My apologies for coming off too strong. My experience tells me this is looking like one of those situations were a trivial thing will cause a critical problem.

The keyboard output vi seems to work as coded. Each time it's polled it returns a 105 element array of the key states of the entire keyboard. But you can't tell if a state change of the keyboard occured, so you don't know if the key was held down - or pressed again between polling.

As its performance is based on your set program delay - Different CPU loads and computer speeds will cause this function to perform with varying accuracy. I cannot think of a way with information returned from this function to determine a key-hold or new press instance.

The event structure seems to perform better - but does exhibit and error about 5% of the time. Slowing down the barcode scanner to its slowest speed also helps.

[alvalee]

You said “Slowing down the barcode scanner to its slowest speed also helps”? Would you please give me some materials for this theory? Thanks