Event response delaying exponentially longer

[cdreike]

LabView 2010

Using a basic producer/consumer model queued state machine with 6 events I'm having a problem.

The response time to the events increases every time an Event occurs.

This is a very simple application. It uses strict type dev enums for selecting the states in the consumer loop.

Clicking on any of the 6 events increases the response time of the subsequent Event.

The consumer loop has a delay of 250ms. No other timing is used anywhere.

Any ideas as to why the Event response time is ever increasing?

Thanks,

Chris

[altenbach]

Attach some simplified code. We are not clairvoiant! 😄

How do you measure the response time? How long does it take to consume the queue entries?

Thanks!

[cdreike]

Thanks Altenbach.

Attached are jpg's of the front panel and the block diagram.

After clicking one of the buttons on the front panel I can watch not only

an LED on my output circuit board, but also the "element" box which shows what state

will be excecuting.

Each subsequent click of a button requires a longer and longer time span before the next

state shows up on the front panel and the LED supports that result.

Thanks,

Chris

[altenbach]

This cannot really be debugged from picture. Attach some actual code! What is in all other events/cases? One potential problem is the fact that the consumer loop also produces queue entries. Can you monitor the queue size, for example?

[cdreike]

Thanks for the hint. Looks like I am somehow enqueueing 2 times instead of once. Have not yet found the error.

I rewrote the vi starting from the producer/consumer example and made a new strict type def enum, to no avail. Should be clean that way.

To troubleshoot,I inserted a queue status vi in front and back of the dequeue On the front panel I have both queue counts at the top.

Its sort of fixed. I added an extra dequeue inside of the case structure to get rid of the extra queue element. Not very satisfactory, but it should work.

I have attached the .vi and the .ctl files. 

 I have used this exact pattern many times in the past with no problems. I created a large LV9 application last year to run a machine. Ran perfectly.

Best Regards,

Chris

[altenbach]

A lot of your code makes little sense. You should not enqueue anything in the consumer loop, it should exclusively consume queue entries. You enqueue a wait element in most cases, even in the wait state. Why??? What should happen in the wait state? If you just want to wait until another element is equeued, set the dequeue timeout to -1 and it will wait forever until an element is enqueued or the queue is destroyed. (catch that via an error and thus stop the lower loop once the top loop completes)

All event cases in your producer loop enqueue an element. Shared code belongs outside the event case, now only one instance is needed.

What made you change the mechanical action of the buttons to "switch until released" and use "mouse down" events. A more reasonable way would be latch action and value change events.

Why do you have a 250ms wait in the consumer loop? If you really want to spin 4x/second even if no elements are enqueued, set the dequeue timeout to 250, for example. (see attached). If you only want to process elements, set the timeout to -1.

What is the purpose of the 1000ms wait before releasing the queue?

The attached modification shows some of the points made, it is in no way complete. Modify as needed.

[cdreike · Accepted solution]

Christian,

Thank you very much.

I've learned a great deal today.

Not sure why I did not have any problems in past programming. Nice to have someone point out what is going on.

Been quite a while since we've had a LVUG meeting here in the south bay.

Best Regards,

Chris

[altenbach]

---

cdreike wrote:

Been quite a while since we've had a LVUG meeting here in the south bay.

---

Ah, now the name rings a bell. Good to hear from you. 😄

We actually had a LVUG here at UCLA recently.

I got rid of my car and take the bus to work, so it is more difficult to go to other user groups unless I can borrow my wife's car or can carpool in some other way. The 405 freeway is no fun either way. It once took me 80+ minutes to drive the 22 miles from UCLA to Carson for a user group meeting...