how to debug event structures?

[klausStaehle]

i have an application where i use events very extensivly. the events (even user defined events), handled by a single event structure in a while loop. the events are created by front panel actions as well as by using the signaled value property of several controls. in some cases the vi is running as sub vi, in other cases as top level vi. in both cases it has to process events. because of timing problems it happend that a software caused event is "fired", and the execusion of the vi is stopped before the vi was able to process the event.
it would be a great help in developing such applications if there would by a chance to "monitor" the events which are created, handled and processed. is any tool available to do something like this?

[<Mike Ross> mross@smpcorp.com]

It is a fairly common practice to put a string indicator on the front panel and send messages to it via property nodes. Incorporate a short wait so you can see it happen.

Or you could make a log file by writing messages to a file for each use of an event of interest.

I suspect there are good ways to use probes and custom probes for this. These are after all the primary debug feature offered to us.

I use the producer consumer architechture a great deal which is an event loop running parallel with other queue driven loops. The user event responsive loop activates different cases according to elements placed in a queue by enqueue commands contained in the user event structure itself.

That is a difficult sentence, I will restate: a user event occurs, within that event an element is enqueued, the user event responsive loop dequeues the element and the associated case is activated, the functions contained in that case are performed. In each queue operated case one can place a property node to place a message in a string indicator. In this way you can track the function of the queued case structure.

Be warned that it can be a problem to call a vi containing an event structure. It is more straightforward to only have user event structures in the top level vi. In particular you may experience problems if a user event structure ends up calling another user event structure. Bad juju.

Certainly one can stop an event structure/while loop before all the user events that have been queued up are completed.

If a particular user event has the ability to stop the outer while loop, then that is exactly what will happen when it fires. I suggest you investigate the function of other architechtures such as the producer consumer. It is easier to control these kinds of problems in this way, IMO. You can test for the presence of unaddressed elements in a queue before allowing the vi to cease. Here I am talking about the explicit queue function that one sets up on purpose, rather than the queue that is implict in the use of an event structure. I do not know if you can sample the contents of the user event queue as it runs, probably not.

[klausStaehle]

Thank you Mike for your quick and detailed answer.
This producer consumer architecture seems to be a good thing, i have to check if and how it could be a benefit for my programms.

The intention of my solution is to create "objects" for interfacing hardware components, represented by a single "object-VI" with a number of callback-VIs coming with it, for each hardware component. The goal is to get a highly self-configurating software layer which defines a number of default methods and specific methods and properties for each object.

These object-VIs are only intend to process the default methods (e.g initialisation), the processing for the specific methods and properties is done by the callback VIs. Additionally the object-VIs should only handle th
e events which are assigned to these specific methods and properties.

Because the object-VIs provide a user interface for expert level usage as well as a programming interface to an overlaying automation software for guided usage, the object-VIs should make no difference what the events are caused by.
Because of the signaled value property, events are a wonderful thing to do this abstraction.

Nevertheless i was thinking about separating the user interaction by implementing VIs as a user frontend for my objects. But less VIs mean less debug effort and less error sources.

I am aware of the terrible consequenses in mixing up whith events by doing what i want to do. But i got some of these objects run already and it is an stable an ellegant way to interface hardware whith a software layer configured at runtime.

The only thing i miss is a independent LabVIEW tool (like the good old "DDE Spy" of Visual C/C++) to monitor "lost" events.

[<Mike Ross> mross@smpcorp.com]

That is quite a job. I don't think I am qualified to recommend a "best" architecture for it.

Producer/consumer is designed to manage parallel functions that have widely different rates of function, as in a UI vs. program functions operating at computer speeds. The UI produces requests to or data for the consumer which may or may not come slow enough that the consumer can keep up, or may be very slow in comparison and the consumer may be performing functions that are transparent to the user, or it may be mixed.

I keep returning to the producer consumer architecture because it can reproduce the functions of a flow chart. If I can describe the decisions to be made and identify when inputs are used, and outputs produced
, I can usually get a good results from a producer consumer.

However, it may not the the best for your application, but it is certainly worth knowing. Producer consumer might be great for a particular module of what you are doing, but it may not make a good overseer program. I am scared of the "highly self-configuring" comment.

Good luck,

Mike