Match specific string (Hex 2E2E)

[James_W]

I have a file I need to process, a nice simple function to create.

Read in file, find part of file with certain data string in it, create data array output in expanded format and save to spreadsheet file (e.g. csv will do)

Here is the problem, the data is in the format:

 #PS0,#PS1,#PS3,#c3..31,#c34..126

(I can remove the # and , no probs. The bit that's killing me is that I need to expand the array from c3 to c31. A match pattern will never find ".." beacuse "." is a special character in both match pattern and match regular expression -  Thanks NI.)

I can sort of locate it using the split string function, but this wont do what I want very efficiently, so has anyone got any ideas for a more efficient way around this problem?

Cheers

James

[GerdW · Accepted solution]

Hi James,

try this:

[James_W]

Genius!!!

I learn something new everyday.

Danke

James

...now if I could just work out how to open snippets in LV2009...

[James@Home]

James,

I see you have a solution already, but here's a VI I already made.

Just in case you're not already way past this point.

Also attached is one subVI from my user.lib it calls.

Yes, I was a little bored this AM.

James

[James_W]

Thanks for the feedback James,

Nice method  

I have attached a snippet of my implementation to show you how I went about it.

 

Personally I prefer to avoid the string functions which can generate errors when I can as they can occasionally cause unexpected behaviour, so you will see a bit more overhead in this approach I have done, but this is not a problem.

2 points I notice: -

1) you have a massive overhead compared to my VI (if you were going for efficiency) with the way you implemented the case structure,

2) in case you have missed it, there is a single finction on the comparisson pallete that does the "Empty string" comparisson - might make your subVI more compact if you ever wanted it.

Cheers

James

[James@Home]

James,

That's a nice solution.

From your code, I see you've already eliminated and don't need the # characters.

Also, I see that prefixes with numeric ranges are limited to a single prefix character.

I thought, from the example, prefixes might contain variable length alpha characters (i.e. #PS1).

1) Is it "Scan From String" that adds massive overhead?  Or is it something else?

 

2) *giggle* Yes, that subVI looks bad...  I hadn't opened that diagram in many years (created in '01).  I've created 100s of user.lib VIs over the last 10 years ago and haven't reviewed them.  My user.lib looks similar to the OpenG library, but different functions and none green.  Some of those that I created as a LV beginner obviously need some review & cleanup!!

Thanks for sharing your solution and the feedback on mine.

James

[James_W]

Hi James, 

It's the case structure's and it's undefined cases...

I have only 2 possible cases T & F

you have -1 and 1,(default) - the numeric in the case structure will never be handled as fast as a boolean input as it has to determin which case to go to if the numeris is not one of the defined cases, you also have a potential I32 cases instead of 2 to search through.

James

Edit : yup i forgot/didn't bother to mention that I didn't need to handle the alpha chars PSn and every other one will be Xnn

Message Edited by James W on 05-05-2010 01:58 PM

[James@Home]

James,

Thanks for the feedback.

I did not realize this would be a big performance hit; just hadn't given it a lot of thought. 

At first, it seems as there are only two choices with my logic as well (-1 or default).

But, that must not be the way LabVIEW handles it? 

In the future I'll remember to drop in the >0 so my cases are just T/F.

Thanks again,

James