LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Enqueue'd items are not recognized by consumer.

Solved!
Go to solution

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

v2009 devel. w/RT
0 Kudos
Message 1 of 10
(3,851 Views)

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.  Smiley Wink

 

Jim
0 Kudos
Message 2 of 10
(3,839 Views)
Another thing... Is your producer loop waiting for updates off of that string coming in?  (The one wired to APS DATA wait?)  If it is, that could be why it only runs once.
0 Kudos
Message 3 of 10
(3,828 Views)

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

v2009 devel. w/RT
0 Kudos
Message 4 of 10
(3,823 Views)

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.

v2009 devel. w/RT
0 Kudos
Message 5 of 10
(3,819 Views)

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...

0 Kudos
Message 6 of 10
(3,811 Views)

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.

v2009 devel. w/RT
0 Kudos
Message 7 of 10
(3,796 Views)

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!

Message 8 of 10
(3,785 Views)

Question?

 

If you break on the enqueue function, does that mean the program will pause before or after the item is enqueued?

0 Kudos
Message 9 of 10
(3,780 Views)
Solution
Accepted by topic author 8bitbanger

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", Smiley Wink

Jamie 

 

v2009 devel. w/RT
0 Kudos
Message 10 of 10
(3,770 Views)