Missing dynamic user events across VIs

[martin.kretschmar]

We have a sub-Vi Statemachine.vi, which has its own event structure with a 5ms time-out, everything enclosed into a loop.

This sub-VI is called repeatedly from the main application with command lists to execute. This can be a longer list or e.g. an empty list.

It turned out, that we can miss successfully sent events, despite the documented internal queues.

Placing the event structure into an added parallel executing, non-terminating loop in the sub-VI seems to help.

Is there a link to further informations about this behaviour? We are using a german LV 8.2.1.

[andre.buurman@carya]

Hello Martin,

Can you disclose the source code?

Preferably in simplified form that demonstrates your issue with the event structure (loss of events), german names are not a problem.

Could be some initialisation problem, because its in a subVI.

Kind regards,

André

[martin.kretschmar]

Attached is a working sample, where pressed buttons are reported immediately and without up to know none noticed loses of events.

It should be noted however that just right now, I received repeatedly the same user dynamic event in the event handling structure of the sub-VI. This seemed to coincide with a break point in the event handling structure of the main application.

We are using a german LabVIEW 8.2.1.

[andre.buurman@carya]

Hello Martin,

If I look at the big picture the architecture you are going for looks at lot like to one I often use.

Communication between parallel running VI's with User Events.

Try putting the Creation, Sending and Destruction of User Events in a LV2 style global, also known as an Action Machine.

You never registered "Benutzerereignis erzeugen" User event in the event structures for capture.

By the way you should always unregister for events and destroy afterwards.

I hope this helps you.

Kind regards,

André

[martin.kretschmar]

How can we capture "Benutzerereignis erzeugen" User events in the event structures?

This option is offered nowhere or have we overlooked something?

[andre.buurman@carya]

Martin,

I overlooked something. The User event name in the event structure takes the name of the variable with which you create the  User Event refnum tat you register. in your code its "Value changed event".

"Benutzerereignis erzeugen" is german for "Create User Event". I know some german, but overlooked the obvious.

What you have works just fine, except for the lack of unregister and destroy user event and the fact that the Stop button in the main VI doesn't stop the subVI's.

This can easily be overcome by creating another user event called "terminate"or "Stopp". And register that event in the subVI's only. Add a true boolean in the event structure for the Stopp event and wire it to the condition terminal. Make the  tunnel "Default if unwired", so every other event will return false.

Generate the Stopp user event in the main VI when the Stopp button is pressed.

Regards,

André     

[martin.kretschmar]

André,

thank you for all of your replies! 🙂

In our real application the event world seems to be divided into two parts, sort of. We still would like to better understand how to correctly program events,

The main application successfully receives events generated from its sub-Vi "Generate Value Changed Events.vi" of its sub-VI Statemachine.vi.

"Generate Value Changed Events.vi" has its own "Generate Event" etc. structures, more similar to "Button 6 Menue.vi".

We would like to send our own key pressed events down to the Statemachine.vi, but right now the sent events are not recognized.

We had created a version of the Statemachine.vi, which passed the event down. This successfully allowed to receive the events, but therefore "Generate Value Changed Events.vi" was no longer responding.

Exists an URL, how good and correct event handling programs should look like and how debug unwanted effects like those mentioned above?

[andre.buurman@carya]

Martin,

I don't know of a good document describing the use of the user event in the way the you and I are using them.

I've learned from bits and pieces lying around and my collegue. After using it for two years now I have a framework in which the use of user events is relatively easy.

I know this doesn't help you a lot, but I know that if get the hang of it, it will provide a good and usable architecture.

I hope the attachments helps you a bit. It is the way I define user event for inter process communication. It will get rid of a lot of wiring.

Kind regards,

André

[martin.kretschmar]

A last notice: we are now able receive our events, although it's not 100% clear why! 🙂 😉

The sub-sub-VI "Generate Value Changed Events.vi" was changed from an input refnum to an input event. Probably this caused a more intensive internal rebuild, because all of a sudden all the existing code came to live! 🙂

Previous tests with variants of the Button6 example had shown, that playing with the events resultet only in local effects within the edited sub-VI.

And the afore mentioned excess receiving of events was now seen again. But it looks as if that is just a debugger "mistake." If all halts are removed, then no double events were seen again.