Best framework for an output window for event logging tracing and debugging

[mkratzok]

I am creating an output window for a large LabVIEW program with the hopes of:

• Minimizing the number of message/error dialogue windows so they are not disruptive
• Preserving errors and messages from the dialogues 
• Provide informative data to the support team so they can assess the issue
• Provide helpful information to the user if they can solve the issue on their own and not overwhelm them with unimportant messages
• Log diagnostic information about the internal state of the program (commands sent/received to/various places), wait events, timeout errors, log data, etc
• Debugging information for devs

I've attached an image of an example of what this diagnostic tool could look like. The drop down would have additional information about the message and clicking on it will bring the associated front panel to the foreground. Additionally there should be the option to right click on a message and copy them to the clipboard. Is something like this remotely possible in LabVIEW? 

I'm also attaching a screenshot of my first attempt/experiment for the output window using LLAMA. Errors are bold and colored red. Most of the errors/messages used by the program are held in a .xml file so the shorthand error name will be printed in the column where it says "REF" or "SHORTHAND HERE."  The message/error will print in the next column. I can use LLAMA to get additional information about the VI chain but that information does not need to be presented on the output window. But that would be good information for the other style of window.

My main questions are: 

1. Does anyone here have experience using LLAMA? Any advice/words of wisdom/warning would be greatly appreciated!
2. Would you recommend a different logging framework?  The end goal is to maximize performance and minimize issues. I looked into using Actors but decided to start off with LLAMA because it seems to be a good tool for the job.
3. Any advice on making a diagnostic window that has drop downs with extra info/other customizable features? It would be cool if the final product looked like the attached image but the most important thing is having a tool that works and works well.

Thanks so much for reading all of this! 

[cbutcher]

---

@mkratzok wrote:

I've attached an image of an example of what this diagnostic tool could look like. The drop down would have additional information about the message and clicking on it will bring the associated front panel to the foreground. Additionally there should be the option to right click on a message and copy them to the clipboard. Is something like this remotely possible in LabVIEW? 

---

Yes - it can be done. Whether it would be easier/faster to use an existing tool (like LLAMA) I don't know.

You can try using a Tree indicator/control to display your details - they handle indentation of items and collapse/expansion easily. They can also have different text colours for different cells.

However, their manipulation is a little fiddly. I created the image above manually at edit time - to do so programmatically (which of course you'd need) would require something like the following (although you'd probably want to Add Item at End or similar?).

To make this actually workable, you'd want to have some VIs that added an "Error" or "Information Entry" with all of the necessary fields so that your top-level(s) didn't need to handle any of these Invoke Node changes.

I haven't tried using it but you might consider taking a look at (even if only for inspiration) this toolkit for Trees: https://lavag.org/topic/10278-cr-tree-control-api/

[cbutcher]

Oh. As a side note - it appears the Child Position value is used for sorting multiple children of a node (this includes the top level).

So you can use it to manipulate if elements are added to the top or the bottom and so on.

I attached my test VI that you can play around with, backsaved to 2015 (originally created in 2019).

[Thomas_robertson]

My memory of Llama is that it's not based on actor framework (I believe they said that was done so as to not intimidate adopters, plus it was made several years ago when AF wasn't as popular), but, there's no reason it couldn't be wrapped in actor framework (run the llama engine or whatever they have in your actor core.vi), create AF messages for sending errors and information from your application to it which in turn result in Llama messages or whatever technology they use for that.   So, in that sense you don't have to decide between Llama or an Actor Framework solution.   In fact, the developers of Llama may appreciate a "Llama Actor" which could be distributed with the package if you felt like contributing back.

As for the GUI, if I'm not mistaken, Llama is extensible, so, if you wanted to make a Tree GUI as has been proposed here, I believe you could do so and just harvest the information from Llama to populate it.   That said, my concern about a Tree view is that it would make it very difficult to view events in the time domain.  For instance, if "Information" messages such as "DAQ init" "Daq channel start" "Daq read" "Daq close" are in one branch of the tree with timestamps, and an "Error" such as "DAQ Timeout" is in another branch of the tree, it wouldn't be obvious at a glance that the timeout occured immediately after DAQ read (vs say Daq start or a timeout when closing the channel).  It might be useful from an information overload perspective, but, switching to a time based view from a category based view would almost certainly be necessary, so, unless you want to develop multiple views I would be weary of this one.

[mkratzok]

---

@cbutcher wrote:

I attached my test VI that you can play around with, backsaved to 2015 (originally created in 2019).

---

This is a great framework for the structure that I am looking for, thank you! I'm working on implementing a similar setup in my VI right now. Out of curiosity what is the Edit Tree Items.Delete Invoke Node doing? The Front Panel seems to exhibit the same behavior regardless of the value of Delete Children.

Edit: Please disregard the above response... I was being stupid. 

[cbutcher]

The Delete node is simply clearing the entire tree. If you remove it in its entirety you'll get something that probably errors (I can't test right now) when you run repeatedly due to repeated tags, but of you wanted to create a (sub)VI that appended elements you wouldn't use it.

As was commented above, the Tree control/indicator certainly can be a little fiddly - but if you want the features it offers then it can be quite powerful.

Manipulation of the "Child Index" (in this case, always using 0) would allow you to put "new" events at the top in chronological order.

If you used All Errors and All Info as parent items, then you'd see the issue described (difficult to line up times perhaps) but I didn't get the impression that you wanted that (grouping by category).

If you build some sort of class that holds a model of all your events and can create a tree, then you can conceivably reformat or filter it as you want. I'd suggest that this might look somewhat like the VI I attached but with the array of clusters as an input control (so rebuild the tree with whatever subset you wanted, e.g. type = error).

Just to reiterate, it's not a trivial undertaking and there may already be frameworks or toolkits that can do part of the work for you (but I can't remember any immediately).

[drjdpowell]

The logger I use and wrote a few years ago is the Cyth SQLite Logger, available through VIPM.  Intended to work with async "launched" actor-style things (I use it with Messenger Library actors but it should work with AF Actors I think).