My system gets weird at loop count ~2050

[Jeremy_B]

Hi,

A 9000x64 point array of doubles is going to be about 4.6 megabytes. Anytime LabVIEW has to make a copy of that much data, you'll have big performance hit.  Also, to view a dataset with 9000 samples, your graph would need to be 9000 pixels wide.  Unless you have a monitor that big, the normal way of viewing such a large data set is to decimate the data.  There are VIs to do that under the waveform palette.  

The From DDT is used only to convert the dynamic data type to something else, usually to a waveform.  I'm not sure if the normal conversion VIs can do that with dynamic data. 

What trouble are you having reading the counters?  You can sample those at the same rate as your analog inputs.  The only real requirement is that your input signal must be TTL (0 to 5v logic).  

A continuous acquisition can be stopped after retrieving at certain number of data sets.  The advantage to the continuous acquisition is that the sample clock does not stop between reading chunks of data.  If you use the finite acquisition in a loop, then when you put your individual chunks together you will have gaps in time because the sampling stops after the last sample is acquired, and doesn't restart until your loop completes its processing.  That may be acceptable for your application, but I just want you to be aware that a finite acquisition in a loop is not the same as doing a continous acquisition. 

[Scrx]

Hello again,

Some details on the 9,000 points:

While it's not that important to have all nine thousand across, is *is* important to have all nine thousand (x64) laid over each other in the circular figure. And that does not require a huge monitor, because they circularly repeat.

Altenbach proposed an intensity graph as an interesting idea, but I want the opposite; That the outliers be labeled most brightly, and it doesn't solve the data problem. I still need all the points.

To be continued, Scrx

[Scrx]

Now, on the counters, Continued:

The problem I was having... Let me describe what I'm trying to do here again. Perhaps I wasn't making myself clear.

I'm sampling a sine and a cosine, from 10 to 300Hz, 64 points per cycle, 9,000 times, and looking to see how circular they are. Specifically, I'm looking at the radius of the circular Lissajous figure, and measuring that radius. You've probably noted a little Pythagoras in there. This, by itself, works quite well (Yes, I've tried it in its very own VI, and it purrs like a kitten).

However, I also need to know how far apart the zero crossings are, in terms of counts of an external square wave, which runs, say, 800x faster (this is externally determined and programmed in as a constant).

So I ran the square wave into a counter input, and I just subtract the previous value from the current value of the counter, and that's how far it went between samples.

In an ideal world (which I have, since at the moment both signals are being generated by a 'fake' device, which digitally generates them in perfect synchronicity) then the counter would read '800 greater than last time', 9,000 times.

So I subtract first the previous counter value, then subtract another 800, to get what I expect to be about zero. And it is - For the first 2,000 measurements... 

(As an aside, actually it's about +/-3, which is marginal, given that the specification for pass-fail is only +/-12, and since I'm testing with a 'perfect set of signals', being not only digitally generated, but also synchronized, they should be +/-1 AT MOST. They're being generated by a 5ppm Xtal oscillator running at 20MHz and a handful of logic (200ns cycle time).

But at reading (roughly) 2050, it goes haywire. Suddenly the counter is read late, causing a very high value (overshoot). Then because that value is high, when it's then subtracted (as the previous reading) it's causing a very low value (undershoot). And it just gets worse as time goes on.

So the upshot is that apparently, no, I cannot sample the counters. The counters can sample the external signals, but LabView can't reliably read them. Given that the external signals are running continuously throughout, if I can't read the counters exactly when I need to read them, the results will be garbage. As they are.

Scrx

[Scrx]

PS- Workaround for the weird carriage return issue: Write the whole post externally (I used Notepad), cut and paste. That seems to work. Except when it takes so long to type that your login authentication expires. S

[TCPlomp]

Hi Scrx,

I had a look at your code and notion that you build the XY graph with data from two different acquisition tasks. (daq assistant 3 and daq assistant 4).

These data sets are not simultanious measureed over time!

Besides that your code could be a lot more readible if you right click on the feedback terminals and select 'Change Direction' this will not change the program, only the graphical representation and will reduce crossing wires (sorry this is an 8.5 feature, but with wire moving you should get the same result in 7.1).

Again if you have performance issues ditch the express VIs they are not optimized code!

Ton

[Scrx]

Hi TonP,

Thanks for your interest.

You're right that they're not simultaneous, which is why I have, until I get a better idea, given up on the idea of using the internal counters.  

They're not helpful if not readable at precision timing.  

I'm going to do all the precision counting externally, and send the PCI-6143 an analog representation of them. This analog signal can be sampled by the same task, and so it'll be forced to be simultaneous. I hope.

And in cleaning up wires? I have gotten really sick of that - Yes, I'm using 7.1 (client-ordered. Upgrading is Not An Option) and the feedback registers like to change direction on their own. The right-click 'clean up wires' as often as not makes more mess than it cleans up. When it gets really confusing I try to tidy them up manually. Sometimes not with a lot of success.

I am in the process of rooting out the 'Express' VI code, and replacing it with other items from my palette, but it doesn't seem to help much, and from the general gist of the commentary I'm getting, they won't, because I'm throwing around quite a lot of data here.

Scrx

PS - And yet another postscript; I managed to screw up completely the 'DAQ Assistant' VI. I'd place it, and it's supposed to 'build a VI' when you're done selecting input/output options, yet it stopped doing that. All I got when I placed a new one was a blue box labeled 'DAQ Assistant' with no terminals.  Double-clicking on it would bring up all the usual screens and selection options, but when you were done it didn't build.  After you clicked OK to dismiss the configuration window, it had no terminals. It was unexpandable with the mousie. Happened even on blank new VIs. Finally fixed it by deleting the entire LabView installation and reinstalling it.  Now it works like it used to, but that wasn't much fun.  S.

[TCPlomp]

Forget Express VIs.

Have a look at the shipped DAQ examples for counters.

Ton

[Jeremy_B]

Hi,

I completely missed that you are creating a circular graph, that makes a lot more sense with the 9000 points.  However, the fact remains that manipulating such large arrays is going to have performance consequences. 

As for the counter, the reason you don't get precise samples is because you use an on demand sample timed by your while loop.  The counter is free running, so the discreprancies you are seeing are related to when you are sampling the count value, not the actual count rate of the counter itself.  In the case of your VI, your loop timing is controlled by the acquisition time of your finite task, and then on top of that all of the processing that occurs in the loop.  Since data keeps getting added to the XY graph, the amount of data being dealt with in the loop continually increases, which causes the loop to take more time to execute.  Additionally, loop timing is notoriously bad on Windows based systems.  This is not the fault of Windows, it is not designed to run loops at a precise enough rate for data acquisition (real time operating systems address this problem).  Even if you had an empty loop, it would not execute at a consistent interval.

Here are my recommendations:

1) Don't use the DAQ Assistant, use the DAQmx API instead.   The API gives you a lot more visibility and flexibility in configuring DAQ tasks.  Also, with more complicated applications, the DAQ Assistant tends to start having problems.

2)  Use continuous sampling task to sample the counters, with the sample clock set to the analog input sample clock.  This will guarantee the timing of the counter sampling in hardware.

3)  Use continuous sampling for your analog input.  You'll need it set that way for the continuous counter sampling to work since it will need a continous analog sample clock, and it will also give contiguous sets of data.  Generally, if you need to acquire data in a loop, you should always use continuous.  Finite is normally used for one shot acquisitions of a fixed duration.

4)  You need to somehow cap the amount of data you are working with.  Usually when you have a wire branch, LabVIEW has to make a copy of the data in the wire.  This is normal dataflow behavior and allows parallel processing of data, but the price you pay is that you need a unique set of data for each action which is occurring in parallel.  There are several instances of this in your VI, and I would not be surpised if that array is being copied at least 4 to 5 times.