Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

viRead failed using a Unicode Operating System

Hello!

I am using my own Class Library for Visual Basic 6.0 and NI VISA 3.2 to control my measurement systems and providing function like read binary arrays, ....
I want to read IEEE 32-bit floating values from a Spectrum Analyzer which come as binary data (#3123...).

- Using the functions with Windows XP German version: this is no problem.
- Using the same function with Windows XP Multilanguage and Korean extension, the function fails (wrong values).

As far as I can see from the HEX editor, each 2. character is 0x00, but this only happens on the korean system.
So binary casting must detect the current unicode state and would not be very useful.

Unfortunatly, I can only pass a string array to ViRead (and not e.g. X() as Byte).
I could try to pass StrPtr() with a Byte field, but I am not sure if this will work.

Is there any workaround / solution for my problem?

Best regards,

Martin Weiss.
0 Kudos
Message 1 of 2
(3,046 Views)
Martin,

@you wrote:

I am using my own Class Library for Visual Basic 6.0 and NI VISA 3.2 to control my measurement systems and providing function like read binary arrays, ....
I want to read IEEE 32-bit floating values from a Spectrum Analyzer which come as binary data (#3123...).

- Using the functions with Windows XP German version: this is no problem.
- Using the same function with Windows XP Multilanguage and Korean extension, the function fails (wrong values).

As far as I can see from the HEX editor, each 2. character is 0x00, but this only happens on the korean system.
So binary casting must detect the current unicode state and would not be very useful.

Unfortunatly, I can only pass a string array to ViRead (and not e.g. X() as Byte).
I could try to pass StrPtr() with a Byte field, but I am not sure if this will work.

Is there any workaround / solution for my problem?


AFAIK Unicode uses 16 bits per 'character', so the behaviour you described does not surprise me.
What you can do is checking the 'number of bytes (characters)' at serial port and check if there's a value of 0x00 at _every_ 2nd byte. If so, it is probably unicode and I'd try to remove those 0x00 on each 2nd position. You might also perform some plausibility checks (size, shape, mean, whatever) for the remainder.
HTH and
Greetings from Germany!
--
Uwe
0 Kudos
Message 2 of 2
(3,041 Views)