Boolean And gate - false logic where T + T = F ?

[Hazelwp]

Hi,

I've made a VI that somehow gives me an invalid output from an and gate? where T + T = F

The and gate controls execution of a while loop. The local variable is written on a spearate while loop, on 'execution complete' from a sigexp express VI

I thought dataflow into this gate would mean that the output should update whenever the inputs to the and gate have been updated?

VI snippet:

 

Any pointers guys?

Cheers,

Paul

[PhillipBrooks]

Please attach your images to the NI forums instead of a hosting site.

Many corporate firewalls block imgur.com and if the image is ever removed, your post is not helpful to others...

[Hazelwp]

edited, thanks for the tip

[GregFreeman]

[edit] misread, so my answer was irrelevant...

My guess is some kind of race condition not playing nice with the probes. But that is a bit weird.

[Hazelwp]

It is weird, it looks like the local variable is read correctly. It is false until the sigexp VI completes, writes to true, stops the first loop and is read seemingly correctly by the prbole.

The result seems to haev updated at the same tiem as the local, but has been updated with an incorrect value...

There is nothing in loop 2 to write antything to my local variable - this should prevent a race condition?

Worth linking:

http://www.ni.com/white-paper/7585/en/

[James.M · Accepted solution]

What do the probes look like if you put a breakpoint on the wire right before the Stop terminal?

or what happens if you put a sequence structure around the local variable and AND operator, so the local variable isn't read until the TDMS code finishes?

It should be pointed out that you shouldn't be stopping your consumer loop using a local variable at all. This above race condition will happen every time because the True value doesn't get read in until the next iteration after you hit stop, at which point you have no new data coming in. If you close out your queue reference after the producer loop, your consumer loop will throw an error and you can trigger the stop of the loop that way.

You should never use the queue size of zero to stop the loop either because then you will never be able to use the timeout functionality. If it ever times out, it will stop the loop.

Here's what's happening:

1. Local var Stop reads False in consumer loop
2. Dequeue function waits for data to come in
3. User presses Stop
4. Producer loop enqueues last data value and stops
5. Consumer loop dequeues last data value, outputs a True
6. AND operation with False value that has been sitting at the local variable datawire -> False to stop
7. Next consumer loop iteration
8. Local var Stop reads True in consumer loop within the same second as the end of the previous loop iteration
9. Dequeue function sits for-ev-er becuase no new data will come in

[Hazelwp]

Hi James,

Thanks for the reply. Pretty detailed.

So what I could to to prevent my race condition: 

1. After loop 1 finished - separate while loop to wait until # queued elements = 0

2. let consumer loop catch up to all ququed data

3. when queued elements = 0 - write true to local stop

4. read local - stop loop 2

5. once loop 2 finishes - clear queue

^

Not ideal - fails if something times out.

Instead - clear queue when sig exp execution completes - and look for that error code inside the consumer loop?

How do I make sure that the remaining data is read from the queue

[Joe_H]

I am not sure what is going on with your original qustion but I do have some comments about your code. 

1. I would use the standard Producer consumer model.
2. I would move the release Queue to the outside of the top loop.
3. Since the top loop only enqueues 1 element and the bottom loop Dequeues the single element, then the Queue status will always be zero since it is after the dequeue element, therefore it is not needed.
4. use a case statement in the bottom loop wired to the error out of the Dequeue element to stop the loop when the top loop stops.

This will do away with all race conditions.

Just my two cents...........................................................................................................................

See example........

[James.M]

Did you confirm that my above post is actually the problem? Making sure the local variable isn't read until after the TDMS code finishes (using a sequence structure) should verify that the problem is solved.

The error cluster from the Dequeue function should end the consumer loop. This will ensure all data is handled because the producer loop sends all before killing the queue.

[Hazelwp]

Hi James,

Yes the case structure was the trick. Stops the consumer loop correctly 

That verifies we have a race condition?

But as you pointed out in the first reply - my implementation is not ideal anyway.

I'll get the queue cleared after finishing my producer loop, and end the consumer on an error in the dequee structure (should I check this error for a particular error code?/ do I have to unwire any error-in to the queue function for this to work as expected)