Community Documents
Contestant Info:
Ton Plomp, contact via PM on LAVA or forums.ni.com
User Group Affiliation:
LVUG. LabVIEW User Group for the Netherlands
Twitter Account (optional for mainpage ticker feed):
Summary:
A debugging tool to quickly spot slow functions inside a while-loop iteration based state machine, this tool will tell you during runtime which of your iteration steps are relatively slow by calculating the statistics (mean, max, min) on execution time.
Function:
When you use a state machine that runs slower than expected it's sometimes hard to spot which of the states actually is the slow state. With this tool you can debug two common state machine architectures for slow states:
- Iteration based statemachine:
- Enumeration based state machine:
As you can see from the two examples both have an (unwanted) pause of 30 ms. in the third state. For a simple state machine it's not hard to find such an error. It can however be complicated if a state machine is called numerous times or the pause is only occuring in rare conditions.
This tool offers a VI you can connect to the iteration counter or the enum, it will keep track of the execution times of every state/iteration.
It returns the following details about every state:
- Last execution duration
- Total number of executions (spot states that run a lot of times)
- Total time of execution
- Minimum time of execution
- Maximum time of execution (spot exceptional values)
Optionally it can show a pop-up which calculates the average time per state and allow sorting based on any column or export the data to the clipboard.
Used techniques
This tool has several VIs which show various techniques, I'll summarize and point to the specific code sections.
Full-size table
VI: DebugStateTimes2010.vi contains a table which is set to 'Scale object with panel'
Advantage: the front panel consists of a single element which resizes with the front panel to hide other front panel elements.
Feed back nodes to keep track of statistics
VI: DebugStateTimes2010.vi contains three feedback nodes (iteration, time and statistics) to keep track of data.
No need for a while-loop with shift registers, cleaner code with less nodes.
Optionally show a dialog
By giving the calling VI the option to show a dialog with the timing statistics it's possible to leave this code in your executable and decide when you want to show the actual statistics for debugging purposes
Reentrant VI
By using a Reentrant VI the Debug-tool can be placed at several locations without interfering with each other
Sortable Table XControl
The used table in the GUI is an XControl. To encapsulate all the code for table handling, it allows the Debug-tool to ignore any user interation with the table, those are dealt with in the XControl. The XControl is located at 'data\CM_SortableTable.xctl' and can be reviewed for the following techniques:
Limit Table to be an indicator
Since the table is not meant to be a control (users cannot enter data into the table), we enforce the XControl to be an indicator:
Messaging within an XControl
It can be hard to know what actions need to be taken with an XControl, by using a specific field in the XControl-state ability (Action), properties and method can give commands to the XControl-facade VI:
Handle complex code within a sub-vi
Some of the more complex codes sections are stored within a sub-vi. For example the calculation of the short-cut menu contents is done in a specialized VI. This allows the facade VI to stay simple.
Use of Open Source code
The heart of this XControl is the possibility to sort on a specific column, this sorting is done with an OpenG function called Sort Array, this tool allows sorting based on a specific column and a direction (ascending/descending). By using Open Source code you can harness the power of well-known and tested libraries within your code.
The download contains a copy of the function, but if you want to use the tool (and other OpenG functions) within your code I advice you to install the full library.
Besides the OpenG sort function the XControl heavily uses parts of the JKI State Machine Toolkit (TM), this allows me to not worry about message handling and use a proven technique (code reuse).
The download contains a copy of the function, but if you want to use the JKI State Machine within your code you need to install the full library.
Build dynamic short-cut menus
The table alters the short-cut menu based on the column that is selected to supply a well designed experience to the end user.
Demonstration
The following video shows an example of the code usage.
Steps to execute code:
Extract the downloaded Zip-file to a location of your choice
- Drop the VI main VI (DebugStateTimes2010.vi) in an iteration/enum state machine, connect the iteration counter and run your code, if you set 'ShowGUI' to true in the last iteration you will get statistical details about the iterations.
Note:
The last iteration is not calculated nor included in the statistics.
Screenshots:
Main Front Panel:
Main Block Diagram:
VI Snippet
The following shot shows how you can use the VI inside your own code:
Demonstration video
Future
Possible extension of this code in future round could include:
- string state machines
- enum state machines-reporting state names
- Probe creation
- VIPM compatible package
- Table colouring
- More features for the Sortable Table XControl
VI attached below
The accompanied zip-file contains the Debug-tool (DebugStateTimes2010.vi), a demo vi (TimerDemo_2010.vi) as well as all the Sub-VIs needed to use the Debug-tool.
LabVIEW user groep 
