|Download Help (Windows Only)|
Parent Topic: Device Software Fundamentals
Processes are LabVIEW VIs that perform a specific set of tasks within the application software. To provide a starting point when you create your own process, the NI InsightCM SDK provides a process VI template file at the following directory location: <InstallDir>:\Program Files (x86)\National Instruments\labview\examples\InsightCM\ProcessTemplate.
This topic explains the design for the template VI, including the role of each major component.
The process VI template is designed to continuously execute one of multiple subdiagrams. Each subdiagram contains code to perform a particular task in response to a message or internal action. The following block diagram calls out each major component that achieves this and other goals.
|Message Registration||Evaluation of Message Queue and States||Error Handling|
|Configuration Data Cluster and Internal Actions||Message-Handling Subdiagrams||Changes to Internal Actions|
|NI Watchdog Add-on||State Reporting||Shutdown|
The Register for Message VI instructs Qbus to add specific broadcast messages to the message queue for this process whenever a process broadcasts the messages. If this process handles only routed messages or internal actions, this code is unnecessary.
The majority of process code executes in a While Loop that repeatedly iterates as the process receives and handles messages. This While Loop contains three shift registers that serve the following purposes:
The NI Watchdog is an add-on, which is distributed on the LabVIEW Tools Network at ni.com/labview-tools-network, that ensures the RT target triggers a recovery procedure if a software failure occurs. The process template creates a watchdog when the process starts running. Each time the process While Loop iterates, this package resets the timer. If the timer reaches zero, the Watchdog process restarts the device.
At the beginning of each loop iteration, the Receive Messages VI returns the name of the subdiagram that executes during that iteration. If the previous iteration sets a priority action to execute, this VI returns its name. Otherwise, the Receive Messages VI gets the oldest message in the process message queue. For more information about how the Receive Messages VI evaluates messages and actions, refer to Determining Which Action a Process Executes Next.
Subdiagrams in the process Case structure perform a particular task in response to the string the Receive Messages VI returns. These strings can be one of the following types:
This Case structure should contain a subdiagram for each message name the process registers for or expects to have routed to it, as well as any internal priority or default actions it sets. Match the exact name, including any capitalization, of the message or action name.
The following sections describe the subdiagrams that are part of the process VI template:
The template is designed to execute the Initialize subdiagram during the first loop iteration because its name enters the loop as the priority action. This subdiagram is useful for populating the configuration cluster with values so that subsequent message-handling subdiagrams have access to them. For example, a data acquisition subdiagram might need to know how fast to acquire data, so the Initialize subdiagram can read the device sample rate property from the appropriate configuration file and bundle it into the configuration cluster.
After this subdiagram populates the configuration cluster, it calls the Set Listener Process State VI to set its process state to configured. If a process does not set its state to configured within several seconds after startup, the Controller process logs a tracepoint that reports the process was not ready.
The default case handles execution in the following situations:
This subdiagram handles Exit messages that the Controller process sends when any process returns an unhandled error. When the Receive Messages VI receives an Exit message, it stops the While Loop in the process. This means the Exit subdiagram is the last code that executes in the process before it stops. Therefore, use this subdiagram to close references, free resources, and so on.
At the end of each iteration, the Log Loop State VI sends a message to the Tracelogger process so it logs a LoopState tracepoint. This tracepoint contains the current process name and the name of the case it just executed. These tracepoints are useful for debugging issues in the application software.
|Tip The tracepoint is included in the tracelog file saved on the server machine and available to be viewed on the Trace Logger tab of the Utilities page in the InsightCM web application.|
If an error occurs, the Catch Error VI performs the following steps:
If no error occurs and if the message-handling case that just executed specifies a priority action, this VI returns the name of the priority action. To allow the process to return the oldest message in its Qbus message queue, set the priority action as an empty string.
When a loop iteration is about to finish executing, you must prepare for the next iteration by defining a priority action and a default action. The priority action is the case to execute without waiting to receive messages from Qbus. The default action is the case to execute if the timeout for receiving message elapses. If you do not need to perform a specific case, specify empty strings for both the priority action and the default action.
When the process While Loop stops, it no longer needs to receive messages from Qbus. The Destroy Listener Process VI frees up resources by removing the process from the processes for which Qbus implements communication.