From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

get data from bar code scanner

You don't need all of the keyboard input functions. A string control in LabVIEW acts the same as Notepad. Use an event structure to capture the value changed event (which is triggered by the return character or end of line character). I do this all of the time and it works good for me.

 

See VI attached




Joe.
"NOTHING IS EVER EASY"
Message 11 of 32
(2,170 Views)
@Joe_H wrote:

You don't need all of the keyboard input functions. A string control in LabVIEW acts the same as Notepad. Use an event structure to capture the value changed event (which is triggered by the return character or end of line character). I do this all of the time and it works good for me.

 

See VI attached

I believe this won't work.  He stated earlier that the VI running won't have key focus.

 

Artem:  Let me reword problem statement a bit...  we can ignore the fact that this is a scanner at all.  Really what you want to do is make a keystroke logger in LabVIEW - something that runs in the background quietly, detects "keyboard" input (scanner really, but you can't tell the difference), and records / processes it.

 

There is nothing in LabVIEW natively that I know of that'll do this.  I haven't ever attempted it before, but I suspect you are going to end up registering for a callback system event.  I'd start searching things like "Windows API capture keypress event" and the like.

0 Kudos
Message 12 of 32
(2,155 Views)


 

My task really bigger. One app (not LabVIEW) controls the system, I can't change it. And this app take data from scanner. And I need second minimized app (LV). This one will check every code in DB. If code has flag "not tested", the second app must open warning window.



So you have one app that you want to have take data from the scanner that behaves like a keyboard, but you also want LabVIEW to take data from the scanner that acts like a keyboard?

 

That makes no sense!  Have you ever seen multiple applications in Windows take data from a keyboard at the same time?  Only which ever window as focus at the moment will capture the keystrokes coming from the keyboard.

0 Kudos
Message 13 of 32
(2,146 Views)

Hi RavensFan,

 

I heard of such tools!

Usually they are used to steal account data from users and are called "keyloggers"...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 14 of 32
(2,142 Views)

Artem:  Let me reword problem statement a bit...  we can ignore the fact that this is a scanner at all.  Really what you want to do is make a keystroke logger in LabVIEW - something that runs in the background quietly, detects "keyboard" input (scanner really, but you can't tell the difference), and records / processes it.

 

There is nothing in LabVIEW natively that I know of that'll do this.  I haven't ever attempted it before, but I suspect you are going to end up registering for a callback system event.  I'd start searching things like "Windows API capture keypress event" and the like.


Problem: there is an engraving machine. He has a code scanner. On the screen, the buttons: "start" and "stop". No keyboard or mouse.
The worker scans the code and presses "start". The machine engraves the code on the product.
We want to be sure that the product has been tested, otherwise we do not need to engrave the code. We can not change the program of the system, but we can run a parallel application that will read the data in parallel and check them in the database.

0 Kudos
Message 15 of 32
(2,129 Views)

RavensFan wrote:

That makes no sense!  Have you ever seen multiple applications in Windows take data from a keyboard at the same time?  Only which ever window as focus at the moment will capture the keystrokes coming from the keyboard.


It works, but not correctly.
On my 1st screenshot notepad and vi works simultaneously, but VI get incorrect data.
I thougt the Acquire Input Data VI will return me only new data from buffer, but look like it return all data in buffer.

0 Kudos
Message 16 of 32
(2,133 Views)

How do you enforce the user to NOT press start? 

Can you block the start of the other program?  Or is it up to the user, to wait on your program NOT to come with a pop-up, before he/she presses start? 

How long time should the user wait for that? 

Are you sure that he/she will not press start with the scanned bar code? 

 

In what language is the other program made? 

 

0 Kudos
Message 17 of 32
(2,115 Views)

An alternative way to handle this might be to connect a barcode scanner via virtual serial (rather than virtual keyboard wedge), read it via VISA into your LabVIEW application, do whatever data validation/database lookup you've described, and then, only if it passes the validation, send keystroke data (using the WinAPI SendInput() function in user32.dll) for the engraving application to process.  If the "Go" or "Start" control on that application supports a keyboard shortcut, you could even generate that keystroke, so the entire process could be hands-off.

 

Just a thought.

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 18 of 32
(2,097 Views)

dkfire asks the Key Question -- how do you prevent the User from pressing Start after the Scan?  Do you have control of the Display?  Do you interact in any way with the Engraving Machine?

 

One of my applications uses a Bar Code scanner to select specific items for a test.  We know which items go to which Test Station.  The user selects an Item, scans it, the program says "Place in Test Station <whatever>" or "No, we are not testing that item".

 

So if you want to use your scanned information to "make a decision", you need to interact with the Operator in some way.  

 

If all you want to do is skip the Engraving, would returning an empty string do the trick?  Would that prevent an engraving, and would the operator notice and remove that (presumably faulty) device?

 

Bob Schor

0 Kudos
Message 19 of 32
(2,083 Views)

If the code is correct, the program keep silent.
If the product is not tested, the program opens a warning message.
The operator himself decides whether to continue engraving, or not.

0 Kudos
Message 20 of 32
(2,070 Views)