Strange behaviour using queue

[becktho]

Hi guys

I have a problem and don't know what to do.

I already posted an entry in the national instruments forum.

I wrote a program (LV 7.0) using a queued state machine. To identify the states i use a strict type def. The dequeue timeout is set to -1, queue-size unlimited.

In a separate while-loop a boolean input is checked. If the input is set true, an event is generated. This event is caught by the event-structure (placed in another while-loop) that enqueues the specific element. Afterwards the element is dequeued and the specified case in the main while-loop executes.

The program was built to an application which runs under winXP.

This application now worked for about 3 months without any problem. Since a few days, a delay (about 30sec.) occurs without any reason. The program works eg. for 2 hours and suddenly it delays. First i thought

it was a problem in communication (rs232), but it wasn't. Using some logging entries i saw that the event mentioned is caught correctly and the necessary element must be enqueued, but it takes some seconds to dequeue the element.

How could that be and what can i do to make the program work correctly again?

Many thanks in advance.

becktho

[JackHamilton]

Becktho

Can you post a snapshot of the diagram that's receives the queue? I'm very familiar with queues and have not see this problem. You are aware that upon creating a new queue - you must flush the queue? LabVIEW retains the queue in memory - even after a destroy. (Another mind-reading feature of LabVIEW) thus, you must flush the queue upon creation - or the previous queue and any messages inside will come back like a ghost from the grave.

This issue is only when in the development environment.

Regards

Jack Hamilton

[becktho]

Hi Jack

Thanks for your answer. First of all - the strange behavior is occurring on a compiled application and the queue is created when the application is started and destroyed when the app is finished. A snapshot is attached in the thread in the NI-forum (see link above).

As you might know it's hard to free time for troubleshooting if you have to develop new applications in time, but anyway I recently put some time in troubleshooting again and, due to an obvious time-delay, I started to measure execution time of different things. After measuring the time used to dequeue an element, I had to find that this is not the problem . Now I go on with measuring the time where I think it could cause this amount of "idle"-time.

If I find out something new, I'll keep both forums (lava and NI) up to date.

Thomas

[JackHamilton]

Looking at your code this is one Queue no-no.

You NEED to put timeouts for the ENQUE functions! Yes, timeouts when inserting items in the queues. Years ago I had a program that would stop working after some time.

I traced the problem to an enque that was trying to pass data to a full queue - as the delay was set to infinite the function waited forever, never generating those useful error messages.

Also, I sound like a broken iPod - NEVER put naked queue functions on the diagram! - if you used a wrapped funtion around all the queue sends - you'd only have one place to look for debug.

"Too busy working on other new applications" - I've been there, a word of advice - 'Take the time in every new project to 1. Learning something new. 2. Improve you code architecture - write some routine that you can REUSE in other applcations.' I know -'every application if different' - yes they are and no they are not.

I've got routines now that I wrote years ago that I drop into new projects - taking days of development time down to minutes. It took me a long time of scrambling to keep outputting code to realize there has to be a better way.

Regards

Jack Hamiilton

[becktho]

Hi Jack

Ok - I'll try the one with the enqueue timeout.

But - I logged the queuesize and it never contained more than 4 - 5 elements and its size was not set.

Could the enqueue operations without timeout still raise problems?

Thomas

[Götz Becker]

...

you must flush the queue upon creation

...

This issue is only when in the development environment.

3882[/snapback]

Thx for that information!

I already gave up hope to ever fix a bug in my current app. Good thing I already had all my queue accesses wrapped in subvis .

But I have seen this bug in my standalone version too!

Greetings

Goetz