Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

How to probe private data of actor when running?

Solved!
Go to solution

I'd like to debug the LabVIEW program when running actor framework. How can we probe private data of actor when running? Thanks.

0 Kudos
Message 1 of 31
(7,951 Views)

Hi,

I don't have a real solution, but can tell you what I would do:

AFW is a higly dynamic system; if you debug it you change its timing behaviour. And finally you could run into timeouts and other means to detect and prevent erroneous behaviour.

What I'd suggest is to (temporarily) add some logging to the actor in question that writes the interesting data into a file, that you can evaluate offline. Maybe you add a timestamp to each message. You also might consider to log from caller of your actor in question as well, but do not use the very same file. Either use different files to prevent the different logsources from blocking. Or create a single log-vi that accepts data by a queue of text - you can use the same queue in different vis than.

HTH!

--

LuI

0 Kudos
Message 2 of 31
(5,700 Views)
Solution
Accepted by topic author hmqi2002

You send a message periodically from actor core to the self enqueuer, that calls a method in its do method, which accesses the private data cluster. Like this you can poll the private data.

Alternativly you can send the same message from somewhere else.

Finally you can store a data reference to your data instead of the data itself. This has the effect, that you do not copy the data anymore since you copy references. This means that you can observe the data change while a message is executed and you get your information immediatly, without waiting until it is your turn in the queue. Then there is a garbage collector, which destroys your reference, when the creating vi is finished. In addition everybody, who has access to the reference can change the values. Due to this reason the last option ist really dirty and should never be used in productive environments. In addition you brake the object oriented programming paradigm principle of information hiding and you make the actor design pattern senseless, since you can communicate with your actor without using the priority queue.

0 Kudos
Message 3 of 31
(5,700 Views)

There's an "Open Actor Core front panel?" input on the Launch methods (though I think it doesn't work on RT).  If you can open Actor.lvlib:Actor Core.vi then you can probe the Actor object.

0 Kudos
Message 4 of 31
(5,700 Views)

Like this you can see only what happens before the AF actor core is started and after it has finished. After it has finished you cannot access the private data anymore (because it does not preserve the input class for good reason)

When you send a message to an actor the processing takes place while the AF actor core which is a parent method of your actor core is running.

0 Kudos
Message 5 of 31
(5,700 Views)

Ah, so that feature only opens to "outer" Actor Core.  

Does "Monitored Actors" allow the opening of Actor.lvlib:Actor Core.vi?   If not, one can make a message that will open the front panel of Actor.lvlib:Actor Core.vi, though it wont work in RT.   This involves using Call Chain to identify the full name, with clone number, of the running Actor.lvlib:Actor Core.vi, opening a reference to it by name, then opening the FP (or, better yet, the Block Diagram).  Then one can probe the Actor object.

0 Kudos
Message 6 of 31
(5,700 Views)

Yes if you mean by "outer" the framework override. The problem is, that the processing of the messages takes place within the Actor Framework actor core.

It doesn't help anything to find out which copy of actor core you call, since usually other methods than actor core modify the data of the actor class. Those methods are invoked by messages.

If one doesn't want to send a message to probe the actor core data it is also possible to override the "receive message" method. Like this you can probe the data every time a do - method is executed. This is even nicer than my first suggestion, since you do not have to poll. You can place an intermediate class it in the class iheritance tree in order to equip all actors with your probing override of "receive message".

The method which is called by the do.vi of a message should have a very short execution time, because it has to end bevore the next message can be received.

Monitored actor is a good tool to find out, if an actor is still alive or where in the tree it is. Thanks for this suggestion, I will use it!

0 Kudos
Message 7 of 31
(5,700 Views)

mthimm1 wrote:

It doesn't help anything to find out which copy of actor core you call, since usually other methods than actor core modify the data of the actor class. Those methods are invoked by messages.

Those messages are invoked only by Actor.lvlib:Actor Core, so one can put a probe after the "Do" and see the current state of the data. 

0 Kudos
Message 8 of 31
(5,700 Views)

Try Desktop Execution Trace Toolkit. Very powerful tool for seeing what is going on in Actors. See the link below for lots of details on how to use it. You just need to choose a method to drop it into, probably one that already accesses the private data and makes the changes you're interested in seeing.

https://decibel.ni.com/content/docs/DOC-44158

0 Kudos
Message 9 of 31
(5,700 Views)

drjdpowell schrieb:

mthimm1 wrote:

It doesn't help anything to find out which copy of actor core you call, since usually other methods than actor core modify the data of the actor class. Those methods are invoked by messages.

Those messages are invoked only by Actor.lvlib:Actor Core, so one can put a probe after the "Do" and see the current state of the data. 

In my opinion modifying the original Actor.lvlib:Actor Core is even worse than the use of data value references. You might want to preserve the original library in order to replace it by a newer version as drop in replacement.

There is no need to fork the AF. Receive message.vi is called everytime a message is executed. It is called exactly as often as do.vi.

Since "before a message" is almost everytime "after a message" you catch all interesting changes of your private data cluster.

0 Kudos
Message 10 of 31
(5,700 Views)