How do I handle this DEQUEUE issue?

[JasonWB]

Hi all,

I have a question regarding usage of a queue. I have two loops in my program, one that enqueues data for transmission on a VISA serial port and another one that dequeues them, puts the data into the proper format and then writes the data to a VISA WRITE VI. The problem is this: originally, I had problems because the while loop surrounding the DEQUEUE and VISA WRITE would not exit. I found out this was because the queue I was using was not killed and the DEQUEUE has "-1" for its timeout. I had it set to '-1' (forever) because I wanted it to wait indefinitely for data because data came from the front panel. So, now I have a few choices and I am wondering which would be the best programming practice:

1. Simply make sure that when I want to terminate this loop, I release the queue first
2. I put a non-zero timeout into the DEQUEUE function.

Which seems best? #2 has one additonal problem that I have to put a case statement around all of the rest of the code in the VI because otherwise it will improperly write data to the serial port every sec.

Comments?

Thanks,

Jason

[tst]

Your first way is better. Either release the queue which will cause an error, which you can use to stop the loop, or have another enqueue after the first loop and place a "stop" element into the loop. When the loop will detect this element, it will stop.

[JasonWB]

Thanks for the reply. That seems to make the most sense. The only other thing I did was to put a local variable "STOP" driving the termination terminal for the loop with the queue. One thing I can't really do is to put the exit command in the queue as you have suggested because I am queueing up network packets to be transmitted, not commands to be interpreted by the consumer loop. I know I could add a command to this, but since I am trying to get pseudo-real-time out of this, I don't want to waste the processing time associated with this. Every command except one would be NET XMIT 🙂

Also, for the loop with the ENQUEUE function, I did add a 1000 mS timeout. Since this is coming from the front panel and all front panel changes lock out others, I would never expect to see the ENQUEUE have to wait. I simply put this there just in case some error caused it to; but now it would just timeout and then fall out of the loop into the RELEASE QUEUE block.

Does that seem pretty reasonable to you?

Thanks,

Jason

[tst]

I don't think checking whether the string is "stop" will hurt your psuedo-RTism any more than the non-RT OS jitter, the network unperdictability, or maybe even the use of a local variable. You can just put a case around the VISA write and only write to it if the string isn't "stop".
I don't think there's any reason to use the timeout, unless your dequeue can't do its job fast enough, but I also don't think it really matters. As long as your queue is big enough and is being dequeued fast enough, you shouldn't have a problem.

[Otis]

As tst said, your better option would be the first one.

I've attached an example that may show you how to best kill a queue. There is also some additional functionality of flushing the queue, but that may not be necessary for your case. This example is written in LabVIEW 7.1.