How to Accelerate LabVIEW Based ATS Development, Handling Errors and Understanding Execution Flow (Part 2 of 3)

Reduce your debugging time with simple tools (2/3)

This is Part 2 of our 3-blog post series.

In Part 1 we offered a few ideas to incrementally boost testing productivity. Here, in Part 2, we go into detail on the system log suggestion. Part 3 will go into detail on Error Reporting.

How to Use a System Log

The objective of a System Log is to provide enough information about the execution of the code to enable root cause identification of simple and complex problems without requiring “debugging” time in the code. As a rule of thumb, Synovus’ ATS send information to the system log:

• When values/states are changing,
• When a user interacts with the ATS and
• Frequently enough (every minute) general system status

to understand “standard” execution flow (“Good” references) and results.

There are a few different ways of implementing a system log.

• Use the functional global variable (FGV) capability of LabVIEW, to communicate between parallel loops contained within different virtual instruments (VIs). The “functional” nature of the FGV means that you can create additional functionality beyond that of a basic global variable, for example to repeatedly record a stored value.
• Create a file on disk and write sequentially to it.
• Use the LabVIEW built in “system log” which relies on the operating system (OS) functionality. (see image below)
• Use a simple database schema, such as SQLite (a small, fast, self-contained, high-reliability, full-featured, SQL database engine that’s the most used database engine in the world).

The first option which keeps the log in memory provides the fastest access but developers must be aware of the need to “control” memory usage by capping the size of the string in memory (Synovus Symplify™ typically reserves 1MB for this) and splitting the system log into smaller, more manageable files that are easier to use when needed. The fourth option is more involved but allows smarter queries on the information than searching through multiple files programmatically or with an editor.

Trick: If you do choose to go with a simple sequential file logging, in one or more files, our developers are having a lot of success searching through many of them with the NotePad++ ‘search in files’ feature.

Whichever approach you use, with a system file in place, you have much more information about what is happening in your application, without relying on probes (i.e. the information is available when you need it!)

Gains & Next step

As soon as your team implements this into your custom ATS application, you will quickly notice how problems are resolved faster. It’s not that typical problems disappear but with more information to understand them, your team will focus more valuable time on development.

We will talk about Error Handling in our next post, Part 3 .