This widget could not be displayed.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can't correctly read a string value in '\' code from a configuration file in LabVIEW 2009

Solved!
Go to solution

Hi,

 

I use configuration file VIs in order to read different value from a *.ini file.

I use it to store string data that I send through a serial port. I have normal formatted ASCII string (ex: “START”) but also ‘\’ code formatted ASCII string (ex: “\3A\01\02\03\FF\AF”).

It works in LabVIEW 8.6, the ASCII numeric read values are the same and they are correct on my front panel when I display them in ‘\’ code.

In LabVIEW 2009, when I read a string value which is written in '\' code the character '\' is doubled for the value over \1A (ex: “\\3A\01\02\03\\FF\\AF”).

 

Is it a bug or a limit of LabVIEW 2009?

 

Jeremy
0 Kudos
Message 1 of 7
(3,872 Views)

Can you include your code? Does it work in 8.6 with exactly the same code?

 

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 2 of 7
(3,859 Views)
Here, 2 identical VI (one in LV 8.6 and the other in LV2009) reading the same value from the same ini file but with different read values on their front panel.
Download All
0 Kudos
Message 3 of 7
(3,849 Views)
What are you expecting to see here? If I turn the constant to True on the read raw string then I get "\3A\BF\01\FF\05" for the normal display using 2009. Is that what you are looking for?
Tim
GHSP
0 Kudos
Message 4 of 7
(3,842 Views)

In my examples I try to retrieve my initial string which contains only 5 characters ("\3A\BF\01\FF\05").

In LV 8.6, this string in normal display shows nothing very useful because the characters don't correspond to full displayable character.

The '\' code display contains the following string : ":\BF\01\FF\05" because 0x3A is the hex value of ":".
0 Kudos
Message 5 of 7
(3,814 Views)

I think the point the OP was raising is that the result is DIFFERENT in 8.x and in 9.0

 

The string in question comprises 5 instances of a \xx escape sequence, aach representing a single character.

 

I tried reproducing this:

In 8.2 the result string from read key is 5 characters long, and consists of the equivalents of the 5 escape sequences in the .ini file.

In 9.0 some of the \xx sequences are NOT converted, so the resulting string is 11 characters long.

 

I've looked into the parser vi that converts the string which may contain escape sequences into the result string,

<LV dir>\vi.lib\Utility\config.llb\Unescape String.vi

 

It would apear that 9.0 is stricter at what it allows in the escape sequences. In 9.0, an escaped character of the form \xy is only recognised in 9.0 if x is 0 or 1, and y is a hex digit (A-F must be in Upper case) -- Open the vi, [you can drill through the confin file VI's as they're not passworded] and you'll see the the VI looks for a match pattern of "^\\[01][0-9ABCDEF]" to see if it's an escape sequence.

 

In 8.x, the routine was rather different, and both x and y were any character acceptable to "hex string to number"

  

 

In both revisions the routine to convert INTO the \xx escaped form would only convert characters whose value is 31 (decimal) or less, and always use upper case for A-F, so would always produce sequences that both 8.x and 9.0 will read.

 

So ..... if you use just NI's routines to convert the string into its escaped form before writing, you're OK, but if you did you own escaping, you'll need to read the string in raw format and do you own unescaping, (or pinch the LV 8.x unrescape routine)

 

Rod.

 

 

 

Message Edited by Rod on 19/10/2009 15:17.. 03:17 PM
Message 6 of 7
(3,802 Views)
Solution
Accepted by topic author JeremyM

Hi,

 

I finally fix my problem by modifying the Unescape String.vi in <LV9 dir>\vi.lib\Utility\config.llb.

I change the match pattern constant string from "^\\[01][0-9ABCDEF]" to "^\\[0-9ABCDEF][0-9ABCDEF]".

 

Thank you for your help

0 Kudos
Message 7 of 7
(3,767 Views)