Buffered XY Graph

[GraemeJ]

The attached vi incrementally plots data on an XY Graph while retaining the earlier plot. As written, data is plotted in one second increments, for a total of 60 seconds. This suited the application in which it is to be used but it would be much better if this could be controlled programmatically. I would welcome help with this or any other comments.

The code generated data option was added as an afterthought and is only there for demo. purposes.

The essential piece of code is an extract from a previous post by Becktho on 04-06-2006 (cannot find the thread). The vi was simulation_graph_1.vi and I would like to give my thanks for that help.

Regards, GraemeJ

[Mark Balla]

QUOTE (GraemeJ @ Jun 24 2008, 08:20 PM)

The attached vi incrementally plots data on an XY Graph while retaining the earlier plot. As written, data is plotted in one second increments, for a total of 60 seconds. This suited the application in which it is to be used but it would be much better if this could be controlled programmatically. I would welcome help with this or any other comments.

The code generated data option was added as an afterthought and is only there for demo. purposes.

The essential piece of code is an extract from a previous post by Becktho on 04-06-2006 (cannot find the thread). The vi was simulation_graph_1.vi and I would like to give my thanks for that help.

Regards, GraemeJ

Could you expand on what you mean by "could be controlled programmatically"

What ultimately would you like this vi to do?

Looking through the vi it looks like you are breaking up the aquired waveform into 2 separate (X Y) 60x10 2D arrays.

You select (Current Index of the While loop???) one of the 60 rows of each array and append it to the current waveform.

Acquire a new waveform and repeat the process.

I would guess that you want to break up a single acquired waveform up into 60 segments of 10 seconds each. and display them on the graph but we need more information to help.

[GraemeJ]

Hello mballa,

Thanks for your interest.

Data is being acquired by a sensor, plotted on a graph to confirm to the user that the data looks OK, eg. the sensor is working correctly etc., and then further information is derived from the data in the balance of the program.

In the first use of the program I know that the data is collected at 10 Hz for 60 secs but this may not always be the case and I would like these parameters to be user controlled (which would include control of DAQmx Read).

There are two reasons for trying to use a buffered plot. The first is operator boredom. Rather than have the user watch a blank display while the data is collected I have tried to have the graph plot change incremetally in one second increments. The second is a fuctional one. The data is used to model the response of the sensor and derive the equilibrium voltage (which can be a very long time – 45 min). While it has already been established that 60 secs of data can produce an answer, the buffered data should allow this to be done dynamically and establish when equlibrium is within a tolerance range before the full reading has completed.

I would appreciate any comments you may have.

Regards, GraemeJ

[Yair]

You do realize that the 60 seconds are simply determined by the constant, right? All you need to do is change the value on that wire to another number.

Incidentally, you should watch your memory allocation. You're repeatedly increasing the size of the array, which might hurt performance considerably over time.

Essentially, it seems that what you're looking for is an XY chart (something where you only add the new values and it remembers the old ones). There is actually a shipping example of this, but it's not very nice, so I created a quick one myself once and you can find it here. Just for the fun of it, here's another version of it which creates a vertical chart.

[GraemeJ]

Hello Yair,

I was tempted to describe your vi's as 'elegant' but I guess that is too formal a word to use in a post.

Functionally, your code will suit my application but the user is expecting to see an XY graph with data plotted incrementally from the origin, rather than a chart. In addition to a plot of a single channel of data I also wish to simultaneously include incremental plots of both a smoothed data curve plus the sensor model response curve. .

I have not been able to work out how you made an XY graph operate like a chart.

Because I am new to LV I do not have an intuitive idea of the memory allocation due to increasing array size. Could you comment further?

A problem I have had with your vi [using LV 8.5] is that it will only run once and has to be closed and restarted for the next run.

Regards, GraemeJ

[Yair]

QUOTE (GraemeJ @ Jun 29 2008, 06:57 AM)

I have not been able to work out how you made an XY graph operate like a chart.

Try looking at the property nodes in the main VI and understanding what they do. Removing them also might help in understanding this. You can also try placing probes on the wires or running in highlight execution to understand why this works. Once you understand that, you might be able to change the code to do what you want, including adding the calculations.

If the calculations rely on some or all of the previous data, you can hold it in a shift register, or just add it as more plots in the main VI, simply by using Build Array.

QUOTE

Because I am new to

LV

I do not have an intuitive idea of the memory allocation due to increasing array size. Could you comment further?

LabVIEW takes care automatically of memory management. That's truly one of its greatest features, but it also means you have less control and in certain cases need to be aware of what's going on. For every piece of data LabVIEW holds in memory, it will need to ask the computer for enough memory to hold it in. When you keep making the array larger inside the loop (by using Build Array) LabVIEW has to repeatedly ask the computer for more and more memory to hold the array in.

This has two basic implications on performance. First, allocating memory takes time, CPU cycles, etc and means that memory will not be available for something else if it is needed. Second, LabVIEW holds flat data (like this array) in consecutive memory locations. If it needs to make more room for the array and it can't find it, it will have to find a new place where it will fit and move it there. If it can't find such a place, it will have to ask the computer to make the room. If it still can't find it, you'll get an out of memory error (although those are relatively rare).

The bottom line of all this is that's it is not advisable to repeatedly resize arrays in a loop. I'm not saying it will crash the computer or hurt performance, just that's it's problematic. Instead, it's better to set the size of the array once and then replace. If you do need to resize, it's usually better to resize in chunks and then do the replacing.

You can find some LabVIEW tutorials http://wiki.lavag.org/LabVIEW_tutorial#External_Links' rel='nofollow' target="_blank">here.

QUOTE

A problem I have had with your vi [using

LV

8.5] is that it will only run once and has to be closed and restarted for the next run.

That's because it was a quickly written example and it simply has a bug. I'll leave it to you to debug this, but I'll hint by pointing at the bottom shift register. If that doesn't help, you can enable debugging on the VI or make it non-reentrant and then use probes to understand what's going on.

[Ton Plomp]

QUOTE (Yair @ Jun 29 2008, 08:19 PM)

If that doesn't help, you can enable debugging on the VI or make it non-reentrant and then use probes to understand what's going on.

No need to make it non-reentrant, LabVIEW 8.5 can debug and probe reentrant VIs.

Ton

PS Jeff Washington thanks for that feature

[Yair]

QUOTE (tcplomp @ Jun 30 2008, 07:13 AM)

No need to make it non-reentrant, LabVIEW 8.5 can debug and probe reentrant VIs.

Which is why I said QUOTE

enable debugging

on the VI

or

make it non-reentrant

[GraemeJ]

QUOTE (Yair @ Jun 30 2008, 04:19 AM)

That's because it was a quickly written example and it simply has a bug. I'll leave it to you to debug this, but I'll hint by pointing at the bottom shift register. If that doesn't help, you can enable debugging on the VI or make it non-reentrant and then use probes to understand what's going on.

Thanks for the tip – bug fixed. However, I have yet to fully understand all the subtleties of your Buffer.vi : part of my continuing education.

GraemeJ