Kabul Maharjan is a guest blogger. He is a Certified LabVIEW Architect at Renishaw.
During Developer Days at Newbury 2018, I presented how we use DQMH in our projects at Renishaw. This post supplements the presentation. We have a DQMH module template and a project template with some core modules. To watch the presentation, go to the bottom of this post.
The ability to create custom Module Templates with DQMH 3.0 played an important part in our decision to start using DQMH toolkit. Some of the updates we have made to our custom template include
- Folder cleanup
- Newly created DQMH Events will be added to the top-level library folder but the core VIs will remain in subfolders
- Package API into two polymorphic VIs
- Admin–poly.vi holds all the Events that come as part of the Template and is not expected to be modified.
- Methods–poly.vi is empty to start with. It gets added to as the module grows.
- This splits the access to the module API as “out of the box” and “user created API”
- Module data cluster is replaced by either a class or DVR Library to encapsulate the “Do” subVIs
- This enforces each MHL case to have its own subVI. This also makes the actions atomic as explained by Sam Taggart in his post and outlined by the DQMH Best Practices.
- Launcher.vi is added which includes start module.vi and synchronise module events.vi
- This also has the Main.vi of the module in a disabled case for easy access to the Main.vi through the block diagram of the application launcher.
- Main.vi’s Front Panel is modified to fit the application theme used.
- Tester is updated to fit the User Interface theme.
Post module creation
- Launcher.vi is modified to add the registration VI so that shutting down of the module is automatic at application shutdown
- Main.vi’s MHL state for “Error” is modified to Report Error the the Central Error Handler Module
Click here for instructions on how to create your own module template.
The sequence diagram below shows how modules are initialised and shutdown by the Application.lvlib:Main.vi.
All the modules used are singleton and are launched at application initialisation. A register is kept for all running modules so that the Stop Module.vi can be programatically called at shutdown.
The modules discussed below are used as part of the project template.
Central Error Handler
The Central Error Handler is divided into three sub categories.
- Display error and log to file
- Manage error lookup table
- This is generally a table that is editable by support engineers so when an error occurs, the software operator sees the problem statement and solution
- This allows redefinition of any error code for troubleshooting
- If the error definition is categorised as “Critical” Safe State is triggered
- Tracks the status of individual system components
- All system components need to be OK before controller triggers any sequences
- Tracks the flow of the application sequencing
- Receive updates about what the Controller module or its sub-sequencers are up to
- When “Finish Process” event is triggered, any failure reasons are returned for troubleshooting or diagnostics
For most applications Controller module deals with all of the application’s sequences or test routines. For larger applications however, separate sequence modules are created based on the variants. This makes validation of change to code or system easier to manage. When the Controller receives the “Start Sequence” request, it simply requests the appropriate test routine to start. The Controller then simply sets its state to “Busy” and remains idle until it receives a “Sequence Complete” request back from the test routine.
Controller and the subsequent test routine modules are the only DQMH modules where a bunch of MHL states are en-queued from within the MHL. Doing this helps with development where certain MHL states need to execute in a particular sequence. If such MHL states cannot be interrupted, a state machine subVI is placed in the MHL state which makes them atomic.
When the Controller receives the “Stop Controller” request (normally from User Interface module to close the application) it broadcasts a shutdown event and all modules are stopped by the application launcher.
State Machines in MHL
Our current implementation uses a notification for process stop and global stop to stop the state machine. This is polled at the end of every state machine iteration. A “user events” state also exists to listen to controller’s state update broadcast. However, this is only allowed to be checked when the state machine enters the user events state. i.e. the controller cannot truly interrupt the state machine to stop.
Another way of dealing with the exit from the state machine if the controller broadcasts a stop, is to place the state machine’s case structure inside the timeout case of the Event Structure. Read more about this method here.
The user interface module is customised as required by the application. The main section of the Front Panel is taken up by a sub-panel. Requests are sent to the User Interface module to either insert any VI’s front panel as a “Page”, “Prompt” or “Splash”. This layering helps the developer organise the main page for a test routine, prompt for a user input, or splash the status or the tools. Using this approach, the software user is not inundated with multiple windows and only the most relevant interaction is on the User Interface.
To access the presentation slides click –> DQMH in Action