Improving Statechart debugging

[RichardS_Dynex]

While the LabVIEW Statechart Module has some capability to run in debug mode, if the statechart is broken/unable to run then the information available as to why it can't run or deploy is inadequate.

I have come across the following situations:

1. Editing the statechart, it appears OK, but when linked to a 'Run Statechart' function the calling VI is broken. No indication of why.
2. Double-clicking a state to edit it results in a 'Cannot load diagram' message. This appears to be memory corruption (completely closing LabVIEW and re-opening it usually fixes it), but the error could be more explanatory, or offer to purge the statechart from memory and reload from disk.
3. Many edits to the statechart diagrams/reactions/guards/triggers do not trigger a forced recompilation even though the functionality has changed.
4. Deploying a statechart to a Real-Time target can fail (even though the statechart and its calling VIs are unbroken), and when it does the information provided is useless. "statechart.lvsc:Instance72.vi loaded with errors" is a useless message as there is no way to relate 'Instance72.vi' to a particular object on the statechart.

Can we please have more (any!) debugging information.

• Reverse translate 'Instance72.vi' to an object on the statechart.
• Allow us to inspect the intermediate VIs of statechart compilation (i.e. allow us to open 'Instance72.vi' to see what code has been generated).
• Allow us to export the statechart as a standard VI structure for editing/running - i.e. use the statechart module as a design/documentation/template generation tool.
• Fix the inconsistency between an unbroken statechart and a broken Run function.
• Make sure functionality changes require recompilation.
• Improve Real-Time deployment to give more information than simply 'loaded with errors'.

Richard.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.