bug in lossy enqueue

[User002]

Hi,

In my project I use consumer/producer processes using queues for measurement data transfer

When I dequeue elements in a consumer process, from a queue that is initialised to size one and containing waveform elements, sometimes empty elements are returned. Is this a known bug?

I have a workaround for this, checking if the element is empty.

/Roger

[Norbert_B]

Roger,

a queue does not lose data. If data is enqueued, it will be available at the receiver in the exact same manner as it was enqueued.

So the only possible explanation for an empty waveform is that your enqueue already enqueues an empty waveform....

What is the source of the waveform? How fast do you acquire the data? How often do you enqueue?

hope this helps,

Norbert 

[User002]

Thanks Norbert,

Let me explain in some more detail.

The producer process is aquiring analogue data sampled at 1000Hz, and looping at 100Hz in a timed loop. The data is then lossily enqueued into the single element queue.

The consumer process then reads from this queue at 100Hz, and sometimes dequeue element returns empty elements.

The processes are run in different threads.

It could be the case daqmx read sometimes returns no data, I haven't verified this, though, but I find it unlikely since dequeue element was added recently in LV8.6.

Regards,

/Roger

[Norbert_B]

Roger,

could you post your code in order to find out the reason?

thanks,

Norbert 

[User002]

Hi again,

Basically, I was just wondering if it was a known bug in LV before trying to isolate it further?

Anyway, thanks for you help and I'll get back with more info.

Regards,

/Roger

[Ben]

---

RogerI wrote:

Thanks Norbert,

Let me explain in some more detail.

The producer process is aquiring analogue data sampled at 1000Hz, and looping at 100Hz in a timed loop. The data is then lossily enqueued into the single element queue.

The consumer process then reads from this queue at 100Hz, and sometimes dequeue element returns empty elements.

The processes are run in different threads.

It could be the case daqmx read sometimes returns no data, I haven't verified this, though, but I find it unlikely since dequeue element was added recently in LV8.6.

Regards,

/Roger

---

You always have the option to post some example code tht demos this condition but it sound like proper operation.

If the file write operation takes longer than then time period of the timed loop it will (by defaul) try to catch-up and run the cylce it missed. So if nothing was queued up between the time the queue was read and the timed loop ran the catch-up cycle, everything makes sense.

There is a status code returned by the timed loop that tells you if it finished late. You may want to monitor that flag.

I think you have found the proper way to handle this condition.

 

Ben

[Norbert_B]

---

RogerI wrote:
[...]

 I was just wondering if it was a known bug in LV [...] 

/Roger

---

Roger,

experience shows that queues do not lose data once it is enqueued. Therefore your case would be the first one i have ever heared of.

Please post some code showing what you are seeing. I am still very sure that your method of enqueuing creates the issue.

Norbert 

[Ray.R]

I agree with Norbert & Ben..

---

RogerI wrote:

... I was just wondering if it was a known bug  ...

---

The answer is no.  I have never heard of a lossy queue being a LV bug.  Try what was suggested.  Posting your code will be the fastest way to find the problem.

R

[User002]

Ben, thanks.

I'll configure the timed loop to not try maintaining the phase and see what happens. 

I have the code in my other workstation.. I was just curious knowing if it was a known bug in lossy queue. Well, I suppose it wasnt. 🙂

Regards,

/Roger

[dan_u]

---

Roger wrote:

The consumer process then reads from this queue at 100Hz, and sometimes dequeue element returns empty elements.

      and 

I'll configure the timed loop to not try maintaining the phase and see what happens.  

---

Do I understand correctly that you're using a timed loop in the consumer process? Usually the consumer process is timed using the data frequency, in your case by the queue. Do you use a timeout in the dequeue element? If you do you should check the "timeout?" flag, as it will return the default data (empty waveform for instance) when it times out.

A timed loop somehow isn't really compatible with a dequeue element. Use a plain while loop and let the dequeue element (without timeout) handle the timing.

Daniel

Message Edited by dan_u on 02-25-2009 01:36 PM