Escaping char in string passed to labview

[David_Stevenson]

I am having problems passing escaped chars in a string to labview.

I have tried \14\02\55, and \x14\x02\x55 and both ascii string and binary string but I always get "Invalid Escape sequence in Expression"

The only solution I have found is using:

Chr(13)+Chr(3)+Chr(0x91)+Chr(0x55)+Chr(14)+Chr(3)+Chr(0x62)+Chr(0xAA)

But this ends up difficult to read,

Should the escape work?

What am I doing wrong?

David

[dug9000]

You are probably not considering the fact that the \ character is itself an escape character in an expression's string literal. So if you want the string \x14\x02\x55, you have to use the string literal:

"\\x14\\x02\\x55"

Or in TestStand 2012 and higher you can do:

@"\x14\x02\x55"

The @ symbol indicates to TestStand to not treat backslashes as escape characters.

-Doug

[David_Stevenson]

No. What I am trying to send is the 3 bytes value 14, value 2 and value 55. (in hex)

Or as in the example that works 8 bytes, the data values varies in each step.

[dug9000]

I think if you have the parameter in the TestStand LabVIEW adapter marked as a binary string, then it will unescape the string (the verison with the backslashes) before passing it to labview.

-Doug

[crossrulz]

---

@David_Stevenson wrote:

I have tried \14\02\55, and \x14\x02\x55 and both ascii string and binary string but I always get "Invalid Escape sequence in Expression"

---

I seem to be having a similar issue with TestStand 2016 SP1 with LabVIEW 2016.  I am trying to use a Binary String with value of "\03" (End Of String character).  I am getting the error from the analyzer.  But if I ignore that error and continue anyways, the value is passed correctly into LabVIEW.  So it appears to just be an issue with the sequence analyzer.

See the simple example attached for any other details.

[Dane.S]

Thank you for discovering this and posting your simple example.

Based on this it does look like the Analyzer is incorrectly throwing that error so we have filed a report( #732825) on this.

[Scott_Richardson]

Just wanted you to know that your issue, 732825, is a duplicate of another recently report that is tracked using issue 718241. I have close 732825 and added this forum posting to 718241.

[Dane.S]

As a workaround for this issue you can use Chr(0x30) as a substitute using "&" to concatenate longer strings as touched on in the initial post. You can also configure the sequence analyzer rule to be ignored.