DMC's LabVIEW logging framework has been upgraded to LLAMA. Learn more.
What is it?
Many developers may be familiar with the concept of a logging platform. Essentially, a logging platform is a modular system that is designed to be plugged into a project and allow the system to keep a time-stamped record of events with minimal effect on execution time or system resources. Think of it as a journal of a program’s execution.
One of the most commonly used logging platforms is NLog – an open source module that integrates well with .NET applications. We borrowed heavily from the concepts used in this project but wrote most of it from scratch using native LabVIEW code to preserve compatibility for as many different targets as possible.
Why is this useful?
Where this begins to pay off, is in diagnosing issues during program development or deployment. LabVIEW is known for having good in-line error handling – as long as error terminals are wired and VIs are connected, an error is passed through the execution and can be handled or displayed easily. The benefit of a platform like NLog is allowing a history of errors as well as other levels of debugging and methods of retrieval.
How does it work?
This is probably best illustrated with an example. I recently worked on a project that used LabVIEW Real-time on an EVS to do vision inspections for a manufacturing line. I added our NLog module while trying to debug issues and here’s a quick description of the logging scheme:
Trace Events: I wrote a message recording the image number every time the camera sent an image. I also wrote a message whenever the trigger input went high that recorded the conveyor’s encoder position.
Info Events: These included normal status messages to an end-user like “Image streaming on” or “Camera configuration complete."
Error Events: Anytime an error occurred in the code the error number and description would be written as a message.
When the system was actually deployed at the factory, the log level was initially set to “Info” on both our Real-time console target and on our file-logging target. This means that all informational messages and higher priority messages (like error messages) are displayed on the RT Console and written to a log file. During the course of deployment, our end customer was seeing some odd behavior. In order to quickly debug this behavior, they simply changed the Console target to “Trace” mode. This meant that they could see when they received every camera image and when each trigger occurred. By doing this it was quickly obvious to them that no triggers were being detected. They checked the cable and fixed a loose connection and then checked the console again to make sure the triggers were being received. With the problem solved, they switched the logging mode back to “Info” and continued with system setup.
I think the ROI is easy to justify here – especially with real-time systems that are otherwise difficult to debug. Without the NLog module in place, the technicians would have been either trying to fix the issue blind, or a programmer would have had to connect with a debugger or create a custom build just to debug the application.
This is just a simple use-case for NLog. There are six different logging levels included as well as multiple targets. Log events can be reported via file, database, TCP/UDP message, email, Windows Event Logs, Command-line, and several other options. Our module is written in native LabVIEW code and is easily extended with new targets for other scenarios.