Jump to content

Logging in LVOOP projects


Recommended Posts

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.

Link to comment

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.

Link to comment

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 by Daklu
Link to comment

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:

post-7603-126416767338_thumb.png

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.