Adding a STX as a prefix

[Papoulos]

Hi all,

I've problem configuring a LS 2208 scanner.


I wanted to add a STX as prefix, but it seems it didn't take the good characters.

I use Scan Option / Prefix+Data then Scan Prefix+1002 (for stx).

But when I scan a test code on notepad++ it didn't send any stx char.
But if i press Shift while i'm scanning the barecode it gives me the STX.

So after several research I found out that the "1002" prefix code send "CTRL+b" and not "CTRL+B" or "CTRL+SHIFT+b".
Thanks to outlook keyboard shortcuts...

Is there a way for me to send the CTRL+SHIFT+B or "CTRL+B" as a prefix ?

 

[JRB-Bldr]

The ascii key received by the program is 0x02.

As Dan pointed out above and as I have suspected for a while, the problem is in your Application, NOT the Scanner.

I would now recommend that you contact your application vendor/manufacturer and find out why things are not working.

When you say that the Application works when you send it a CTRL+'B' (caps), how are you Sending it?

Most likely the Send that you are doing for testing in some way differs (example: maybe a CrLf (0x0A, 0x0D) is added after the STX, etc.) from the data received from the Scanner.

When you contact your Application's support team give them an example of a full 'should-be-working' character string (All in ASCII) from the Scanner when it is not working.
From that they should be able to see what is missing.

Good Luck,
JRB-Bldr

 

[Papoulos]

I've had a return form my scanner support and there is an option in Gryphon that is "Keyboard send control character".
In default it's Ctrl+KEY, but you can change it by "CTRL+Shift+Key".


So now i can see that the new and the old one are sending the same datas.

But it didn't work any better so you were right, but there is an other problem with the appli. But as the appli have been virtualized perhaps vmware player change things with the data sending to it ?

Now it's the appli support to work.

Thank you.
^^

 

[JRB-Bldr]

But it didn't work any better so you were right,

I am glad that our analysis was correct.

I am not 100% sure of what you mean by the application was 'virtualized'.

If you mean that the application is running on a remote virtual (VM) workstation and you are sending barcode scanner data to it from a physically different workstation, then you have indeed introduced a number of possible issues.

Before going much further I would test how things are working when everything in occurring on a single physical workstation - scanner physically connected to it and application running in it.

If things work in that manner, then yes working remotely via VMWare might be the problem.

Good Luck,
JRB-Bldr

 

[Papoulos]

Yes that's what i mean (what are the good words for it then ?

In fact the issue about testing it is that it's NT4 and that the USB scanner isn't working.
So i try to use a Wedge configuration and it seems to work but it's not production tests, that will take me more times to do.
Let's see it in the week.

 

[JRB-Bldr]

NT4 was released on 29 July 1996

Perhaps it is time to consider upgrading to something more current - even XP Pro (although definitely not current, certainly more functional)

When considering the cost of workstation upgrades from NT4 to something more current, keep in mind that if this barcode scanner functionality is BUSINESS CRITICAL, then the cost should be no object - it is ESSENTIAL to Operate Properly!

Good Luck,
JRB-Bldr

 

[Papoulos]

The entire production system is in NT4 system and changing it with up to date IT is not in the bugdet, so we choose to take it to vmware so that we could get some more years before changing.

So there is no option for us to change from NT4.

 

[JRB-Bldr]

OK, I understand.

In that case you might want to do a Google Search for: nt4 usb

There appear to be a few 'tools' that might allow you to get USB support for your NT4 workstations (hopefully they are still available).

If you could get one of those working, then you might not have to use VMWare.

Good Luck,
JRB-Bldr

 

[Papoulos]

I finaly had a respons from our soft support.

It seems that the program is waiting from SHIFT then CTRL and B.
They gave me the corresponding key codes :
16 : Shift
17 : Ctrl
66 : B


The strange thing is that with USB Keyboard the scanner give me "CTRL+SHIFT+B" and when i configure it in Wedge it gives me "SHIFT+CTRL+B".

 

[DansDadUK]

Those values are virtual key (vk) codes, which are not the same as character codes.

For example, on most Western keyboards:

vk code 66 (0x42) will generate character code 98 (0x62), which is the character 'b'.

vk codes 16 + 66 (0x10 + 0x42) will generate character code 66 (0x42), which is the character 'B'.

 

[JRB-Bldr]

Remember that SHIFT is not, by itself, a stand-alone Character and will not generate its own ASCII value. Neither is CRTL.

These 'control characters' act upon a 'real' Character by causing the Keyboard to send a Different ASCII value when you hit the 'B' key.

Consequently you cannot separately generate a SHIFT or CTRL barcode.

Instead the barcode you generate when you COMBINE (not sequential) SHIFT and/or CTRL with another key is some variation of the 'real' key's barcode representation which in turn will cause a specific ASCII value to be returned to the recipient device.

And, as you have proven already, the ASCII values sent by the following are the same
* SHIFT then CTRL and b (Lower case 'b' - resulting in Upper case 'B')
* CTRL then SHIFT and b (Lower case 'b' - resulting in Upper case 'B')
CTRL + "B" is the same as CTRL + 'b'

Only the following are different.
* CTRL and B (Upper case 'B')
* CTRL and b (Lower case 'b')

Also there is no such thing as a SHIFT then CRTL or vise versa.
They must be used CONCURRENTLY (at the same time) with a 'real' key to produce the intended results.

When the software vendor is telling you:
It seems that the program is waiting from SHIFT then CTRL and B.
that sounds to me like either they are 'blowing smoke' or someone doesn't know what they are talking about.

Software responds to the ASCII Input from a device.
I've developed software for over 35 years and I KNOW this.

If, as you have already proven, the ASCII values are all the same, then something else is going on that either:
* has not been properly explained by the software vendor
* and/or is being introduced by the VMWare path you are using.

Finally...
The strange thing is that with USB Keyboard the scanner give me "CTRL+SHIFT+B" and when i configure it in Wedge it gives me "SHIFT+CTRL+B".
As Seen/Displayed By What or Where?

Since from an ASCII perspective they are EXACTLY THE SAME (1 single ASCII character), who cares?
It is just how the recipient device is notifying you (displaying to you) about what it received.

I could write code to "interpret" an ASCII 0x02 and display it as "SHIFT+CTRL+b" or "CTRL+SHIFT+b" or "CTRL+B" or "CTRL+b" - they all represent only the one same single ASCII 'Character'
How my 'interpretation' code writes out the display to a user is at the developer's discretion.
And displaying the ASCII character as what appears to be 3 separate things (SHIFT, CRTL, 'B') is only for Human reading only, a software application won't care.

Good Luck,
JRB-Bldr

 

[Papoulos]

I think that the software didn"t wait for STX as they told me first.

I think that when they develop the application they didn't use the code for STX but they coded the sequence Shift+Ctrl+B that the scanner sended them.
In fact the application is waiting for a key press sequence.
I've try it manually and it worked.
I've tried with the different keyboard combinations and only the shift+ctrl+b worked.

 

[JRB-Bldr]

they coded the sequence Shift+Ctrl+B

I won't say that they DIDN'T do that, but I don't know how they could have done it that way.

Applications don't look for a human readable sequence like that.
They look for the ASCII characters received and respond to them accordingly.

And since the SHIFT & CTRL aren't really Characters at all, but instead merely operators on 'Real' Characters, they can't separately come into an application in ANY sequence.

Now that I think about it, I guess that, in a very Round-Abound manner, I could develop code to receive the 'raw' ASCII character string and THEN change them into a human readable 'character' string and THEN pass that into the application for use, but why would I develop code in such a Rube-Goldberg manner. It would make NO SENSE.

Oh well, you either have to work with what you have or get it changed to doing it RIGHT.

If they were indeed doing as you say, they could always change their code make it respond equally to:
* Shift+Ctrl+b (lowercase 'b')
* and Ctrl+Shift+b (lowercase 'b')
* and Ctrl+B (uppercase 'B')
* and Ctrl+b (lowercase 'B')
since they all generate the same STX which is the ASCII 0x02

Regardless, as you have proven, the problem is with the Software and not the barcode scanners which appear to be doing their job just fine.

Good Luck,
JRB-Bldr

 

[JRB-Bldr]

The thing that is driving me NUTS about all of this is that there is NO SUCH THING (from an application's perspective) as ANY of the following:
* Shift+Ctrl+b (lowercase 'b')
* and Ctrl+Shift+b (lowercase 'b')
* and Ctrl+B (uppercase 'B')
* and Ctrl+b (lowercase 'B')
They are all 0x02 which is a STX

Just like (again from the application's perspective) there is NO SUCH THING as a SHIFT+t
Instead it is a 0x54 or "T"

Keyboards have a chip in them which recognizes which keys (or combination of keys - CONCURRENTLY) were struck and then sends the associated ASCII to the computer, where an application uses it.

A barcode scanner works the same, but it starts with reading the barcode image and then its decoder sequentially 'interprets' ASCII char-by-char of what it 'saw'.

If I create an application to give visual feedback to a user of what keys they used to generate an ASCII string, I can make it display anything I want regardless of how an application will REALLY see it.

If my application were to receive an 0x02 (or STX) I might assume that the user will not understand that since there is no STX key on the keyboard so I will choose to display it as something else - perhaps:
* Shift+Ctrl+b (lowercase 'b')
* or Ctrl+Shift+b (lowercase 'b')
* or Ctrl+B (uppercase 'B')
* or Ctrl+b (lowercase 'B')
But my application could have just as easily told the user that it was "BLAH" - that type of thing is up to the developer.

BUT, no matter what I displayed to the user to visually see, that is not really what was received - it was a 0x02 (a STX)

If this other application was REALLY expecting only Shift+Ctrl+B, then they are saying that you would need to send:
"S" "h" "i" "f" "t" "+" "C" "t" "r" "l" "+" "B"
That would be absurd.

Either the software people need to own up to a problem on their end or you need to zero in on the problem coming from your use of VMWare.

Good Luck,
JRB-Bldr

 

[DansDadUK]

Some applications are able to detect keyboard scan codes, so that they can take action when certain keys (associated with graphic characters or not) are pressed or released.

See the (relatively old) support page

http://msdn.microsoft.com/en-us/library/aa299374(v=vs.60).aspx

for tables of such scan codes.

As the name suggests, these are keyboard scan codes, although they may obviously be relevant to devices which are emulating a keyboard.

I don't know at what point these scan codes (single, or in combination) are converted to character codes, but it seems that the scan codes for the combination of Ctrl and B keys (regardless of whether or not the Shift key is also pressed) results in the character code 0x02 (the <STX> control-code character).

 

[JRB-Bldr]

Dan - OK, you have educated me on something I was not aware of.

And, I'll add, something that I have never had to deal with in my many years of software development with the exception of those VERY LOW LEVEL (assembly language, on-board computers, etc.) applications where my code had to be the keyboard 'processor' itself.

Regardless I stand by what I said before about
* Shift+Ctrl+b (lowercase 'b')
* or Ctrl+Shift+b (lowercase 'b')
* or Ctrl+B (uppercase 'B')
* or Ctrl+b (lowercase 'B')
All being the same - they ALL result in a single ASCII 0x02 which is a STX

And considering sequential pressing of the SHIFT and/or CRTL keys is nonsense.
They may be pressed one before the other, but unless they are ALL concurrently pressed, the user will NOT be getting what they intend to receive.
* A SHIFT pressed and then released to be followed by the pressing of the 'b' (lower case) will not result in a 'B' (upper case)
* It is only a SHIFT being pressed while the 'b' is pressed that will result in a 'B' (unless CAPS LOCK is in effect).

So even if the keyboard itself can notify the PC what was pressed in what sequence, it is of no importance to how an application needs to operate - at least an application like is needed here.

Papoulos - Good Luck,
JRB-Bldr

 

[DansDadUK]

@JRB-Bldr

I can hardly claim to have educated you, as it's a subject that I'm not very familiar with either - it's just that I had a vague memory of KEYBOARD scan codes, so did a quick look-up of the topic.

... and I agree with all your comments - the end result of various keyboard manipulations is a character, and the one we're interested in is the (non-graphic) control code <STX> character (0x02).

Chris (I'm actually Dan's dad).

 

[Papoulos]

I'v found in the Datalogic manual that there are ascii codes for "shift" or "ctrl" keys.

Shift is 81 for press et 82 for release
Ctrl is 9D for press et 9E for release.

So now i've configured the scanner with these codes to see if it do it as i want...
Let's pray...

 

[JRB-Bldr]

Good luck since there are NO separate ASCII characters for SHIFT or CTRL - not even in the Extended ASCII set. ( See:

http://www.ascii-code.com/

)

If Datalogic is somehow generating something for those separate 'control' characters they would be doing so in a very Non-Standard manner.

Good Luck,
JRB-Bldr

 

[Papoulos]

I had an answer from the retailer and he told me that it's the scanner that have been set to send the character this way so the only way to change it is to ask for a special command for scanners with my specific configuration.

No luck...

But what is strange is that it works fine under NT4...

Thank you all for your help.

 

[JRB-Bldr]

I had an answer from the retailer

A very few retailers are truly knowledgeable at a technical level about the barcode products that they sell.
If not, then they are just giving you an 'standard' answer without really knowing anything about it.
But if this retailer is one of the exceptions, great.

The other approach is to approach a solution from the Application side.
If you can get the Application developers get things working with more than just a single input data configuration (they too could 'convert' various input data strings into what they want to see), then you could get things working that way.

Good Luck,
JRB-Bldr