Read and write data at different rates, parallel loops.

[Josh_Trainor]

Machine monitoring and datalogging application.

imple question, maybe not so simple answer.

I want to read fieldpoint channels at a certain rate, say every 2 seconds, so I can verify satisfactory operating conditions of a machine under test.

I then want to write these values to a file at less frequent intervals, say once an hour, as I have no need to record all the data if the machine is running correctly.

I thought parallel loops with "wait until next ms multiple" would be the way to go, but I am having trouble ensuring that the slower loop actually grabs the values I need. I am not clear on the intricacies of shared variables, local variable, and queues and not sure which way I need to go.

Semaphores didn't seem to work for me as the faster loop grabbed control and the slower loop couldn't sneak in to read its values.

Any help would be much appreciated,

Thanks

[tbob]

 I would use a queue.  As you gather data, enqueue the data.  In the slower loop, process the data queued so far by reading from the queue until it is empty.  You can use the Queue Status vi and then flush the queue to get ready for new data.

Here is some sample code to get you started.

Message Edited by tbob on 08-06-2007 06:00 PM

Message Edited by tbob on 08-06-2007 06:01 PM

[Josh_Trainor]

Thanks tbob,

I'll mess around with the code, but I'm not sure this will do exactly what I want.

Suppose I've written 10 values to the que. In my slower loop I want to reduce my data to be the last value added to the que.

How do I do that if the que is constantly being written to?

It seems to me that the que would work better if I was processing every data point sequentially.

[tbob]

If you want just the last value written, use Index Array and Array Size as the index input.  This gives you only the last value.  What is good about the queue is that it stores all that is written to it, and you can process the elements any time you wish, as long as the queue don't overflow (limited by memory).

[Josh_Trainor]

What will happen if I'm reading the last value in the queue at the same time the write loop is adding another value to the queue?

[tbob]

You need to use precise timing, like timed loops, if you want to avoid race conditions like this.  Or you would have to use some type of lock while you are reading, then unlock so the writing could resume.  But then you could possibly miss some data while the lock is in place.

Maybe using time loops and reading just so many elements from the queue at a time would work.  If the fast loop runs 10 times faster than the slow loop, you could create a loop inside the slow one to dequeue 10 elements.  Process them as you wish.  If a queue occurs during that time, it will not be lost.  It will be retrieved the next slow loop time.

What I gave to you was a simple example to get you started.  It wasn't meant to be a final solution.  You should experiment and learn to develop from this.

[johnsold]

The queue functions have internal mechanisms to handle the contention for resources. The only way you would have a problem is if you had a finite sized queue and a non-negative timeout. And the Timed Out? output would tell you that data had been missed. Look at the detailed help for the queue functions.

Lynn

[tbob]

Actually, in the example I posted, I used Queue Status to get all elements at once, and then I used Flush Queue to remove them from the queue.  There is a possibility that a new element could be enqueued between the status and flush operations, and that new element would then be lost.  So don't use status and flush, use dequeue instead and this will ensure data protection.  Since dequeue gets only one element at a time, you would have to put it in a loop to get several elements.  You could use a while loop to dequeue and then check the status, and when empty, break out of the loop.

[Josh_Trainor]

Alright, thanks. I'll do some more tooling around. I might look at case structures (eg. case 1 "read and write data", case 2 "read only", case 3 "alarm")