11-24-2008 01:28 PM
Hi Folks,
I have a seeminly strange problem with a fairly simple producer/consumer loop. The producer waits for data acq, then queue's the data for display/logging purposes. The sample rate is only once every 4-5seconds. The strange thing is this works on and off. I just can't get it to operate correctly.
If I break on the enqueue subvi, it breaks at regular intervals. However the program will break once (at start) on the enqueue, and never again.
The queue size is fixed (for testing), but I do not see an overrun issue (I tested with -1 and it still 'works' the same).
Again this *sometimes* works exactly as it should, other times it doesn't. I tried changing the tunnels in the consumer to shift registers but that didn't help. The Preview Queue loop to the lower left was added but it doesn't provide any insite, only returning the (correct) queue name and zero elements/pending. The elements output appears to be un-initialized.
Any thoughts on what could cause this?
Best Regards,
Jamie
Solved! Go to Solution.
11-24-2008 01:42 PM
Hi Jamie,
I stared at your screenshot for a while, and nothing really jumped out at me. Monitoring the queue items is also where I'd start, too.
Is this on an RT target? I'm only asking because after your signature you mentioned you're developing with it. If it is, then I've definitely got an idea or two... If it's not, I'll go back and stare at it some more.
Jim
11-24-2008 01:56 PM
11-24-2008 02:01 PM
Hi Jim,
Thanks for the reply. To answer your question, "sorta". 🙂 This portion of the code resides on a PC, non-RT. Code within the 'APS Data Wait' subvi communicates with a cFP-2010, but it is mainly just a hacked RS232 'tunnel' of sorts.
If I 'shut off' the consumer (by rewiring a boolean 'true' to the large case statement) I can see the element begin to enter the queue. Worth noting that I can see the *counts*, but again no elements from the 'elements' output ('still appears un-initialized).
Some examples use a shift register for queue references, some do not, so I'm not 100% sure what the purpose is (when the queue itself is buffered). The tunnel should maintain the correct reference after the first iteration correct?
Jamie
11-24-2008 02:04 PM
The string input to 'APS Data Wait' is a static IP address used for LOGOs.
The producer seems to chug along just fine - if I place a breakpoint on the EnQueue, it happily breaks every 4-5seconds, and I can Probe the Cluster and see changing data.
11-24-2008 02:17 PM
Hmm.... Well, I can tell you for sure that you don't have to wire the queue into a shift register, because it's really just a reference and thus shouldn't change. (Unless you reinitialize the queue inside your loop, in which case the reference will change and you'll need a shift register)
Here's another idea...
If you wire up the error cluster from your queue initialization and your enqueue function in the producer loop, do you see any errors on those? Additionally, are you seeing any error come up on your "Queue Error" indicator? Sometimes if you hit the "abort execution" button on the VI, it can leave the queue reference open and not close it out properly. If that's the case, the queue might not initialize properly the next time you run it. You'd see an error and nothing would go through.
Regardless, I'd check the error clusters first, because the most obvious problems will be there.
I hope it helps...
11-24-2008 02:52 PM
Well I suppose I should revise a previous statement. After seeing the producer/consumer *work*, I stopped, disabled the consumer, and added the 'Preview' directly after the enqueue (as shown below). The queue preview does not reflect *any* data, although I am breaking at both the enqueu and preview (and the probe shows data).
I'll wire up some error ind's but I did not previously see any errors present.
11-24-2008 03:01 PM
Wow, that's really odd. So you're not seeing any elements in the queue from the "Get Queue Status" function? Ordinarly, at this point I'd wonder if you have a tunnel miswired somewhere and the correct queue isn't being referenced... (In which case you'd see errors) but you said it worked intermittently. I'd definitely check those error clusters just for sanity's sake. If that doesn't reveal anything, I'd save a copy of the VI, strip it down to its most basic elements, and see if it works with a random number or some other simple example. Without being able to see the source I'm running out of ideas.
Sadly, I'm actually leaving to go home in a minute, too. If you're still stumped tomorrow and no one jumps in to help, I'll certainly take another look in the morning.
Best of luck!
11-24-2008 03:15 PM
Question?
If you break on the enqueue function, does that mean the program will pause before or after the item is enqueued?
11-24-2008 03:21 PM
No need to rack your brain further. A few points worth noting:
-my method of 'disabling' the consumer was not valid - I needed to enclose the 'Dequeue' within a case statement to allow the 'preview' to catch the elements.
-after doing so I *still* didn't see elements in my preview queue on the lower left.
Point number two led me to realize that the consumer was executing ONCE due to a race condition on the 'STOP' boolean. It is set to 'switch when released', and although I take great care in re-init right before exit, and again re-init in an Initialization vi, it still did not catch it.
<insert about two hundred embarassed emtiocons here>
It's run about 5-6times consecutively now with no hitches. I greatly appreciate your help- thanks!
"Learned",
Jamie