Pulse/Period measurement to control VI

[Ross@UL]

Hi

I am enquiring regarding controlling a vi iterations with an external trigger. Let me summarise my VI first.

I have a for loop using single point aquisition i need to run for a specific number of iterations depending on the time base between my external trigger (this is approx. 1-3 seconds). This is located in a while loop containing a number of other data manipulation including limit testing etc. The reason i am using single point rather than buffered is that i need to display the data in RT and (from my knowledge) i can't get the buffered aquisition to do this, or even waveform AI to do it either.

I have used the measure period VI in labview to obtain a time in either s or ms within the while l
oop and passed this to my for loop to iterate x times.

The problem is (which actually makes sense!) when the while loop runs it must recieve two pulses from the external trigger before it can pass a number to the for loop. The result of this is that i lose sequences (a sequence is the data occuring between the pulses).

The VI does exactly what i want BUT the timing is all wrong.

What i need the VI to do is capture the time between ALL the pulse sequences, so that when the VI reiterates, the number of times the for loop must iterate is already in place. I have tried buffered pulse measurement but can't seem to get it to work as i think it should.

Any ideas? It is kinda difficult to explain this exactly in writing but any solutions appreciated.

R

[markwysong]

Ross,

I'm not sure exactly what you're doing, so I'd like to see your VI if you can email it to me at mark.wysong@ae.ge.com, or attach it here. However, you CAN get real time readings from a continuous acquisition and display them on the screen; I do this all the time.

Mark

[Ross@UL]

MArk

Thanks for taking the time to help me out, but unfortunately due to IP restrictions i cannot e-mail you the VI. I have managed to figure out most of the problem above but as always a new one appears that i think you may be able to help me with.

I have a while loop running within another to collect my data until it is stopped by an external trigger. So lets say the trigger occurs once every 3 seconds or so, at the moment using the single point aquisition i am collecting roughly 210 points or so but as you probably know this is variable! As the while loop is running there is a chart inside to display the data in real time. How can i set up an AI to obtain data at, lets say, 150Hz and function exactly like the vi does at the moment.

I'm actuall
y going to extract the code from the VI and attach it here (i'm sure the company won't mind to much!!)

Regards

R

[markwysong]

Ross,

There are definitely different ways of doing this. The way you have done this in your VI will work; however, there are drawbacks. First, each time you call the AI single point VI, it performs a configuration, which takes time, so you're doing this 4 times every loop. This slows down your readings.

A better way is to scan all four channels at once, and then read them all at once, saving the time to configure every loop. Even better than that is to run a buffered acquisition, and read the most current data out of the buffer.

Therefore, I would propose taking a look at an example in the LabVIEW directories for a Continuous Scan example. It will show you what VIs you need to set up the acquisition. Then, there will be a while loop w
hich reads the data. What you'll need to do is look at the inputs of the AI Read VI. There's an input to tell it where to get the data. If you set it to "Relative to the end of the buffer", and tell it to get 1 point, you'll get the most up-to-date point for all 4 channels. Then you can combine the channels to get your plot, just as you are now, and you can look to see if your trigger happens.

Second, when the trigger does occur, you can do an AI Read outside of that loop and read the ENTIRE buffer, to get ALL of the points. These will be at whatever scan rate you set up, but they will be nice and evenly spaced, not determined by the loop time. So, in this manner, you can still get real-time updates of what's happening, but your scan rate can be higher than the loop time, and you'll still get all the data. Got it?

If you need an example to demonstrate how to do this, I'd be glad to show you.

Mark

[Ross@UL]

Mark

Thanks for the info, its much appreciated. I have had a look at doing what you said by adapting the Cont Acq&Chart (buffered).vi example in LV 6. I can't seem to get the VI to do what i expect. would you mind sending me the example of how to do this? I understand the logic of the method you outlined but putting it in to practice is a whole different kettle of fish!!!

Regards R

[markwysong]

Take a look at this VI, Ross.

Mark

[Ross@UL]

Mark

Thanks for the VI, it looks like it is going to do the job for me, but i have one problem with it. The whole buffer contains only one scan, the same as the real time data. I'm sure its something simple i'm overlooking but i can't seem to figure out why. Do you have any suggestions. The VI makes sense and i think it should function as we need it too. Again thanks for the help, i can actually understand buffered AI now!!

Regards R

[markwysong]

Ross,

I'm not sure why it would only read 1 sample when reading the whole buffer, but here's a better way (see attached VI).

What has been added is determining the time. Every loop iteration, elapsed time from when the acquisition started is calculated. Then, when the trigger goes high, the last AI Read outside the loop now uses the END of the buffer as a reference. The offset from the end of the buffer is calculated by taking the elapsed time (ms), dividing it by 1000 to get seconds, then multiplying that by the scan rate to get total number of scans. That is negated to move the marker that far back from the end of the buffer. Then, that total amount of data is read from the buffer. This SHOULD return the amount of data that was acquired between trigge
r pusles.

Try this one and see if it works (I don't have aDAQ card on my work PC here--they're in other PCs in the plant).

Mark