Filtering out and sending data to the correct graph depending on data identifier

[Dargar]

Hi!
I'm a student and I'm working with LabView 7 for the first time. I'm looking for tutorials or hints from you on how to solve the following problem:

I have managed to set up serial comm. so I get a string, I can log data to a file and I can show the raw data in a text display.. now.. I'm talking with a naon-satellite and the VI is going to act as a groundstation for it. (This is a student project, and I chose to try to develop the groundstation in LabView, none of the others did, help me impress them with the coolest groundstation controll software! 🙂

The nano satellite will "talk" on RS-232 9600 baud and since I'm programming the PIC MCU I can make up my own protocol.

I'm thinking something like:
Groundstation sends this: ?Temperature1
And the satellite then replies: !Temperature1[Data]EndofData

I will have 10 different probes in the satellite, monitoring currents, voltages and temperatures and I need some help and tips on how to "filter" the incomming string and split it up so that I can route the approrpriate data to the appropriate "frontpanel?" or graph.

So how would you recommend that I do it?
I have looked at and read about all the powerfull string searches and manipulations, maybe I could use a switch of some sort? My problem is I cant really see how I can first single out the data from the (continous) stream comming from the satellite and then pass the data on so I can treat it. (do conversions and prepare it for display.)

I'm not asking anyone to solve it for me, but I would like to get pointers so I can get started on the right track right away, I cant afford to "waste" a week and then discover that I have to use a completely different approach.. I hope to avoid that. 🙂

Also, I'm wondering if it is possible to have several graphs "underneath" each other in the front panel, so that when the user presses say, F1 through F10 it "brings to the front" different graphs. That way I can have 10 graphs but only show one at a time (but I can scroll them back in time to look at the history of it). That way I could have one big graph area on my screen and cycle which one is active. Hard to explain... I don't want to have just 1 graph window, because then I cant go back in time, so I actually need one graph for each data-set, I just want to controll which one is visible at all times.

I don't know what to search for in help to find out about this, so please help me get started with this too. (For example by giving help search strings to use or which VI's to look closer on and why I should look at that particular VI.)

Also, I'm not sure how to make arrays of the incomming data? Maybe that is a vaste of time anyway, but if your advice is about making arrays of the incoming string, then how? I cant find the orange array anywhere, I can just find the pink (for strings) and blue (for numbers)?

Thanks!
PS: not sure if this is a LabView General or a LabView datalogging, maybe a little of both?

[Greg_McKaskle2]

> Also, I'm wondering if it is possible to have several graphs
> "underneath" each other in the front panel, so that when the user
> presses say, F1 through F10 it "brings to the front" different graphs.
> That way I can have 10 graphs but only show one at a time (but I can
> scroll them back in time to look at the history of it). That way I
> could have one big graph area on my screen and cycle which one is
> active. Hard to explain... I don't want to have just 1 graph window,
> because then I cant go back in time, so I actually need one graph for
> each data-set, I just want to controll which one is visible at all
> times.
>

You have a couple options. You may want to have a shift register where
you keep your own data in a history buffer, then inde
x one plot out and
wire to a graph. Or you could have ten charts. You can either show and
hide them using a property node, or you can place them in a tab control,
color it transparent, hide the tabs, and write to the tab control terminal.

Greg McKaskle

[Dargar]

Thanks for a fast reply with relevant information! 🙂

I think using a history buffer and have one graph will be to slow. The satellite will be active for 6 - 8 hours, and towards the end of that time, I think (I don't know) that the time it would take to read in the buffer and then display the data would be significant, taking away resources needed to keep logging the new, incomming information. So, I will try and play with the property node and see if I can get anywhere.


Now, the first part of my question still remains valid for anyone who has a few minutes to answer it, about how to "multiplex" the incomming command and data to the correct "branch".

Yet again, thanks to Greg McKaskie for his quick reply.

[Brian_Powell]

Regarding your string parsing...

Maybe I don't understand your protocol, but it looks to me like it's just a simple query/response protocol. So I'm not sure what you mean when you talk about a continuous stream of data.

It seems like you'd just send "?Temperature1\n" and immediately do a VISA Read knowing that the data you expect back is for "Temperature1".

I'd suggest that you terminate your data with an end of line character, and use VISA's termination character functionality to simplify the read. E.g., have the satellite return something like "!Temperature1[Data]\n". Then configure "\n" as your VISA termination character. You could leave out the "Temperature1", since you should know what you queried for. But, it does make a good sanity check
if you identify the data that comes back with the appropriate channel name.

Is the data encoded in ASCII? If so, then the "Scan from String" and "Spreadsheet String to Array" functions will be useful. If it's in binary format, you'll probably end up using the Type Cast function.

I'd suggest downloading some of the native LabVIEW instrument drivers on http://ni.com/idnet/. E.g., download something for an oscilloscope that includes a serial interface. This should provide you with several examples of how to read data with VISA and parse it. This should also show you many examples of how to get real-valued data (orange) instead of pink or blue.

I hope this helps.

Brian

[Hap Frerker]

Dear All,

I have updated from LV6 to LV7. With this update the VI "volume
information" cause an error if the volume which is ask for is an external
card reader and the memory card is not inserted. I received the message:
"Please Insert a Card in drive". This is what I do not need, because I would
like to have this information without a user input (!)

Any Ideas,
Hap@OHB-System.de

[Dargar]

Hi Brian and thanks for your feedback.

A few comments:

I'm "tagging" the data, because I want to be able to sample and send in a loop from the satellite side, without querying for the data. But I also want to be able to query specifically for data manually. I don't know what I will end up doing in the final application though, so right now I'll go with ASCII (easyer to check for errors and read for humans) and the identifiers, I might remove them later.

Also, I'm not sure if using just a /n character (8 bit ASCII code) is good enough, because the data comming is from an ADC circuit (or actually 10) and they can have any value from 0 to 1024 and the data might accidentally contain a sequence that in ASCI corresponds to the /n character. Thats why I wi
ll use at least 2 characters for the end of data sign. 🙂

[Brian_Powell]

So it sounds like you want to send back a sequence of two-byte binary data samples. Thus, you'll use the Type Cast function.

(When I talked about ASCII, I meant that encoded the value "142" as three ASCII characters, '1', '4' and '2'. It sounds like you are not going to encode your data this way.)

Back to the continuous vs. query mode... It's kind of weird to be combining both of those. Usually devices either constantly spew data, or they are queryable. Maybe they can do either, but they are typically put into one mode or the other as part of their configuration.

But let's run with this. Here's what I'm envisioning, and you can tell me if I'm right.

When no queries are going on, the satellite is constantly spewing out...

!Te
mp1[data]End
!Temp2[data]End
!Temp3[data]End
and starting over...
!Temp1[data]End
etc.

If the satellite receives a query, it reports the results back at the next opportunity. Something like this...

!Temp1[data]End
!Temp2[da
Computer queries for ?Temp1 while receiving !Temp2
ta]End
!Temp1[data]End
!Temp3[data]End
etc.

If that's the case, then I think you'll want two parallel loops. One is responsible for waiting for a reason to query for a specific data value. It doesn't do anything until that data is needed.

The other loop is constantly reading, and has no idea whether data was queried, or just received as part of the normal spewage. It is responsible for taking whatever is read, parsing it and updating some data structure (e.g., a set of globals) that contain the latest data values.

The rest of your program that needs to display or log or analyze the data just looks at the globals.

Is any of this making sense? Am I off track?

Brian

PS: I thin
k any posting that contains the noun "spewage" is worthy of a 4-star rating, don't you? 😉

[Greg_McKaskle2]

> I think using a history buffer and have one graph will be to slow. The
> satellite will be active for 6 - 8 hours, and towards the end of that
> time, I think (I don't know) that the time it would take to read in
> the buffer and then display the data would be significant, taking away
> resources needed to keep logging the new, incomming information. So, I
> will try and play with the property node and see if I can get
> anywhere.
>

You don't mention how much data you will have at that point. It you are
going to display it all, someone has to keep it, and the graph and shift
register isn't quite as well suited to incremental updates as a chart
(that is why the chart was written), but when you change properties on a
chart, you often
cause it to remap and redraw all of the data. Plus, you
don't have direct access to the data in the chart. If you truly have
lots of data, you may want to decimate it for the display.

If you have numbers, I can give you some expected results.

Greg McKaskle

[Dargar]

I don't have any 100% accurate values at this time since we have not desgined the sample system yet. However, going with what I have to estimate one:
Assuming data is transferred in binary format (header and footer in ASCII)
10 data sources, each is app. 10-13 bit long, round up for worst case = 130 data bits.
Assume 2 samples/second = 260bits/second.
Header + footer = assume 8 characters total = 64 bits/source = 640bits/second .. and sampling at 2 samples/second increases this to 1280bit/second

So incomming data will be 260+1280bits/second.

One chart or graph (depending on which I should use) of the 10 will therefore receive 2 * 13bits of data/second
Multiply up for 6 hours = 26*60*60*6 = 496'000 bits in 43200 samples or char p
oints.
I don't know which to use, chart or graph, and I don't know what you mean by "decimate it for the display".

Additional information:
I need to calculate (and graph?) the capacity of a battery-pack. I have the voltage and current that goes in or out of the battery (sampled 2/sec). If I multiply every volt-sample with every current sample and plot/graph them and calculate the integral of that curve, I can use that to see the remaining capacity of the battery. Can I apply the "time domain Math" to a "chart" vi?

Thanks for all your patience in helping me get started. I'm really impressed by the power in LabView and I'm constantly surprising myself when I experiment with it, but some of the things isn't obvious until after you have solved a problem.. 🙂

[Dargar]

I'm sorry Brian, but the "rate this answer" doesn't show on your latest reply?????

As for the query thing, you're right, it doesn't make sense to be able to do both I guess. So either I'll have the computer request each data by sending "?Temp1" requests and listen for the replies, or else I will have the satellite just "spew" out data in a predetermined pattern, using "!Temp1" so I know were the data belongs.

I've read some on the parsing VI's but I'm having problems seeing how I can use them to further my needs.

The data itself will not be ASCII, it will most likely be binary. Simply because some of the data is 13 or even 16 bits wide, it will take considerable more "bandwidht" to transmit the ASCI equivalent to the data than just
transmitting it binary. As I said, I feel very unsure about how to handle this using parsing?
Example: temperature-probe 1 returns 10 databits, looking at the received string it might look like this:
[T][e][m][p][1][8 msb of data][2lsb of data + 6 padding bits]
Each bracket signifying 8 bits in the incomming stream.

How can I search for and find "Temp1" and then when I do, extract the 8msb and 2lsb and then build them into the 10bit data that I need?