Actor Framework Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

AF 4.1 for LV 2012 vi.lib DEBUG FORK

This package installs a DEBUG AF 4.1 for LV 2012 and later into vi.lib. For LV 2013, please check out Monitored Actors.

This is the same version of the AF that released with LV 2012 with one performance improvement and one new method ("Substitute Actor.vi"). It is fully backward compatible with version 4.0.

This version installs into vi.lib. Uninstalling will restore the original AF that shipped with LabVIEW.

This is the DEBUG FORK. That means this is a modified version of the MAIN FORK with modifications to support attaching a debugger that can track events in the actor framework and inject behaviors into actors.

Details about this debugger:

How to use the Actor Framework Debugger and How To Modify the Debugger For Your Tastes

Installing this package will modify your vi.lib\ActorFramework directory. Some of the VIs installed with LabVIEW will be modified.

Uninstalling this package will PUT EVERYTHING BACK THE WAY IT WAS.

The ability to debug the actor framework requires editing the framework VIs so that they expose hooks that the debugger can use to report details about what is going on in the system. Normally we advise against modifying vi.lib VIs. In this case, you are deliberately modifying the VIs temporarily while you do debugging and then reverting the changes out when you uninstall this package so you go back to the release version of the framework.

To use the debugger:

1) Install the package.

2) In the same app instance as your project, open this VI:

     <vilib>\ActorFramework\DEBUG\DEBUG Actor\Launch Debug Actor.vi

3) Modify the path in the path control to point to this LV class:

     <vilib>\ActorFramework\DEBUG\AQ AF Debug Logger\AQ AF Debug Logger.lvclass

(If you have created your own debugger, pick the path to that class instead.)

4) Run the "Launch Debug Actor.vi".

You can start your actor project running before OR after launching the debugger. You can stop the debugger and restart it without shutting down your project. You can stop your project and restart it without shutting down the debugger.

The debugger that I provided at this time is named "AQ AF Debug Logger.lvclass". This debugger provides a log of events as they occur (actor launched, message sent, etc). I hope that in the future we have a graphical depiction of the actor tree and the messages as they pass among the actors. Anyone in the community want to tackle this? 😉

The deubgger also provides a way to abort all the actors. Currently it pops open the front panel so you can hit the Abort button manually. Why? Because calling the Abort VI method is, for some unknown reason, returning an error to me. I do not understand and I am trying to get info about that from Those Who Know Things on the LV R&D team.

The debugger is itself an Actor. That means that if you want to create your own debugger, you use the same skills that you use for extending any actor. Your debugger class should inherit from "DEBUG Actor.lvclass". Override the methods as you see fit. You may create message classes that your debugger class will send to itself using the message maker as normal.

If you want to instrument some portion of the AF that is not currently instrumented, you need to create a regular message class using the message maker and then make the following modifications:

1) Make the message class inherit from "DEBUG Message.lvclass"

2) Modify the block diagram of the Send VI to look just like the diagram of "Send Actor Launched.vi".

If you are interested in how the instrumentation was done...

1) Any VIs or classes that I added to the framework itself are named "DEBUG *.vi".

2) Any modifications that I made to the diagram of existing VIs are surrounded with sequence structures painted orange and have a comment with the word "DEBUG" by itself inside the structure.

I hope this helps your AF experience. And I hope others in the community are motivated to take this as a starting point and improve it. Post modifications to the community forum and if they're good improvements, I'll absorb them into the "official" version available on the READ THIS FIRST page.

-- Aristos Queue

August 2012

Comments
Intaris
Proven Zealot Proven Zealot
Proven Zealot
on

"If you want to instrument some portion" and "If you are interested in how the instrumentation was done." is using the word "instrument" in a way I'm not familiar with.  What does this mean exactly?

Active Participant
Active Participant
on

http://dictionary.reference.com/browse/instrument?s=t

verb (used with object)

8.     to equip with instruments, as a machine or manufacturing process: to instrument a space vehicle.

                   
AristosQueue
Proven Zealot
Proven Zealot
on

Intaris: In this context, it is debugging code by modifying the code, essentially adding sensors and alarms throughout. The preference for debugging is to be able to do all detection from the outside so that the code is exactly the same code that will be deployed, since the addition of sensors/alarms always runs the risk of breaking one of the systems under test, but often you have to actually modify the structure to get more information out of the core. Here I have modified the AF to make it fire events at various points to an attached debugger, events that it would not normally report to the outside world.

LVB
Active Participant
Active Participant
on

What was the design decision to use numbers for messages and actors rather than the name and clone number?

CLA, CTA
AristosQueue
Proven Zealot
Proven Zealot
on

I wanted to introduce a unique ID since I figured there would be lots of database-like indexing and cross-referencing when trying to generate complex graphs of messages. It's a lot simpler and faster to just compare integers, and you only really need the strings when you translate to a UI. Also the numbers give a sequence ordering, which made it a lot simpler when I was debugging the debugger. 🙂

LVB
Active Participant
Active Participant
on

The log window only shows IDs (Unless the Actor Name on the Launch Actor VI is wired).  How would you suggest correlating the message names and actor names to their IDs?

CLA, CTA
AristosQueue
Proven Zealot
Proven Zealot
on

In the existing debug plug-in actor? Scroll up and find the matching number. 🙂

Eventually, each debug plug-in actor would be maintaining its own lookup table, which it sets when the message is sent and clears when the message is received (or possibly not if it wants to maintain more of a database structure with alternate views). It's entirely up to the particular of the debug plug-in actor that you write how to do that storage. Creating a library of common functionality for writing debuggers -- like backing them with a MySQL database or a simple LV2-Style global look up table -- seems like a good idea to me.

Active Participant
Active Participant
on

It would be very nice if you (or anyone with the time and inclination) would pick a standard mechanism for this and create a class that handles registration and notifications with a simple API so all we'd have to do is instantiate that object in our project and call into those one or two API functions from each of our actors.

AristosQueue
Proven Zealot
Proven Zealot
on

> It would be very nice if you (or anyone with the

> time and inclination) would pick a standard mechanism

As I said, "Creating a library of common functionality for writing debuggers -- like backing them with a MySQL database or a simple LV2-Style global look up table -- seems like a good idea to me."

This is a community project. If someone has time, they will. If someone has need, they will. Hopefully, that someone will choose to share it with everyone else.

Sleepy_Engineer
Member
Member
on

Where would be the best place to post the code for a plug-in debugger/logger I've thrown together?

My idea was that, as the actors are running, the debugger log is displayed as if it were a live Sequence Diagram, an idea that I started to dream up during my 1-on-1 with Darren at the Architects Summit. Essentially, it just makes it easier to see who launched who, and where your messages are being sent to. I've started playing around with things like clicking on the messages taking you to the message VI, and color options so you can easily focus on the messages you care about. This isn't as scaleable as the default logger, but for all of the small projects I do I think it will work great. It also helps that I have a lot of screen real-estate at work so I can just have it open on my second monitor.... so, I guess what I'm trying to say is that this certainly isn't for everyone, but I did want to share for those that are interested. I made a new "Measurement System.lvproj" from the project templates and it seemed to work pretty well with that:

AF Sequence Diagram Logger.jpg

You can see from the image that it is essentially just an MCL that has been adapted to show the lifelines of the Actors as they are spawned and stopped. I couldn't figure out how to get the message names using the DEBUG Actor.lvlib as it stands, so I had to modify the "DEBUG Write ID" method of the Message class to put my LV2 style global in and then the "Enqueue" and "Enqueue Critical" methods of the Mesage Enqueuer class to get the message names. If there is a better way to tie into the DEBUG fork without changing anything in the DEBUG Actor.lvlib I would love to know it!

DEBUG Write ID.jpg

Enqueue.jpg

Besides that, In order to work properly, the actors all need to be named. I changed the “Actor Name” input of the Actor Framework.lvlib/Actor.lvclass/Launch Actor.vi to be required so that I was forced to give names to all of the actors. This will keep the "Sequence Diagram" Lifelines understandable and working properly.

-Carl Wecker

Active Participant
Active Participant
on

Neat tool, but I see that it depends on Yet Another Branch Of The Actor Framework...*sigh*

I imagine you'l want to make a new document and label it an "EXPERIMENTAL FORK" of v4.1. Edit the main document to link to it.

Sleepy_Engineer
Member
Member
on

OK, initially I couldn't figure out how to access the "Call Chain" data that was being bundled into the message data (as seen in the right part of the last image from my previous post)... but now that I looked a little closer I realize that I was foolish and the call chain data is available in the Do.vi of the Message Sent Msg.lvclass. It should have been obvious, but I am going to blame it on me being fairly new to OO (: What this means is that it will not depend on Yet Another Branch, but should be able to work with the DEBUG fork as it stands! Yeah! I will get it fixed up and post it hopefully later this week!

All you will need to do is have the DEBUG launcher launch my Sequence Diagram Logger instead of the AQ AF Debug Logger!

-Carl

LVB
Active Participant
Active Participant
on

Thanks for sharing your work.  I have been using PlantUML (suggested by Staab) for sequence diagrams.  PlantUML generates UML diagrams (PNG format) from text files.  I was thinking about attempting to make a debug actor that would generate PlantUML compatible text files (in my spare time).  This may be a good addition to your tool.

CLA, CTA
Active Participant
Active Participant
on

LVB wrote:

                       

I was thinking about attempting to make a debug actor that would generate PlantUML compatible text files (in my spare time).

I think you mentioned that before. I still use PlantUML for sequence diagrams, though its class diagrams are too unruly to be legible most of the time. I'm so interested in the idea of automated "Messaging Diagram" (Sequence Diagram) generation that I'd like to help you with the project in my own spare time. PM me to see how we can collaborate?

Sleepy_Engineer
Member
Member
on

I started the document AF Sequence Diagram Logger

Please let me know if it works and what you think

It is a little prettier than the images above and has options to change message colors, ignore messages and open any of the VI's on the call chain for the message, all from the right-click menu.

It is a little slow but it works fine if you don't have auto-repeating messages or after you choose to ignore those messages.

And it works with the current Debugger Fork, so no need to change anything that you already have.

-Carl

Sleepy_Engineer
Member
Member
on

One of the big drawbacks to the design is that it doesn't have arrows going to the message recipient like a real Sequence Diagram would... I thought about doing some big picture box, but that sounded to overwhelming for the time I had set aside to program up the thing and I wasn't sure in the end if I could even get it working!

-Carl

Oli_Wachno
Active Participant Active Participant
Active Participant
on

Has anyone else experienced problems installing this package?

VIPM throws the following error at me:

error.png

The zip file has been created

Cheers

Oli

Join the Community!

GCentral
Oli_Wachno
Active Participant Active Participant
Active Participant
on

Seems to be working now: had to uninstall v4.1.1.34 first.

Join the Community!

GCentral
Contributors