XControl speed problem

[tfritz]

Hi,

I wanted to encapsulate a Waveform Graph in an XControl to put some logic in there. However I have incoming data with 500-1000Hz and I noticed that lots of data got lost. I now did a little test with a counter and saw that the XControl is indeed much too slow and loses data. Is this by design? Is there anything I can do about it? If not is there another possibility to build something like a Waveform Graph that also does filtering and mean and deviation computation that can easily be used at different points in the program without copy & paste?

Thanks,

Tobias

Labview Version 8.2.1

[altenbach]

You should do hardcore computations in the main diagram, not in an xcontrol. Xcontrols are for user interactions (control/indicator).

The reason you are seeing fewer updates in your example is the fact that LabVIEW reduces indicator updates to a reasonable value. It would be silly to waste CPU by updating a control 1000x per second, if it is displayed on a monitor with a 60Hz refresh rate. Makes no sense, right?

You can force LabVIEW to process every update by right-clicking on the xcontrol and select "advanced...synchronous display".

I am also curious why you replaced the while loop with a FOR loop inside the xcontrol. Typically NI makes excellent decisions in the basic template so don't try to be smarter. 😉

[tfritz]

Hi,

the FOR-Loop was still there from some things I tried.

The synchronous  display makes things much better but it still loses some values.

The updating argument does not count with a waveform chart because there I can look at the data after it stopped and if it didn't update fast enough, I have lost values.

I know that I should do this in the main VI. But I need exactly the same code at different places and that's where I (coming from C development) would always try to use a function. However since the logic involves display, this is not as easy. But I found a compromise that will do but it's not as elegant as if I could use an XControl.

Tobias

[JeffreyH]

It's only the displaying of data that is behind, not the actual value.. You can see that by reading the XControl's value one more time after the loop is finished.

 

I'd recommend you generate a new XControl and start from there. You now have removed events that you must handle. Also, you don't have to set Data Changed? to true in the Data Change event case unless you actually change the Data Out again on the diagram of that case (which would be quite rare).

Message Edited by JeffreyH on 03-20-2009 11:07 AM

Message Edited by JeffreyH on 03-20-2009 11:07 AM

[tfritz]

Hi,

Well, but it STILL loses values, just not as many (you can see this if you add a Waveform Chart to both the XControl and the Test VI, replace the While-Loop by a for-Loop that runs 20 times and wire the "i" to both the XControl and the Waveform Chart. If you run this multiple time, the Waveform Chart will always show a straight line, while the XControl will sometimes step over values.

Also, if I switch to synchronous display it is WAY behind the Waveform Chart, so this won't do for "pseudo real time".

 I needed the Data Changed? to set to true in the original XControl together with a setting of Data out to NaN because otherwise the Data Changed Event is only called if the new value is DIFFERENT from the old and not everytime.

In short: I think, XControls are just not good for what I want to do. Too bad! 

Tobias

[JeffreyH]

You can probably work around this problem by using a graph in your XControl and do the data-housholding internally in the XControl's state data by keeping the data values in a circular buffer as your 'history'. You should then program some logic to only update your XControl display every X milliseconds.

On the other hand, with the datarate you expect, I wouldn't be using a chart at all. You're better of storing your data in a separate buffer from which you update your graph like 10-20 times a second.

I'm sorry, I don't have the time to mock-up a quick example..

[altenbach]

---

tfritz wrote:

The updating argument does not count with a waveform chart because there I can look at the data after it stopped and if it didn't update fast enough, I have lost values.

---

Well, now you are changing specifications on me. In the original post you only mentioned waveform graph, not chart. Are you trying to emulate a fancy chart using a graph in an xcontrol?

---

tfritz wrote:

However since the logic involves display, this is not as easy. But I found a compromise that will do but it's not as elegant as if I could use an XControl.

---

 Anyway, your processing is probably better done using a reentrant subVI, similar to an action engine but where each instance retains it's own dataspace. I don't understand why you need to tighly couple logic and display that makes no sense at all! These two should not be related at all. The logic needs to process all data, using any available thread while the display will be asynchronous in the UI thread and only needs to execute as often as you can possibly follow by eye. Don't try to do UI stuff at 1kHz. 😉

[tfritz]

Hi,

sorry, it is a chart. I'm using the German version here so I get confused with the english words easily. And to be honest, in the case of a waveform chart I would expect Labview to do the update logic (only update every x milliseconds but still keep all values in the history) for me. This shouldn't be something I should have to bother with.

I wanted to encapsulate this because the chart should also compute mean and standard deviation every 100 values and it should have a Size field that makes it easy to change the displayed size of the data. 

I now achieve this by passing a reference of the chart to a reentrant sub-VI that also keeps a buffer of the data in an uninitialized shift register for mean and deviation computation and returns these values so I can display them. It also takes a reference to the "Size" field and synchronizes the displayed size of data with it if necessary. I just thought it would be nice to have all of this in an XControl.

I upload a zip of what I'm doing right now. This is still a work in progress so it is not perfect.

Tobias