LabVIEW
Which port will the USB scanner send data through?
Solved!
@TakeANap wrote:
Perhaps a newbee question. I have a USB-scanner that sends data as a keyboard. The application that has focus receives the datastream. In what way can I have an event structure to wake up and receive the data? What kind of VI can I use? If I can make a guess I should use VISA Read. Correct?
Wrong! That scanner works as a keyboard and sends its characters as keystrokes. What you should do is have a front panel with a string control, make sure the key focus is set to that string control then prompt the user to scan a barcode.
Configure the scanner to terminate barcodes with an EOL character such as carriage return or line feed and then in your VI you can either configure the string to "Limit to Single Line" and wait on the "Value Changed" event in your event structure, which will be triggered when the string receives a line ending character. Aternatively you can set the string to "Update Value while Typing" and check in the "Value Changed" event yourself for the configured EOL character that you set in the scanner to abort the entry loop, or possibly for a fixed size character code.
Advantage of this approach is, that the operator also can enter the barcode manually over the keyboard if the scanner doesn't work or can't read the barcode for some reason.
Typically you want to structure your test application in such a way that there is a sequence to go through. Early on in that sequence you have usually the barcode entry. Have your application prompt the user for the barcode and set the key focus to that string. There really shouldn't be any reason to continuously reset the keyfocus to that control.
I usually even have a special pop-up dialog with just this string control (and a cancel button) that I show at the moment the barcode should be read. Set the key focus to the string control when entering that VI, wait in an event loop for the barcode, and terminate the dialog if a valid barcode has been entered or the user pressed the cancel button. That is all there really is to it. Messing continuously with the keyfocus in your app is a sure way to make it start to behave erratically once you add other functionality with GUI elements to it.
@pincpanter wrote:
The scanner makes known itself as a keyboard. I guess that also using Windows API it would be difficult to identify it as a scanner (unless you retrieve the model info in the driver properties).
The scanner simply announces itself as USB-HID device with keyboard functionality and the OS automatically adds it to the possible keyboard entry devices. From there the OS event handling simply registers itself as an event receiver and all the "keystroke" messages are sent there. The OS then checks what the message specifically says, determines which application has currently the focus and sends the according keystroke event to that application.
There is no way from an application point of view to distinguish from which specific device such a keystroke event is originating. It's simply a WM_CHAR event at that point. The whole thing is under the hood even more complicated since the USB driver actually receives an message for every key down and key up event. The Windows message loop then combines and translates them into WM_CHAR events.
Many scanners can also be configured as a serial port adapter. If you do this, you can use VISA Read.
Nowadays with USB that is indeed often so. The USB connection stays the same, and in the manual you have some barcodes that you can use to configure the scanner into a specific mode, and also to configure things like baudrate, etc. if you set them into serial mode. It then announces itself as an USB-COMM device rather than an USB-HID device and Windows (and other OSes) will install it as an additional serial port in the system, instead of as a keyboard device.
This allows more detailed control of when you want to scan, for instance if the scanner is built into a production line and you want to trigger a scan through software rather than tell an operator to press a button on the scanner. And here you indeed will use NI-VISA to write and read to and from the device.
It all depends on your applications. If an operator is doing the scanning manually, the keyboard mode is usually the more easy solution. If it is in a fully automated test system you usually want more software control over when a scan should be made and then serial operation is much more convenient (but requires some extra programming to send the right commands to the scanner and decode its response.
