Ajay is a professional developer and architect of NI-LabVIEW applications with extreme interest in getting the hardware connected to LabVIEW and automating the stuff. Recently he is also putting his hands in NI-TestStand to get very dirty on it. He is also a good mentor for the various interns in his career. He is ready to help the people in techie roles.
A typical application in LabVIEW development flows through the stages like
Application Start-up StageApplication Running StageApplication Exit Stage
Over the years this became evident to many developers and hence they all unanimously agreed upon design patterns like state machine.
A state machine template (like JKI simple state machine) usually have these three stages of an application (as initialize state, your process states, errors state, exit state so on) and enable the developer to easily bring up the application to end customer without worrying about how exit process works. These templates are so helpful if your application runs on single while-loop or to-the-max if your application is within one target.
However, if the application extends between more than one targets (like inter-process application) then we realize that we’re crossing the limits of these templates’ helpfulness. We end-up in making our hands dirty, because when exit is initiated in one-target, then it should be exited in other target too in a proper way, sometimes you don’t know from where the exit is triggered.!
Recently I encountered one such scenario and found few tips to get my application exited properly which runs across targets. Here are those…
Identify the sources of exit events in the application. And ensure that exit trigger from each source till the closure of all while-loops (which is eventually app exit) happens in a flowy way. An application can exit can be triggered from various spots like
user event where user presses "Exit" button in your front panel, orthere might be a critical error like your host-PC can’t initiate connection with RT or many other
In case you have multi-processes (while-loops) within host PC, then it’s always good have a master process (or master while-loop) which has control over all other slave processes. The critical control of master process include
broadcasting the "initialization" message to all slavesbroadcasting the exit message to all slaves and
destroying the state-machine-queues of all slaves during exit If any slave process wants to trigger exit, ensure it sends the message to that master process; then master process broadcasts exit to all loop. Don’t allow the slaves to broadcast any messages, however slave-slave communication can be accepted Never allow the slave processes to destroy it’s own state-machine-queue, instead do it in the master process.
Typically, a real-time application (i.e., the program residing inside the controller) doesn’t have exit mechanism. It will be like a micro-controller in which user is always expected to do force-restart if he want to exit. Only the application in the host PC will have exit mechanism. However, after the host exit, the RT should go into a state which allows RT to reconnect to host after some time. In such case you can introduce an "idle" state. When your PC is in exit process, it should ensure RT has gone into "idle" state before exiting the PC application.
Other simple tips to ensure even for single-loop applications are
Never run any infinite loops (like polling for some data) under master or slave loops. Ensure there is always a condition (at least "exit" or "idle" check condition) which bring the data-flow out of the loop during exit process.For user interfaces ensure the "Panel Close?" event is always handled, else clicking "X" button will simply close the front pane but the VI keep running in background.