scanning 2D barcodes (with odd characters) crashes LabVIEW 8.6

[jcarmody]

---

Ravens Fan wrote:

So if having a front panel control handle the characters works for you now, how were you trying to use the scanner before?

---

Not a front panel control, the front panel.  I take KeyFocus away from everything and use the VI's Key Down? event.

[RavensFan]

Okay, you were using an event structure to essentially capture keystrokes.

I can believe that it might not work since the key down events use virtual keys and scan codes to determine which keys were pressed as opposed to a true ASCII implementation.  A lot of keys on the keyboard don't have an ASCII character associated with them such as scroll lock and function keys.  That is why you can tell the difference between a 1 on the number pad versus the 1 from the number row of keys.  I guess the scanner's is able to generate characters that its driver which virtualizes it into a keyboard causes lockups.

Now the question is whether this could be considered a bug or not.  And whether it would be a bug in the scanner's driver, or in LabVIEW's key down event structure.  I would lean towards a LV bug because you said that Word was able to take the scan codes it was getting without crashing.  Though it is possible that the driver is generating non-standard scan codes.

[jcarmody]

This is how I'm getting around this.

Message Edited by jcarmody on 03-12-2009 10:12 AM

[JeffL]

Hi jcarmody,

I tried typing in the characters directly then converting to code and hex but I did not get an error in LV 8.6.1. You said it does not even have to run, correct?

What is the exact order of steps that causes the error to occur without running it?

[jcarmody]

Jeff,

The exact order of steps involves scanning the barcode that contains these characters.  How did you type an ASCII 0x04 (End Of Transmission) character?  Ravens Fan said you can "enter them in normal display by holding down the alt key and entering the 3 digit ascii code on the number pad".  This doesn't help me if that doesn't cause a crash because we're scanning, not typing, these characters.  (Perhaps it helps shed light on the problem.)  Is that how you typed them?  If that is the case, what are the three-digit ASCII codes for these characters so I can try it myself?

So, the steps I take to cause this crash:

1. Open a new VI
2. Create a String control
3. Give the String control text entry focus
4. Scan the barcode

You are correct about it not having to run, but you could add a step between 2 & 3 to run continuously (or put the control in a loop).  It doesn't crash every time (maybe half of the time) and I'm using 8.6, not 8.6.1 (yet).  Also, LabVIEW doesn't crash if the VI is the active application but the String control doesn't have the focus.  In fact, that's how I'm planning to work around this problem.

[Broken_Arrow]

About a year ago I did some 2D barcode scanning code and had two issues. I'm not saying these are YOUR issues, I'm just saying it's something to watch out for...

1) The scanner sent tabs that I didn't see, so I had to deal with that.

2) The " [ " thing at the beginning caused headaches because LabVIEW uses that as a signal for special formatting.

I also used a front panel control (hidden) and had it set to Update while Typing.

[jcarmody]

Did either of these things crash LabVIEW?

[Broken_Arrow]

Jim,

I don't recall a crash, but it was over a year ago - I just know it gave me fits. The code started complicated and ended up tiny and very simple. See attached. The notes I made were the important things, that and the two "\\" before the [.

edit: BTW, my scanner also had two ?? at the end and not decimals. It was after I programmed the scanner itself to have a known character at the end (a comma) where I started to have success. It was a CODE scanner. I also wrote code for a WASP, which was not nearly as troublesome.

Message Edited by Broken Arrow on 03-13-2009 09:33 AM

[JeffL]

I have typed it in directly (matching your entries), typed it in with the ascii codes, and sent it from one VI to another with the VI server and a byte array to string of the decimal equivalent. None of these cause the error.

jcarmody, please attempt to recreate the issue without your specific hardware. That way the rest of us can try to root out the problem (assuming it isn't the hardware or the code in between that and the string control).

Also, here is a page I found with the ASCII code.

[RavensFan]

Jim,

I would try another approach.  You have a method that allows you to work around it without crashing.  I think the issue is not with the ASCII values but with the keyboard scan codes.

See if you can modify your VI so that it takes the values of Char, Vkey, and scan code that come out of the nodes in the event structure and build them into an array to display on screen.  Then it might be possible to compare the values with each other and whether a normal keyboard could legitimately generate a particular code.

Another possibility.  Can you create various bar codes, perhaps one for each character in the string you have to see if it is one or more particular characters causing the issue?