using WDT (Waveform Data Type) in a chart

[Soroush]

Hi,

Here is the old problem again. showing acquired data in a "Waveform Chart". I've done this job several times, each time with a method slightly different from previous times! I have attached a VI that simulates acquired data and I tried to show it in a chart. My main concern was to bundle timing information with the acquired data. Therefore I used WDT instead of familiar "Bundle" node. The problem is that I'm not sure about its performance. Because I'm increasing the size of array of the WDT and also if I replace the chart with a graph, nothing seems to be changed! I'm not satisfied with this code, but I also couldn't find any other way to bundle data with timing information that can be saved to .TDM files.

I looked through NI examples and noticed that WDT is never used with charts! Only graphs seem to use them in NI examples. But if you place a chart on the front panel and use "Context Help" for its terminal in the block diagram, you will notice that WDT is permissible for Charts too. It is confusing! No example, but "Help" files say it is allowed!

There should be a "Best method" for this task. What will you suggest? How much good is my method in the attached VI?

Thanks in advance.

[mikeporter]

Ok,

The thing to keep in mind is that charts and graphs are for displaying fundamentally different kinds of data.

A chart is for displaying data that is being read slowly--think old mechanical strip chart recorders. This kind of data is not really a "waveform", but just a collection of readings because there is no implied timing between one sample and the next. (Which as we will see below pretty well defines your data.) In fact, if you stop an application using a strip chart and then restart it, the data from the 2nd run gets appended to the data that's still there from the 1st run.

By contrast, a graph displays an entire dataset at once. If you read a number of datapoints from a DAQ card, that data is a waveform because (assuming internal clocking) the time between each sample is very precisely set in hardware on the DAQ card.

Now having said all that, there are a lot of things in you code that needed fixing (see attached code). The most fundamental issue is that you are acquiring data point-by-point and trying to synthesize it into a "waveform". This is a problem because the sample timing is being done in LV code and application code is highly susceptable to slow downs due to things the operating system is doing.

As a result, there will be jitter in the data timing. Some samples might be exactly 100msec apart, while others are 110- or 200msec apart--or more. You just don't know. This sort of jitter becomes a major issue if you try to do any sort of analysis that assumes a constant sample rate--like FFTs.

Next there is the use of feedback nodes. If you need shift register functionality, use shift register. And if the wiring makes your code "too messy" that's a real good indication that you need to rethink and redesign what you're doing. As it turns out though, in your application you don't need feedback nodes or shift registers. Along the same general lines of useless features in LV, your code was housed in a big sequence structure--which is now gone. Sequence structures are never required in well-designed code. 

Concerning the right-hand loop, I replaced the timer and case structure with an event structure. Much more efficient and easier to use. The "load" button has also gone away because it seemed to me that it had sorta' run out of things to do. (Of course, this is a subset of your application, so if you need it, just recreate the button and add a frame to the the event structure to implement the functionality you wish it to have.) In additon, this event structure has no timeout case so it will only use CPU cycles when you are telling it to do something.

Mike...

[Soroush]

Hi,

I would know that this problem need more explanations. but now, when you have answerd the first message we may go on.

At first, please forget everthing but the chart and the graph. actually, I've prepared this VI trying to teach labview to some of my friends. I couldn't use event structure or some advanced nodes that you have added to the code. Anyway I really appreciate your work and your time.

so let's focus on the chart and the graph. I'm aware of the fundamental difference between charts & graphs. That's why ,using WDT for stroring data in a chart, surprises me! take a look at context help window on the block diagram terminal of a waveform chart. you will see WDT there. but nowhere in the NI examples.

but the most important problem with your code is that you have lost timing information! Synchronizing the X axis scale of the chart and the graph is a MUST in my application. that's why I tried to use WDT. but you switched back to saving data to the chart by only using the bundle node which will result in losing timing information. I want both X axis's to show absoulte time and they also must show the true time!

I'm really eager to know the answer. Thank you for your time Mike, but I'll be grateful if you continue pariticipating in solving this problem.

It seems strange to me that I can not find the solution at once. because it is a very general issue! All monitoring applications must deal with such a problem. So there must be standard solution, combining acquired data with timing information with acceptable performance and memory management issues.

Thankyou all for your help.

[mikeporter]

Oh, for the plot you want something like this (still don't need shift registers or waveforms...):

Mike...

PS: In terms of showing LV to other people, better to show them the right way to code the first time than to have to break them of bad habits later. Besides, I would argue that event driven programming for a user interface is easier to understand than the alternatives...

[Soroush]

Hi,

This one is not so different form the last one!

The big problem is that I want the timing information to be present in the data of the chart itself. Suppose that you have built a monitoring application. there are lots of charts in this application and all of them are saving data in a finite history length, e.g in 24Hrs periods. after each 24 hours, the data in the chart must be saved in a file and it is archived. The chart must be cleared and everything starts again. Later, we have an archive of files.

Now suppose that one day, you want to investigate in historical data saved in your files. therefore you must be able to plot that data in a graph with the timing information of the day it was saved. your code is not useful for this case. because you have saved the data in the chart by using bundle node and a while loop, but the timing is wired to the graph seperately. this will not work for a monitoring application. my code is working here, but I think it really has performance problems. can you think of an idea to store the timing in the chart itself?

remember that I still have the problem with WDT and charts. using WDT in charts still surprises me!!!

Is there a standard way to build such monitoring applications? will DSC module and using Citadel database help in this problem?

I emphasize that the timing information must be stored in the chart.

We're getting closer to the point of understanding the problem. This is half of the way to the solution!

[mikeporter]

I just downloaded the last code I posted to make sure I sent the right thing, but I did so I guess I have no idea what more you are wanting. The code I last posted does exactly what you are asking for:

• You wanted the chart to show timing data as it acquires the data--it does that.
• You wanted a waveform data type that you can store to an archive file that includes the timing data, you have that too.
• You say now that you want the timing data to be stored in the chart--it already is.

I haven't however used your favorite approach of writing a WDT to a chart, which as I have explained is logically not valid anyway -- regardless of what LV lets you do. You keep making a big fuss that the timing data isn't being stored in the chart but it clearly is, if it weren't it couldn't display the data properly. But more to the point, the chart has nothing to do with saving the data. It's only a display, nothing more. The code assembles a pair of timestamped waveforms when the acquisition loop completes. These waveforms are what you will use for archiving the data

(Note: this structure will not give you seamless recording of data which it seem like you are now wanting, but it was what you had in your original code, so I went with it.)

In addition, the timing data in these waveforms is more accurate than what you were developing in your original code. In my code the dt value won't be perfect (see another of my earlier posts concerning software-timed sampling) but at least it will bear some relation to reality because the same constant is at least setting the sample time and the dt value. In your code the sample time and two dt values came from three seperate constants could have been set to anything. Also remember that a WDT does not store the acquisition time for each datapoint, all it stores is a start time, a time between samples and an array of samples. Period.

If you want a system that can dump timestamped data to a file or database after some period of time, you have all the pieces right there in front of you.

Mike...

[Soroush]

Hi,

I think the problem is solved.

You say that timing is included in the chart data, but it is fed to the attributes of the chart. Therefore the data of the chart is not enough to extract timing info, so you had to wire timing info across the acquisition loop to the graph. It seems that you are not interested in binding timing to the data at all! so I changed my view to the problem and your code gave me the idea.

As you mentioned, charts are not for saving anything, but what if someone wants to save the chart data from the user interface or programmatically? the answer is in the attached code and its idea is ofcourse yours!

By the way, I'm happy to see that someone else also believes that using WDT in charts is not logically acceptable!!

Thank you Mike.

Goodluck.

[Ben]

Please see reply #71 in this thread on beer fermentaion

http://forums.ni.com/ni/board/message?board.id=170&message.id=133303#M133303

In my modification of CC's code I demonstrate how the WDT can be used with a chart to plot the actul times of the readings.

There are two restriction in using the WDT in a chart.

1) New data can not be older than the newest point already dispalayed.

2) Changing the number of plots wipes out the chart and it starts over.

Ben

[Soroush]

Hi,

I checked the program.

• Each data point has its timing info
• Timing info is quite accurate
• XY graph is used to let us store ununiformly captured data with correct time.

But your code rises some questions:

1. Do XYgraphs work like graphs or charts? LabVIEW manuals shout about the fundamental differences between charts and graphs, but we have XY graphs that seem to cover all their functionalities in one component! Why don't we always XYgraphs if they can be used as charts and point-by-point acquisition too?
2. You've said that you have used WDT type in charts, but I see no WDT and no charts. Have you ever used WDT in charts?
3. Don't we face with memory problems? in the case of charts, the history length is defined previously. In the case of graphs all the data points are defined before, but what about building arrays that are continously growing in size in successive iterations of while loop? I'm not sure about the importance of this problem, but I think that if the OS has to reallocate memory blocks for an array, it will be a major disadvantage of the program.
4. I see that you are using shift registers. I have used them in my first code here. I know that the timing in my code is not so accurate because of the possibility of loop lateness. may you take a look at that code and evaluate it?

Thanks,

Soroush

[Ben]

Please look at Beer monitor2.VI located in the llb I pointed at.

It does not use shift registers and does use a chart.

SORRY!

Ben