Logging in LVOOP projects

[dim_V]

Hi guys,

I am currently working on quite big project based on LVOOP, and I can’t decide on how to implement logging? At least I have hardware, protocol, and software logic layers. I was thinning to use singleton Log class, also Observer pattern can work. Can somebody advice how to organize logging approach? Any examples from your experience are appreciated.

P.S. Sorry if my English is silly sometimes.

[PaulL]

The methodology we use is consistent with your needs, but it does require a license for the DSC Module. We flatten an object to a string and write the string to a networked shared variable. (We are only logging signals anyway.) The networked shared variable has logging enabled (only doable with the DSC Module) so that LabVIEW logs the string to the Citadel historical database. When we retrieve the data we have to cast the string to the correct class (easy enough).

Advantages:

NI maintains the shared variables--you don't have to develop a methodology yourself, and they are self-contained so you can separate them from your application.

Disadvantages:

The DSC Module isn't free. Shared variables, while very good, aren't perfect.

[Grampa_of_Oliva_n_Eden]

...

Disadvantages:

The DSC Module isn't free. Shared variables, while very good, aren't perfect.

Adding to that list...

Code is close so if there is a problem you can't get at it to fix it.

Required system resource are un-documented so managing DSC in a secure environment can be a nightmare.

Ben

[Daklu]

Can somebody advice how to organize logging approach? Any examples from your experience are appreciated.

Singleton and Observer aren't mutually exclusive. A class can be a singleton, a class can be an observer, or a class can be a singleton observer.

Lots of people implement loggers as singletons and are quite happy with them. Whether or not it works for you depends on your specific requirements. If you ever need to keep more than one log in your app then you'll have to implement a new singleton class for each log. (You could also change the singleton source code every time your logging requirements change, but I don't recommend that.)

If you need to dynamically change the logging at runtime (such as enable/disable logging certain events, logging events in more than one log file, or changing which file an event gets logged to) I'd consider using an observer.

The singleton is much easier to implement. The observer decouples the process from the logging, is much more flexible, and is more reusable.

Edited January 20, 2010 by Daklu

[dim_V]

Thank you, good point.

The main requirements are multi–level logging and ability to disable any module to be logged. I will try to implement observer, it’s going to be challenge to re invent well known pattern for LabView paradigm.

[Daklu]

The main requirements are multi–level logging and ability to disable any module to be logged. I will try to implement observer, it’s going to be challenge to re invent well known pattern for LabView paradigm.

Yeah, it can be tricky figuring out how to apply common patterns to Labview. Observer is particularly difficult because there's so many different ways to do it, each with advantages and disadvantages. The community as a whole hasn't settled on the best implementation. Most use queues to transfer information between the subject to the observer. I prefer to write the subject so that it exposes user events that observers can choose to register/unregister for on their own schedule. It requires more framework code, but I think it results in a more robust solution and better encapsulation. If you haven't worked with user events much they can be rather quirky.

Here's the topology I would start with:

This prevents your event logger from getting too tightly coupled to your modules and allows you to easily reuse it in other projects. The simpler implementation is to have the module manager receive events from the modules. When it receives an event that needs to be logged, it creates a log entry and sends that to the event logger. Any logic for deciding what and when to log is contained in the manager. The manager also maintains control over the modules, starting and stopping them as needed.

The more complicated implementation has the event logger registering for the events from each module directly. I really don't see any advantages to this though. If you're concerned with the module manager being overburdened it would be better to create an app specific log controller that makes the decisions on what to log.