Parsing A Data String

[rharmon@sandia.gov]

I have a question on how you guys deal with parsing a data string.

The data string looks like this ~00D0370;0;0;0;;1;0;0;1;0;;0;0;0;0;1;0;0;0;1 I understand the ~00D is telling me the string contains data and the 037 tells me the length of the data string.

I could easily use String Subset to select the variables I want, or Match Pattern to drop the semicolons in the string. I'm sure there are hundreds of methods to accomplish this. If you have a better method I'm all ears.

One thing is worrying me... where they have the double semicolons... Could I ever expect a value to end up between the double semicolons? Because that would totally mess up my parsing.

How would you deal with the double semicolons?

Thanks,

Bob

[LogMAN]

I would do it in two steps

1. Discard protocol data (~00D and 037) - This is typically done when reading the data string anyway.

2. Split the payload using Delimited String to 1D String Array.vi.

[rharmon@sandia.gov]

LogMAN

Interesting... I like it, then my data is in an array that I can index for the values I need

Any concern about the double semicolons?

Bob

[Neil Pate]

3 hours ago, LogMAN said:

2. Split the payload using Delimited String to 1D String Array.vi.

Holy guacamole! When did this make it into vanilla LabVIEW? I have been using the OpenG one for so long now...  it is present in 2019 and not in 2015..

I noticed its opposite number is also now in, nice 🙂

[Neil Pate]

1 hour ago, rharmon@sandia.gov said:

Any concern about the double semicolons?

The double semicolons will result in empty array elements in those locations.

Edited June 4, 2020 by Neil Pate

[rharmon@sandia.gov]

50 minutes ago, Neil Pate said:

The double semicolons will result in empty array elements in those locations.

Perfect... Don't have to worry about some data there messing up my parsing... You guys are amazing....

[JKSH]

2 hours ago, Neil Pate said:

Holy guacamole! When did this make it into vanilla LabVIEW? I have been using the OpenG one for so long now...  it is present in 2019 and not in 2015..

I noticed its opposite number is also now in, nice 🙂

Even before this became available, the Hidden Gems palette would expose Split String.vi and Join Strings.vi which come bundled with LabVIEW (vi.lib\AdvancedString\) but which are not shown in the palette out-of-the-box.

I'm not sure why NI created new VIs instead of exposing the Hidden Gems ones. I liked the Hidden versions better as they take less space on the block diagram.

Note also that the out-of-the-box version has fewer features:

• The Hidden Gems version allows you to Ignore Case
• The OpenG version allows you to Ignore Case AND Ignore Duplicate Delimiters

[LogMAN]

10 hours ago, Neil Pate said:

Holy guacamole! When did this make it into vanilla LabVIEW? I have been using the OpenG one for so long now...  it is present in 2019 and not in 2015..

I noticed its opposite number is also now in, nice 🙂

They were added in 2019, actually. Can't live without them now 😊

7 hours ago, JKSH said:

I'm not sure why NI created new VIs instead of exposing the Hidden Gems ones.

7 hours ago, JKSH said:

Note also that the out-of-the-box version has fewer features:

• The Hidden Gems version allows you to Ignore Case
• The OpenG version allows you to Ignore Case AND Ignore Duplicate Delimiters

Indeed, these features are very useful for corner cases. For the general case, however, I would argue that the cost (slower performance, higher complexity) probably outweighs the benefits (haven't tested it). Still, the Hidden Gems version allows you to specify a pattern, which makes it extremely flexible (not sure about the OpenG version).

[JKSH]

3 hours ago, LogMAN said:

 

 

Good find. I completely forgot that I posted that! 😅

[rharmon@sandia.gov]

All,

Once again I want to thank everyone who chimed in to help me figure out this communications issue. I have attached a small project file that communicated with the Tripp-Lite SmartOnline UPS. If Tripp-Lite tells you to use communications protocol 4001then this software should work.

To say again, Tripp-Lite was not helpful. The protocol document they sent me in no way works. Not even close.

What was helpful.

1. Input from you guys who chimed in here. Huge help... Thanks.

2. https://github.com/networkupstools/nut/blob/master/drivers/tripplitesu.c   although I don't do C, reading the information here was very helpful

3. The Tripp-Lite Programmable MODBUS Card Owner's Manual. A colleague at work found this document and although it doesn't translate perfectly it was helpful.

4. My bullheadedness and refusal to give up when I knew it should be able to be done.

So obviously without input from Tripp-Lite I can give no guarantees on the accuracy of this code. I feel it's right. If anyone wants to try it and let me know how accurate you think it is... That would be helpful. Even better yet if you find errors please let me know.

Thanks again,

Bob Harmon

Tripp-Lite Project.zip