Need help with reading 1D array from Queue

[MicahKurtz]

Hi,

I am working on a project where I am using the cDAQ 9132 with some digital I/O cards. My goal is to fire a voltage pulse for a short time using the card with an external circuit and one requirement is that I can fire a full set of channels with one button press. My thoughts were to just create and array and insert it into a queue using a for loop, read the queue and fire away. The actual firing is working just fine like this but where I am having trouble is providing the user with visual feedback of the pulses. In order to do this, I need to be able to read into the queue right after I insert an element into the queue. For some reason sometimes an element is skipped when I read into the queue and it often times gets out of order if I push the 'fire' button several times.

I don't understand why the queue is working ok for the firing (although it too gets out of order sometimes) but when I try to read it, it acts completely different. Any thoughts? I am sorry I can not post my entire VI but here is a snapshot.

[cbutcher]

Difficult to say without any idea what the subVIs do, but looks like a possible race condition between Fire Primary Channel 1 and Set Record Flag, if the record flag is related to recording the output/input?

What do you mean by 'read into the queue'? If you dequeue elements in one place, you can't also dequeue them somewhere else - a queue is a Many-to-One kind of communication. It might be that your elements are being partly read in the producer loop (I'm assuming that's what's going on with the visible event structure and while loop) and not by the presumably invisible consumer loop?

[crossrulz]

You cannot trust the Preview Queue in the producer loop.  If your consumer is sitting there waiting for the data, it will process it as soon as you enqueue the element and then your preview will be something else.  Or another possibility is somebody else enqueued data on you.  Just do not use the Preview Queue and just use the string you are passing into the Enqueue Element for your case structure.  Then you will know what your data is.

[MicahKurtz]

The subVI 'Button Press' indicates which button was pressed to provide visual feedback to the user. In this case where I want to run all the channels one after another, the code should read what is in the queue from the array and change is case depending on what is in the queue. So the next case is 'Fire Primary Channel 3', '..4' and so on. Whats happening in sometimes when I read the queue, with the indicator 'queue' it doesn't match what is in 'array' indicator from the actual array.

The 'Record Flags' array sets some functional global variables to allow the program to begin recording, which in turn allows the program to to the actual firing. Once the firing is completed, the recording stops.

[altenbach]

I see several problems and potential race conditions and would not trust this code at all.

Never hide event structures inside case structures. Are there other event structures in other cases?Should the subVIs inside the innermost case structure execute in a certain order? How about the two on the left? Why are most wires misaligned and partially hidden? Previewing the queue element will return whatever is in the front of the queue, which will often be the same unless you are dequeueing elsewhere at a very, very fast rate. Are you?

We clearly need to see more of the code to give more detailed advice.

[MicahKurtz]

Can the queue processing the incoming data at the same rate that the for loop is imputing the data? I am worried that the for loop would move faster and that I would be firing a different channel then what is ready in the queue. The queue is actually the one responsible for the channel firing. This case statement just tells the program what  channel to indicate to the user and provide feedback.

[altenbach]

---

@MicahKurtz wrote:

Can the queue processing the incoming data at the same rate that the for loop is imputing the data? I am worried that the for loop would move faster and that I would be firing a different channel then what is ready in the queue. The queue is actually the one responsible for the channel firing. This case statement just tells the program what  channel to indicate to the user and provide feedback.

---

Please always quote part of the post you are replying to. Out of context whatever you are writing makes no sense.

[MicahKurtz]

I am dequeueing the element once it is passed into the function that is doing the actual firing of the channels. 'Button Press' and 'Record Flags' VIs don't depend on each other and don't need to be run in a certain order, nor do the two on the left. Everything besides 'Record Flags' are functional global variables which only indicates either telling the code which channel was just fired, and how to update the front panel LEDs to tell the user if the test was successful or not.