Fully event-driven VIs with inter-communication

[denisvion]

Hi, everyone!

I am a newcomer in this forum. Although I played with Labview about ten years ago, I have used TestPoint for remote controlling my lab (I am a physicist) during the last ten years. I am now switching back to Labview (8.5) and have difficulties in finding the proper robust architecture fullfilling all my requirements (it must come from the fact I am used to event-flow oriented progamming rather than to data-flow oriented programming).

My requirements are the following:

- to make VIs of complex instruments that respond to several commands on demand (at any time)

- to have VIs that self update their front panel when the actual instrument (not the VI) is manually controlled

- to control an already running VI directly from its front panel or remotely from another VI as well

- to be able to remotely use VIs provided by device manufacturers without modifying (or even looking at) the code

- not to load too much the processor when the VIs have nothing to do, so that the processor can be used for data processing in other programs (C or matlab).

I came to the conclusion I had to build one event-driven VI per Instrument (that manages only local front panel events), and one event-driven super VI per application (that sends command and gets data from the other VIs through the VI server).

I have tried to implement the simplest example of such an architecture and came up with something that seems very complicated to me. So I hope some of you will be able to give me useful advices and to redirect my work in simpler directions. Attached is a screenshot with my two VIs playing the role of an Instrument (VI1) and of an application (VI2)controlling the instrument.

Both VIs are built as an init-body-close sequence with the body being an event-loop that ends when a stop button is pushed.

This event loop traps and treats prioritarily front-panel events, but do also background tasks in the time-out event, like updating the VI front panel in case the actual instrument was modified manually in the lab. VI1 is rather simple to encode (although it is a bit boring to define all the "value changed" events to be trapped). The problems start with the client application VI2. Its init step checks if VI1 is running and starts it if necessary. Then it stores in VI2 variables the refnums references of all the commands and indicators to be set or read in VI1 (from VI2). These commands and indicators are retrieved from their textual name, which is not convenient at all (especially in the case this name is not be displayed on the VI1 front panel). Then, in the main event-loop, I use a property node associated to the refnum to set or read a VI2 item. This way of programming is a bit heavy and I don't find it elegant (any better idea ?). Note that I failed in pushing remotely on the latched boolean button ( as indicated in the documentation) although I don't see any good reason to forbid the write of a value (signalize) in Labview. I have no solution for this latched button problem but modifiyng the button and code in VI1, which is not an acceptable solution fo driving VIs from third parties, whose diagrams are sometimes locked...

Thanks for your help

Denis

[LAVA 1.0 Content]

QUOTE (denisvion @ Jul 25 2008, 01:51 AM)

These commands and indicators are retrieved from their textual name, which is not convenient at all (especially in the case this name is not be displayed on the VI1 front panel).

This is an acceptable technique, make sure you never ever change the label. The most convenient way to achieve this is hiding the label and showing the caption. Only change the title from the front panel.

QUOTE

which is not an acceptable solution fo driving VIs from third parties, whose diagrams are sometimes locked...

Thanks for your help

That's a bummer, but latched buttons can't be value signalled (with reason)

Ton