Delay/Timer only in a conditional loop.

[Neuropotential]

Perfect. I think I understand it all now. The solution for me is in your words "You need to create two queues where the producer can enqueue elements in both queues, and each consumer dequeues from its own dedicated queue"

Thanks

[Neuropotential]

Hey Ravens Fan,

I followed your suggestions and used multiple queues to control multiple loops. It worked for me. To get a better timing, I used the wait vi instead of elapsed timer vi. Most of the stuff in the consumer loops is to calculate the actual delay vs desired delay. 

When the timer value is 150ms or more (in wait vi), the queues does not stop the loop and keeps on going. I took out the errror data line and I took one error. I have attached the jpeg showing the error.

If the value is around 50-90ms, the loops stop and respond as expected. I do not see any problem. In reality I will have to use some loops with 50 ms and some others with 250ms. Infact, this value will be a control on the front panel.  

Its really interesting how some values in the wait vi can interupt the working of queues. I cannot see any connection between them. Do you have any idea about why is this happening?

Also attached is the latest version of my VI.

[RavensFan]

Put the release queues in the final frame of the flat sequence.  Error 1 is probably just a different variation of the error 1122 you were getting.

Your DAQ assistant is taking about 100 msec.  So every 100 msec, a new item is enqueued.  If the wait in the consumer loop is less than that, than the loop keeps up.  If the wait is longer than that, the consumer loop falls behind.  If you put a get queue status in there and look at the number of elements in the queue, you'll see that number growing on your loop with the longer wait.

So now you want to stop, you queue up your stop command, but there are still several elements ahead of it in the queue for the longer consumer loop.  Before that loop gets to the stop command, your producer loop will have stopped and killed the queue.  The consumer loop never gets the stop command and thus crashes on the error.  Actually even on the fast loop, you get an error.  You just don't see it because you wired the error wire to a tunnel.  As I said, put a probe or indicator on those wires.

[Neuropotential]

Got it. I think I understand my mistake. Let me know if the solution sounds correct to you. 

At present, I was only trying the producer-consumer framework and hence I kept a constant (true) because of which it always access the consumer loop. But in reality i will only rarely need to access the consumer loops. 

In my producer loop, I will enqueue data only when the relevant condition is met (putting enqueue vi inside a condition loop within the producer loop). This should allow the consumer loops to keep up with the producer loop since the consumer loops are accessed infrequently, I will try this tonight and let you know the result. In the mean time, if you think this approach is fundamentally flawed, let me know. 

Also, 1) I will put the release queues in the final frame 2) Delete all the error wires since they seem to suppress the errors.

[Neuropotential]

I moved the release queues to the final frame and deleted all the error lines.

Now the program runs as expected. The longer consumer loop does not stop immediately. It stops only after it has completed iteration equal to iteration of producer loop. So, I think my test vi is working properly. 

Now, I will incorporate all the features into this framework and then test the vi. Let see what happens.

I am learning a lot.... thanks 

[RavensFan]

If you do want to stop the consumer loop nearly right away and discard anything that is in the queue that hasn't been processed yet, then when you do the stop command, use the enqueue at other end function to put it in the front of the queue.

[Neuropotential]

I am not sure if I will need to do it. But I will keep in mind if I would need it.