Multi-Threaded Interrupt Management

[Ashley_Bryant]

Multi-Threaded Interrupt Management Capabilities in LabVIEW

Background

            Event interrupt management works well in LabVIEW if ones’ programme is small and developed within a single overall Event Structure, encapsulated within a While Loop.

            The problem comes when the software architecture demands a separation between the User Interface management (interrupt) functions and the sequential and looped programme structure (executable) components of the code for modular programming. In this configuration, waiting for Events to occur before code execution, pausing code execution (once started), stopping code execution or even aborting code execution (with the ability to close the application down cleanly prior to code exit) become challenging operations to implement within LabVIEW.

            This software architecture design challenge is exacerbated, if branching within the looped programme structure (executable code segment) is also a requirement.

Two Key Requirements

            Ideally, the following two capabilities, if implemented within LabVIEW would solve all of the aforementioned problems:

1. To be able to interrupt a While Loop, pause it and if appropriate reset the [i] loop index back to zero. If controlled via the Event structure, this would make both Event structures and While Loops compatible with each other, which is not the case today.
2. To be able to interrupt a Flat Sequence or Stacked Sequence structure and break out at any individual “Frame” in that structure, based upon a specific Event interrupt or even an Abort, which when controlling hardware can be a critical request that requires immediate action! Today, it is not possible to break out of a Flat or Stacked Sequence structure, one has to wait until the complete Sequence has executed.

Current Tools

            Current LabVIEW, if used with care, can overcome to some extent the current While Loop and Flat Sequence software architecture limitations, but they are very cumbersome to use and require an "eagle eye" and good software tracking and debugging skills!

While Loop with Pause and Stop buttons

Set Occurrence

Wait on Notification (Front Panel activity)

A not yet fully complete explanation of the key multi-threaded programming issues is attached. If it requires updating to make it complete, do let me know.

[Mads]

A break feature for the sequence structure would be nice, however (contrary to what you describe) sequence structures (especially the stacked version) are not much used in good LabVIEW code, data flow is.

Most of the problems you mention are caused by the fact that the fundamental way of controlling execution in LabVIEW is data flow. There are many advantages to this, but yes, there are also challenges - and they make it necessary to design your code accordingly. You have illustrated such a design quite nicely yourself with a state machine as an alternative to the sequence structure.

User events and the fact that multiple event structures across you application can subscribe to the same events might make up another solution to the interrupt problem you mention. It requires that you design your code so that it will allow itself to be interrupted at the required moment though...so perhaps what you really are looking for is the ability to override the flow controlled execution and stop it in "mid air"?

Let's say that you have an event structure within a while loop and several events have occured and are now lying in the event que..It would be nice to be able to put a new event at the front of the que (and/or flush the que). That would be one way of effectively interrupting multiple threads, however you would still have to wait for the already running event cases to complete - which could take a lot of time (especially if you have not taken that into account when designing the code). So instead of just being able to prioritize events you might want to have a way to forcefully jump from the currently executing code and straight to the code you now want to run (?). A bit like hitting the stop button of the VI itself. This might be an idea, however it is also a very messy thing to do as the consequences of not shutting down the code gracefully might cause any number of things (open files, partial writes etc. e.g.), so I do not think it will ever be implemented.  The access to event que operations (flush, insert at front etc.) hopefully will...

[Ashley_Bryant]

The message that "good" LabVIEW code is only based upon serial data flow is somewhat limiting, if one is writing a highly interactive, interrupt driven application. Under these circumstances, linear/serial process flow programming is very difficult to implement / implement well.

For "good" interrupt management code, it is far better to separate out the interrupt management side of the code from the actual code execution itself. Under these cirumstances, direct control of While Loops and Flat/Stacked Sequences as described in my idea would add enormous power and simlicity to LabVIEW progamming. It would also dramatically reduce the amount of screen space required for LabVIEW structures that reduce the screen space for working LabVIEW code.

[Mark_Yedinak]

Control between multiple tasks can be achieved using messaging via queues and notifiers. Both queues and notifiers will provide an event driven system. UI aspects can be controlled via the event structure and messages can be passed to the other tasks using queues and notifiers. There are lots of proven techniques to achieve what you desire without this added feature.

However, it would be nice if the event structure allowed a priority to place on event messages as well as a way to filter duplicate events.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.