Strange behaviour using queue

[becktho]

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?

[Joe_Guo]

monitor the system for memory leaks, that normally slows down the application.

try set the timeout value of the dequeue vi, also try to flush the que once in a while.

-Joe

[becktho]

Hi Joe

I made the changes you suggested. The Program seems to work correct again.

Thanks.

[becktho]

Hi Joe

Now, half a year later, I have almost the same problem again.

I enqueue an item - the time until the element is dequeued varies. Most time it is under 3sec but sometimes it takes about 14sec. This problem occurs about 20 times a day. In the case, which is called in the dequeued sequence-frame I enqueue another item. The time until the element is dequeued varies also. The maximum time is also about 14sec but in this case it's not so often (about 5 times a day).

The problem occurs under a built executable in irregular time-periods.

Do you have any ideas about that?

Thomas

[DFGray]

There are several options. Use the profiler to find out where CPU time is being used in your program. If you are stuffing the queue from UI events, are you using the event structure or a polling loop? If you are using a polling loop, do you have an appropriate delay in the loop (somewhere between 20ms and 200ms is usually good, but you really should use the event structure if you can).

Are you generating events faster than they can be processed? A three second delay between event and process is not normal. It should be almost instantaneous. Put some code in to check the queue length every time you process an event. If the queue keeps growing, you have a real problem. Change your algorithms until it works (or use this as an excuse to get that Athlon64 3400+ you've been wanting). A common cause of problems is stuffing multiple copies of the same event into the queue when you don't need to. Is this occurring? If so, query the queue for its contents and filter events going in to prevent duplicates.

Is the machine you deploy the executable on slower than your development machine? Does it have less RAM? Either could cause a problem. Both require either tighter code or better hardware.

Good luck and keep us posted.

[becktho]

Hi

I developed the program on a P4, 2.8GHz, 1GB Ram and the executable is now running on a P4, 2.5GHz, 512MB Ram, both running with WinXP.

I include you some pictures out of my source. CatchEvent and MainLoop are in the same vi. In CatchEvent you can see, that a enqueue a constant ("Steindaten lesen") which is enqueued in MainLoop (also you can see that I enqueue two more elements in "Steindaten lesen" case).
The third picture shows you how the event is generated. This is a separate vi, running parallel to the main loop. I poll for a digital input (on a FieldPoint-bank) - if it is set I fire the event "Evt_StartPrüfung" (the other cases in this pictures diagram are empty).

As you can see in CatchEvent.jpg and MainLoop.jpg I added Log-Statements in my sourcecode. The time mentioned in my previous post can be taken out of the logfile, according to the entries with INFO-Level from CatchEvent and MainLoop (which also means enqueuing frame and dequeuing frame).

You can also see that my main loop has a time delay of 50ms, which should be quiet enough. If I would fill the queue excessive or use to much memory, the timedelay between enqueue and dequeue should occur more often than it actually does and I also think it should occure more regularly (on 14th it occured 25x, on 15th 8 time and on 17th >50 times). The queue is flushed every hour - so I think there are not to many elements in it.

By the way - the program controls a tool-performance test on a assembly-line, where approximatly every minute another tool is tested.

Thanks in advance for any help.

Thomas

[Joe_Guo]

try to reduce the timeout for the dequeue to 100ms or even 50ms. Is the dequeue vi being used at multiple places? If so, then you might have a synchronization problem.

-Joe

[becktho]

I used the dequeue vi at multiple places, but not within the same vi. I've some user-interfaces, which all are built up on the same system (events using queue).

I'll have a look at what happens if I reduce the timeout.

Thanks

Thomas

[becktho]

Hi guys

I tried what you suggested. I reduced timeout to 100ms but the problem still exists. I also recorded queue-size but this should also not be the problem (I never had more than 4 elements in the queue).

I'm totally at a loss and appreciate every idea.

Thomas

[Matt_F]

Hello Thomas,

Had anything changed on your system (SP2, new hardware, new software utility installed) before the behavior occurred?

Is it possible that some process on your computer is starving the LabVIEW thread that is responsible for de-queuing elements?

Looking at factors outside of LabVIEW may turn up the culprit for the behavior.

Regards,

Matt F