NLog Logging Engine for LabVIEW

[JodyK]

I recently spent some time describing a logging tool that we use here at DMC that has significantly reduced our debug times and helped a lot with onsite support and I thought it was worth bringing it up to the LabVIEW community.

Essentially, it's a logging utility based off of NLog that allows the user to add the equivalent of print statments to their code - any string that can be built is fair game. It also allows a logging level to be associated with the print statement and this is the concept that makes it extremely powerful. Some statements can be low-level "trace" statements, while others are "warnings" or "errors". During run-time (even in an executable) the level of the logger can be changed and you can easily do trace-level debugging for a glitch, and then set it back to an informational level afterwards. 

Multiple targets are supported, including RT console, log files, TCP/UDP streams, and email. All the calls are made asynchronously, so the debug statements have a minimal impact on the code execution.

At this point we are finishing and polishing the implementation, but more information and details can be found in a blog post I recently wrote:

NLog for LabVIEW: Logging done properly

-Jody Koplo

[Ben]

I have to agree that a back ground logger is very helpful. I  have been using one I wrote in LV 6 in most of my applications and it allows miracles to be performed by reviewing the log after an exe crashes for example.

This image

...shows the Event Logger in Ation.

The light blue sub-VI with the rocket ship launches the background logger.

The VI with the warning icon and script shows how it is used in an app to log events.

The final call shuts-down the Event Logger.

It is probably the most used code I have ever developed.

So Yes an Event Logger is worth the time it takes to develop it.

One warning I should point out invloves RT targets. Background loggers may gobble up all available memory if an error storm occurs. These can be reduced if you null-out the string fileds of thew error cluster before logging.

Ben

[JodyK]

Yeah I agree, background loggers are incredible time savers.

Our implementation is still being polished, but we've used size limited queues and instant timeouts for our handlers. This means that if a handler can't keep up you end up losing messages, but that's preferable to crashing the system. With our file-based handler, I've used it for "trace" events at a throughput of about 150 log messages/sec on a real-time system (EVS) without message loss. Not sure what the upper-end on that limit is, but it would depend on the configuration of the file handler - it can be set to flush the file buffer every write (good for system crashes) or to flush it on a perioidic basis (higher throughput).

I'm pushing our company to release this code beyond just our clients. I think it could be a good addition to the LabVIEW tools network. The trade-off is obviously that we wouldn't be able to provide free support and it could eat up some of our time. If anyone has an opinion or experience with releasing a toolkit, let me know. Actually, it would also be great to know if people would be interested in using a tool like this. If there's a good amount of demand it would certainly help make a case for releasing the toolkit.

-Jody Koplo

[Nathan Vaidyanathan]

Really interesting..It will be good if it is itegrated as part of Labview and Teststand. Definitely this can save lot of time in debugging and troubleshooting. If you have finished developing the toolkit, i would really appreciate if you can post it.