Faster LabVIEW development with Symplify – Modify your code while it’s running (part 2)

In our previous post , we explained how our developers can interrupt a specific portion of our code to make changes and then launch that code again within the rest of the application that continues to run. There are a few caveats with this approach that one should know about when working with Symplify.

Managing the supervisor

Your application probably relies on the Supervisor to offer software and hardware based protection in your ATS. Our supervisor monitors the values that are defined in its configuration against pre-defined limits as well but it also periodically checks to make sure that the sections of the code that updates those values are running properly.

Therefore, in the course of development of a new driver, you may want to modify the code but the supervisor would realize this and send the system into E-stop. The best way to avoid this is to disable the Supervisor by writing to a Tag or directly within its User Interface a value of 600 seconds (maximum accepted by the supervisor.) Following the writing to this Tag, the Supervisor will blindly continue to kick the watchdog and disregard any value that is outside the boundaries set in the configuration. This way, you can proceed with your code changes with the rest of the application continuing as expected.

Handling references closed by LabVIEW

The other significant challenge that you may face is invalid references. A typical case would be a datalogging file or configuration file that was opened while the VI was running. Since LabVIEW associates each of those references with the “top-level VI” in the call chain, they are automatically closed once your stop that VI, even if the SubVI is still running and called by other VIs. The only simple workaround we use in our project is to create most of those references in calls from our “Main” that launches all the other code modules and is intended to run until the end.

To our knowledge, this technique should be possible also from within popular frameworks such as DQMH and Actor framework. Their software architectures based on decoupled code modules running asynchronously should support stopping a single code module and re-launching it after making changes to its code.

Watch some of our 90 seconds videos about Symplify here.