02-25-2013 12:37 PM - edited 02-25-2013 12:39 PM
So, I am a bit confused. I am scanning a barcode into a LabVIEW string control. When I have the string control display mode in "hex" it shows one thing when I scan. When I scan into a string control in normal mode, then switch to hex, it shows something else. I am guessing that is because if you "type" into a control in hex mode, it expects you to put the proper characters respresenting particular ascii values. But, I just wanted to verify this.
The bigger issue, I have downloaded a third party application that will display non-printable characters like so; <ascii value>. It is displaying what I expect, the group separaters, SOH character etc. The strange thing is, in LabVIEW, even in Hex mode, certain non-printable characters aren't there. For instance, I don't understand why there is a 6 at the beginning of my string? Furthermore, it seems the group separator (a non-printable character) appears in the string, but the other non-printable characters don't. They must be there, though, because the third party application finds them. Any suggestions?
Solved! Go to Solution.
02-25-2013 01:14 PM
Is this a serial port scanner? Coudl you be running into a weird issue with the mode where characters are getting stripped out by the communication interface?
02-25-2013 01:20 PM - edited 02-25-2013 01:20 PM
@Mark_Yedinak wrote:
Is this a serial port scanner? Coudl you be running into a weird issue with the mode where characters are getting stripped out by the communication interface?
Ultimately, it will be. It's going into a USB port now, as this computer doesn't have a serial port. I tried setting it up per the manual in "com port emulation mode" but I can't get it to recognize the device as a virtual com port. Their read me mentions nothing of Windows 7 so I'm curious if it's not supported. Although, when I put it in this mode, my computer showed the popup saying the driver was being installed.
Anyways, for now, I am using it in just keyboard mode. The odd thing is, that third party program is able to parse the scanned characters fine (admittedly, I don't know what it's doing behind the scenes) but it is able to do this without any configuration changes to the scanner itself. Just plug it into the USB port with the default settings, scan, and it works fine.
02-25-2013 01:42 PM - edited 02-25-2013 01:43 PM
Yes that is the expect behavior.
Forget the bar code reader for now.
Hand type from the key board into the hex display and you will only be able to enter '0123456789ABCDEF'
If the control is set for HEX then you must enter the string in as HEX not ASCII
02-25-2013 01:47 PM
@Omar_II wrote:
Yes that is the expect behavior.
Forget the bar code reader for now.
Hand type from the key board into the hex display and you will only be able to enter '0123456789ABCDEF'
If the control is set for HEX then you must enter the string in as HEX not ASCII
Gotcha, that makes sense. So it would have to be in normal mode. That's fine, but I still don't understand why the non-printable characters are thrown away. Is this a function of a string control not allowing them?
02-25-2013 01:49 PM - edited 02-25-2013 01:51 PM
Got it. I enabled "keypad emulation" which does the following: "Enable this to send all characters as ASCII sequences over the numeric keypad. For example ASCII A transmits as
“ALT make” 0 6 5 “ALT Break”." Wayyy too many settings on these barcode scanners. I'm curious to see how it will ultimately work over a serial port. For reference, this is a Symbol DS3408
02-25-2013 01:52 PM
Is what you are looking for is the Hex values
36,5D,50,44,31,35 etc?
Then use the "String To Byte Array" on the string that is read in.
02-25-2013 02:18 PM - edited 02-25-2013 02:19 PM
@Omar_II wrote:
Is what you are looking for is the Hex values
36,5D,50,44,31,35 etc?
Then use the "String To Byte Array" on the string that is read in.
Thanks, I already have all that no problem. Was just trying to understand why the scanner wasn't populating the string control correctly with what I expected. I had already gotten the parsing to work by manually typing in the expected values for a single known barcode, but I wasn't about to do this to test many different ones.
03-01-2013 09:25 AM
Looks sort of like a CLEI code.