Barcode Reader (USB HID Interface) text entry without Window/control input focus

[david.bolt]

Dear Andrew

First of all my apologises, the keyboard input devices controls are indeed located under the functions palette under Connectivity >> Input Device Control as David mentioned.

I have investigated this further and agree that using a Serial Port method would be a good choice. I have found a related KB referenced below in how you could implement this:

http://digital.ni.com/public.nsf/allkb/77C08FED448DF80786257547005686DB

Please let me know if this is useful. With regards to using a VI/dll combo, I'm going to explore this option too and I will advise on my findings in due course.

[Ben]

Sorry to take this thread slightly off target but...

I generally use an off screen control and give it key focus when I want to read from the barcode.

Done diverting,

Ben

[DavidBoyd]

Andy,

I was looking at: Symbol DS6707 Digital Imager Scanner Product Reference Guide (P/N 72E-83978-07 Rev. A)

On page 7-5, there is a setup barcode for USB scanners entitled 'Simple COM Port Emulation', though I didn't immediately find any further description of its effects.  If it parallels my Intermec experience, the USB device will enumerate as a COM port, without requiring any further driver loading.  Find the COM port number in Windows Device Manager, add it to MAX with an alias (I always use 'BARCODE').

In LV, I create a small independent VI which loops forever, doing a VISA read with a reasonable timeout (1s) for a CR-delimited line.  Of course, the VISA Read returns a timeout error if there is no scanner activity. If the VISA Read DOES NOT time out, I parse the returned string for the barcode type - (I usually enable the AIM ID on the scanner, then parse that preamble out to an enum of the different formats).  I generate a user event, its data is the barcode type and the remaining string.  My user interface routine has an event handling case in its event structure that fires whenever the scanner reports a decode.

The parsing VI knows to exit its while loop and terminate when the user event refnum is destroyed.

Hope this is a viable alternative for you.

Dave

[AndyVessey]

Hi All,

Nathan, Sorry I misunderstood, yes putting the scanner into COMx emulation mode is a good idea/option but the Symbol scanners have a standard set-up here and it would be nice to keep it that way. You just get one out of the cupboard or borrow one from someone and off you go. If I run out of steam on this persuit that is the best drop-back solution to date - cheers.

David Boyd, Thanks for the info on where the input vi's are, I didn't know where the source of these came from - connectivity pallet - thanks. I'm looking more closely into these now. Also, yes as above regarding the COM EMU. Regarding your post 02:49PM It all becomes not very portable code once MAX gets involved with alias names etc. For a none portable/dedicated application we do do the MAX/alias way - sorry I should have mentioned the portability in the requirement spec. I'm hoping to install the app on some technicians PC's some R&D PC's and some production PC's so an exe will be the way I guess.

David Bolt, Thanks for the link - as above regarding the COM EMU. 

Ben, Off target regarding the thread and the requirement spec but nice Avatar and qualifications! 🙂

Andy

[Andrey_Dmitriev]

---

Ben wrote:

Sorry to take this thread slightly off target but...

I generally use an off screen control and give it key focus when I want to read from the barcode.

Done diverting,

Ben

---

Well, and if barcode reader in your right hand, and your left hand on the PC keyboard... And you have press buttons at the same time? 😉

Really top solution is to bypass information from USB HID device into LabVIEW over keyboard. I mean its not possible probably just with standard LabVIEW components, and something should be changed on Operation System side...

Andrey.

[Ben]

I saw no mention of Shane's USB Nugget so let me make sure theese don't help.

Getting Started withUSB communication via VISA part #1

Part #2

It just seems like a shame not to include those Nuggets in this thread.

Ben

[Andrey_Dmitriev]

Exactly right link, Ben! Ah, I just forgot about this post.

Andrey.

[AndyVessey]

Hi all,

I got dragged away from this to look at something else unfortunately 😞

I’ve done some reverse engineering and investigation on the Keyboardmonitor.vi /lvinput.dll as it doesn’t seem to have much documentation.

A few possible facts about this follows:

Keyboard monitor.vi

Initialize Keyboard.vi (lvinput.dll)

Poll >>> Acquire InputData.vi / keyboardAcquire.vi (lvinput.dll)

“I believe LabVIEW uses the Microsoft DirectX functions"wrapped" by the "LVInput.dll" file” ?

“You must have DirectX 8.0 or later to use this VI.” – a clue

DLL Functions

getKeyInfo

getKeyboardState

My view… the LVIput.dll has probably the best way of passing multi key-press keyboard status information to a computer system. The multi key-press part I guess is depending on the keyboard hardware X/Y matrix to support the dll. After this limitation the dll will report as many simultaneously pressed keys as possible.The most I had working was 6 but not in sequential order, this was trying various combinations of keys until 6 worked. The status report of the keyboard is in the form of an array where each key has an element. You can think of this as an array of status bits – one for each key on the keyboard.

The two attached vi’s have this functionality stripped back to basics. Run the 'Read KB AV.vi' with sub vi Readlvinput DLL.vi and press numeric keys 0-9 on the PC keyboard and you will see the status bits in the array change from 0 to 1. Try pressing more than one key at once. I have a HP USB HID keyboard - your keyboard may effect the result of this.

A problem with this is the lack of a synchronised interrupt/strobe signal that indicates when a key down or key release event occurs. On either of these events a re-read of the status array would need to be performed.

Without the interrupt a constant pole would need to be done with some intelligent timing interpretations I guess? or could a key-press event be attained from elsewhere to work with this??

I will be picking this up again in the near future, thanks for all the help from everyone - much appreciated - I hope this thread to date will be useful to others.

Andy

[Andrey_Dmitriev]

Hi, Andy,

Your experiment is interesting. Other way to get pressed keys into your application is WinAPI (don'n remember which functions exactly responsible for that).

But another part of problem - how to "partially disable" USB HID Interface in Windows. So, the only your application should receive pressed keys, and nobody else.

Andrey.

[Intaris]

Does the scanner actually identify itself as a USB keyboard when you plug it in?  Does it have an option to still stick to HID but drop the keyboard identifier?  This would open up other opportunities to communicate as Windows would then allow installing other drivers for the device.

I see in the manual for the device that you can change the "USB DEvice type" relatively easily.  Have you tried the different settings to see how that works out? 

You need to also bear in mind that the actual communication between USB Keyboard and PC is very different from what you experience as a user.  It's horrifying to see how the keypresses are communicated.  It also becomes clear why every keyboard only supports so many simultaneously pressed keys.....  It's in the USB HID reference document.  Read it at your own peril, it's very technical.

Shane