escape character code optimization

[jerry12345]

I have an interesting code optimization problem.  I am reading ascii data off of an instrument.  The strings can be very long and I need to convert the escape characters into actual data.  I was using the "search and replace all” string function at first, but occasionally I'd get incorrect data returned.  I finally tracked the problem to a case where “search and replace all” doesn't work.  The escape character is "\", so if "\" is in the original data it gets replaced with "\\" in the escaped string.   If the original data is hex 0x00, the escaped string is "\0".  So here’s the problem, if the original data was asii "\0" the escaped string would be “\\0”.   When you decode this escaped string with the “search and replace all” function,  "\0" will always be replaced with hex 0x00 instead just being left as “0”.  To properly decode the escaped string you have to process each instance of the escaped characters in sequence.   So with “\\0” you process “\\” to “\” and then “0” is left as is to get the desired “\0”.  Make sense???  My problem is that my original code that used “search and replace all” took about 2ms to execute.  The best I can do decoding the string properly takes about 220ms.  I’ve tried converting the string into a byte array and processing it as numbers instead of strings(~330ms).  I’ve made several attempts using “In place element structures”, which took a minute to process the string.  Is there anyone out there who knows how to speed up LabVIEW string processing?  Or is this something I have to write in C?  Attached are several of my attempts.

[johnsold]

String processing can be slow. But there are usually ways to work around it.

I do not completely understand your question because it seems the wording of thettext in your post does not match the behavior of the VIs you posted.

Your VIs search for "\0" (normal display) and replace with hex0x00, but you say you want something else?

Are there any characters (or short sequences of characters) which can never occur in the data strings from the instrument?  I notice that characters with decimal values 0, 9, 13, and 27 do not appear in the original string in your test VI.

Lynn

[jerry12345]

Hi Lynn,

Thanks for taking a look!  My company is currently shut down and I'm on furlough, so I can't connect to our license server to open up any LabVIEW code.  I'll try to explain things a little bit better.  So, there is a list of characters that have to be escaped.  I believe this is mainly to make the string more readable in a terminal program, so things like tabs and new line characters are escaped.  I can't recall the entire list but it's in the code I attached.  So let me explain my previous example a little better.  To illustrate a simple case where "search and replace all" doesn't work, suppose the instrument has data in memory "\0".  Note this is not an escaped encoded string, this is the actual data stored in memory.  To send this data from the instrument, it is escape encoded as "\\0".  The issue then becomes, how do you decode this escaped string on the client side to retrieve the actual data?  The attached VI's are attempts to write this client side code.  To properly decode the string you have to search for the first instance to the escape character "\", then do a replacement based on the character immediately following that escape character.  (note again that there is a list of 6 or so characters that are escaped)  But in our example, the "\\" in "\\0" becomes just "\" and the "0" remains unmodified so we get the original data string "\0".  Doing a "search and replace all" of "\0" with 0x00 and "\\" with "\" will incorrectly decode the string.  Does that make any more sense?

[Yamaeda]

You have to decode stuff in the right order. Since '\' is a special character it's escaped to '\\'. So basically you need to first search and replace all \\ with \, then look for \0 or whatever. I assume you have a loop going through all replacements, just replace all \\ first.

/Y

[Nathan-M]

To put things more simply and clearly - can you please provide a sample input and output that would like to see your application process?

[camerond]

And could you reattach your VIs in LV 2012? Many of us have not upgraded to 2013 and cannot open them.

Cameron

[Nathan-M]

Here's the 2012 version

[camerond]

Are these VIs the ones you have been using for testing, where you get the string data off the instrument and type it into the VI by hand?

If so, there's your problem. You have got both your control and your indicator set to display "Normal" strings. Here, you won't see any nonprintable characters (or they'll come up as boxes or whatever), but more importantly, you cannot enter any nonprintable ("escaped") characters. If you type in "\0" you will get "\0" out in the "Normal" display, but if you change the indicator display to "\ codes" you will get "\\0" because it treats the backslash as a printable backslash (5C hex). If you type "\0" into the control where "\ codes display" is chosen, you will get "\0" (00 hex, or null) out if your indicator is set to display hex or escape code characters.

And, if you are using "Search and Replace String" function, you also have to set the "search string" input and "replace string" output the same way, or it's going to do the exact same thing. If you search for "\0" and the string is set to "\ code display" on your input but "\0" set to "normal display" on your output, you'll get the literal string "\0" out (5330 hex) for a null (0000 hex) input.

With strings, if you don't get out what you think you should, the problem (at least when it happens to me) 99.9% of teh time is that you didn't correctly format a string input/output somewhere.

Cameron

[jerry12345]

Thank you all for the response!

Yamaeda:  I have code that will properly decode the string, I just need to to run faster.  The attachment on my first message has the code.  One subVI is a "search and replace all" version that doesn't properly decode the string in all cases, but it only takes 2ms to run.  The attachment also has 3 other subVI's that decode the string properly but in different ways.  The problem is that the best of these methods takes 100 times longer long to perform the operation.

Nathan-M:  I think everything you are asking for is in the attachment to my first message.  As I mentioned previously, I'm on furlough and my company is almost completely shut down, so I don't have access to the licence server to open up LabVIEW and give you anything more at the moment.  Thanks for uploading the code in LV2012!  

camerond:  Thanks for the input.  The attached subVI's are the VI's I'm using to test, but they are just a part of a much larger code base to communicate and decoded data from the instrument.  This isn't just a display problem.  Again 3 out of the 4 subVI's that I attached, correctly decode the string.  They're just VERY slow compared to the "search and replace all" version.  My question is about making the code run faster.  I'd be happy with 10x loss in performance where as now I'm at 100x or more. 

[camerond]

I'm still trying to decode your explanation. Might you answer these short questions?

"\0" coming directly from your instrument data (not processed for human visible data on a monitor) should be interpreted as ____ ? Please give answer either as an escape code or hex number.

"\\0" same question.

"\\\0".

"0".

"\t" same question.

"\\t".

"\\\t".

"t".

Maybe this will help me help you.

Cameron