Debugging Actors

[drjdpowell]

AristosQueue wrote:

The clones were never intended to have additional references. If you were to release the reference to the real VI while still holding references to the clones, such that the real VI feels free to unload from memory, it will take the clones with it, and leave stale pointers in the secondary references that are opened. LabVIEW fall down and go boom. It is likely ok in the AF situation because we never give the real VI permission to leave memory while any actor is still in play, but I'm not confident of that, and, honestly, the architects who created clone VIs were so disturbed by my showing them that the open-by-name trick works, I can't rule out there being some other effect, so I'm loathe to rest a tool of AF on that trick. Fixing that crash would require significant refactoring of the clone VIs and almost certainly put some performance penalties on some parts of the operation of clones (can you return a clone to the clone pool when its first reference is released but there are secondary references still open?). Moreover, I don't remember how you figured out which clone numbers to try in your tool, since there's no way to get a list of the clone IDs that are currently in use, so I really had shied away from investigating further... I was assuming that you were instrumenting Actor.vi, which, as I've mentioned, I've been avoiding thus far (though I'm coming to the conclusion that is what we're going to have to do).

If we do instrument Actor.vi, we should be able to use the "This VI" primitive on the block diagram of that VI to get the first clone VI refnum, which means we would not be creating any additional clone references, and then register that with a central debugger.  So, when I said above that I wasn't sure how to make this work, that was mostly because I couldn't do it without instrumenting Actor.vi.

I used "Call Chain" to get the full clone names of the "Actor.vi" and various "Actor Core.vi" clones, publishing this info in a named notifier (whose lifetime is tied to the life of the actor that created it).  I worked with these names as strings, and created references on demand (closing them afterwards) when I needed to do something like open a front panel of one of them.  I don't keep the references open when not in use.  There is a possibility of the clone disappearing between the time I open a reference and actually use it; I might investigate what happens with that if I get the chance.

[AristosQueue (NI)]

drjdpowell wrote:

I might investigate what happens with that if I get the chance.

I already did --- LabVIEW crashed about half the time.

[Q7]

Glad to see all these great suggestions. I have a simple one that would help out a great deal IMO:

Some way to right-click or shortcut on a Send Message or  Do.vi & automatically do any/all of the following:

1. Go to the owning class in the project window
2. Open all class VIs. Good for all LVOOP.
3. Show the sub-vi's for the Do.vi when only the send.vi is open. This would be fantastic.
4. Show all Actors which use this message class or show the classes of those actors.

I have the most trouble debugging when I have to chase my sendmessage VIs. I also fear the day a colleague dives into my 740 VI and counting AF project. At least I wont see them for a month or two afterwards

[AlexAAuck]

Was wondering if anyone had any suggestions for debugging actors running on a real-time computer? Putting a FP.Open = True property node doesn't do anything. At the moment I can't even tell if any of the actors are running?

[CaseyLamers1]

I would like a sequence diagram generated for messages during certain running conditions.  I've been working with niACS on an RT project and it gets complicated quickly.  Messages to self, messages to caller, messages to another actor, message whose method is to send another message.  It is difficult to trace the paths and make sure that you have proper routing.

[David_Staab]

Try using the Real-Time Execution Trace Toolkit (RETT) in the same manner as the DETT is used for normal AF debugging, or implement your own event logger. You'll have to use traces/events to infer the bugs because there's no way to directly watch a reentrant VI on RT.

Where possible, try using this development process:

1. develop your functional class (e.g. Temperature Controller) and test it in isolation on Windows to validate core functionality
2. wrap an Actor and associated messages around the class and test it again on Windows to validate messaging behaviors
3. deploy it to RT and run it with event tracing to validate that it still works on that target

LV  needs to add a lot of new features and tools in the coming versions if AF is going to become as easy to develop/debug as a classical QDSM, especially on LVRT.

[AlexAAuck]

Yeah, that sounds like a good tool, except in typical fashion NI want $1500 NZ for it.

[AristosQueue (NI) · Accepted solution]

AlexAAuck: Try this out:

https://forums.ni.com/t5/Actor-Framework-Documents/AF-4-1-for-LV-2012-vi-lib-DEBUG-FORK/ta-p/3505169

There's no reason it shouldn't work on RT just as it does on desktop, although you may want to change it to write to a log on disk instead of writing to a panel. And I'm giving it away for free. 🙂

[reidl]

Since there were several mentions in this thread about DETT, I'd like to recommend trying the DETT 2013 beta.  There was significant work done to redesign the UI and eliminate out-of-memory issues.

Updated User Interface

• Introduce software ribbon to replace previous toolbars and menus
• Fix mouse-wheel bugs

Enhanced Capability to Trace Large Application

• Allows configuration of message limits and out of limit options to prevent out of memory issues that existed in previous DETT versions.
• Allows log data to file when tracing
• Enhance capture settings capability. You can now specify DETT to include/exclude VIs when capturing data.

Usability

• Search bar(Crtl+F) allows searching all text fields in your trace
• Navigation traces to a VI or any VIs in the call chain

New Features

• Adds compare traces dialog. Allows you to diff between two trace sessions
• Adds bookmark to trace line number when starting or resuming tracing

[AristosQueue (NI)]

If you look at the announcement of the beta here...

...you might notice that a screenshot of the new beta is clearly tracing Actor Framework VIs. Apparently someone was thinking about AF use cases! I had no idea a new version was imminent until today! Woohoo!