LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Which port will the USB scanner send data through?

Solved!
Go to solution

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?

 

 

0 Kudos
Message 1 of 12
(300 Views)

@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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 2 of 12
(292 Views)

Aaa. Yes. Of course. Not VISA Read. 

 

The method you mention with a string input with continous focus I had in my last project with scanner.  I had a loop that every 500ms set the string input control in focus. It felt rather "raw" and not professional (it was made in a hurry).  I thought labview could distinguish between the USB-keyboard and a scanner connected to a predefined USB-port (that's why I tought of VISA Read). 

 

Yes. The scanner software can put preceding chars before the data and also CRLF or EOL.

0 Kudos
Message 3 of 12
(257 Views)

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).

Many scanners can also be configured as a serial port adapter. If you do this, you can use VISA Read.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019
0 Kudos
Message 4 of 12
(245 Views)
Solution
Accepted by topic author TakeANap

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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 5 of 12
(242 Views)

@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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 6 of 12
(237 Views)

(How can I reply to a specific comment?)

Sequence, yes. The PCBA that the eq. tests have two QR-codes and I thought the personnel could prepare the next PCB by scanning the QR-codes while the first undergoing the test. However, the specification says now that we doing one PCB in a seq. That means, scan, put in jig, push start and so on. That opens up for a solution with a popup dialog with a string control. 

 

 

0 Kudos
Message 7 of 12
(165 Views)

That is interesting. I hope I get the time to investigate this.

 

 

0 Kudos
Message 8 of 12
(163 Views)

Both approaches have their merits.  I've tended to recommend the virtual comm port approach, because it ensures that my application receives scan data even if some other application "steals" window focus, or my application has been minimized, etc.  Also, my serial processing for that comm port checks the returned chars for the AIM ID, which I always enable on the scanning device.  This adds a preamble which tells what encoding of barcode has been targeted - code 128, code 39, QR, DataMatrix, etc - which, together with other pattern matching, can be helpful to route target barcodes to their intended targets where different codes may be used.

 

Fully in agreement that the comm port approach may take a little more development.  Typically I have a separate process which loops on a VISA Read, and when the read does not time out, sends the chars read into an event handler (via user event) for further processing as described.

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 9 of 12
(128 Views)

@DavidBoyd wrote:

Both approaches have their merits.  I've tended to recommend the virtual comm port approach, because it ensures that my application receives scan data even if some other application "steals" window focus, or my application has been minimized, etc.  Also, my serial processing for that comm port checks the returned chars for the AIM ID, which I always enable on the scanning device.  This adds a preamble which tells what encoding of barcode has been targeted - code 128, code 39, QR, DataMatrix, etc - which, together with other pattern matching, can be helpful to route target barcodes to their intended targets where different codes may be used.

 

Fully in agreement that the comm port approach may take a little more development.  Typically I have a separate process which loops on a VISA Read, and when the read does not time out, sends the chars read into an event handler (via user event) for further processing as described.

 

Dave


Yes. To connect the scanner (Zebra DS457 with config.software 123scan) as a USB-COMM are more safe. The scanner gets dedicated to one port. It feels more correct in this application I thinking of. The normal keyboard are used to other stuff.
I want to give the production personnel the luxury to not be forced to scan in a specific moment. In my mind I have a independent loop with a event structure that gets activated when something comes into the COM-port. The loop builds up a string until a CRLF+some other codebyte comes in. Then the string gets examined (header, data length, and the bytes at the end) and the QR-codes are extracted from the string.

I'm grateful for comments. 

 

I must test this with my keyboard. 🙂

 

0 Kudos
Message 10 of 12
(108 Views)