Continous dynamic event loss

[martin.kretschmar]

Hello,

we are experiencing a continous dynamic event loss.

The test-main-VI is Button Menue 15.vi, all received and generated counts should be the same.

Button Menue 14.vi is included as a "not really doing some real work" example, an seems to be running flawlessly also on the customer machine. But if we replace the sleep with some larger loops then we easily can see a big difference.

On the customer machine the continous loss can be seen quite easily, here we have to run about 12000 cycles so see a small difference,

We are using a german LabView 8.2.1.

[Norbert_B]

Martin,

the way you are using the event structure in your application (at least nr 14) is the reason for your "losses".
You have to seperate the eventstructures from the event-generation. You are getting many dependencies in timing you definetly dont want to have!!

Sadly, i could not do much testing with your code since it repeatedly crashed my LV.....

hope this helps,
Norbert B.

[martin.kretschmar]

Hello,

of courseweI would like to implement a cleanly running application. 🙂

The attached Button Menue 16.vi has a Button Receiver 16.vi with no local event handling. But here we also continously loose dynamic events on our pc, but hardly any (10 in 10000).

The button tests closely resemble our application and on our pc we didn't experience any problems. But we had crahes on the cutomer pc until we disabled hyprethreading. So it looks as if there is an additional multi-processor problem. It also crahses LabVIEW 8.5.

In the real application we actually don't requre a local handling of the events. But since we have a queue, it looked as if a local handling of events should rather improve the overall stability.

[martin.kretschmar]

Hello,

attached is a more simplified Button Menue 19.vi. The Button Wrapper 19.vi now generates the events.

Nevertheless we continue to have some discrependencies on the received event numbers.

[Norbert_B]

Martin,

i still dont understand what you are up to.
Looking into your attached example reveals, that you are running into synchronization issues created by a race condition.
In order to resolve the issue, you have to rework your architecture. There are some caveats in the work with event structures. Here you can find a list of the most common mistakes done with event structures. Your problem is connected to "placing two event structures into one loop".

Tipp: Removing the Timeout-Case, the wait and the second loop in your example 19 does not miss any events anymore.

hope this helps,
Norbert

[martin.kretschmar]

Hello,

yes we had printed and read "Caveats and Recommendations when Using Events in LabVIEW" before. 🙂

Disregarding "Placing two Event structures in one loop and using dynamic registration, make sure you have a Register For Events function for each Event structure" wan't my idea. 😉

The attached Button Menue 20.vi now takes care of time-outs. It crashed, of course, with the the divisor in Button Wrapper 20.vi set to 2, with set to 4 we experienced no crashes up to now! 🙂

[Norbert_B]

Martin,

instead of posting further attempts of implementions of something what definetly CANNOT work, please describe WHAT the purpose of the software should be......then i hopefully can create an example which solves the issue.....

Norbert

[TCPlomp]

You splitted the Event Registration refnum:

This is a no-no, have a look at this post (and the rest of the thread)
In order to solve your problem you should NOT share the Event Registration Refnum in the sub-vi but create a new one:


If I run that code I have no problem  and seeing no missed events.
Viel Spass
Ton

Message Edited by TonP on 09-17-2007 05:45 PM

[TCPlomp]

If I understood the code correctly he wants to generate the same event in both VIs if in one of the VIs is pressed a button.
And if the subVI has run 4 times (every 20 ms) he generates a user event.
Things to think about:
Always unregister for an event!
Always destroy a user event!
Why don't you use the event structure to generate the 'user event'? Currently you have a polling architecture in the main VI. You could do it just like the Sub-VI
It looks like you use it like a watch-dog function (clever!) but you have a double timing regime in the main VI a 25 ms wait and a 5 ms time-out.
If you generate an event by button on the main VI the number of received events is reset on the main VI.
You don't need the outermost while-loop, it will start over and over the sub-VI which doesn't unregister his Registration Event and will create a huge memory leak.
EDIT:
It is quite hard to close your code it takes ages because of the huge number of event registration refnums. A similar problem arose here.
Ton

Message Edited by TonP on 09-17-2007 06:04 PM

[martin.kretschmar]

Hello,

Iof course I will try to avoid strict no-nos!! I want to have a 100% clean and robust implementation.

So I will read the mentioned thread with great interest!

Nevertheless I had no event losses up to now, so I still would like to understand why I CANNOT implement this at all.

Due to http://forums.ni.com/ni/board/message?board.id=170&message.id=255752&query.id=174473#M255752 we need a 2-tiered application.