I am using NI's Actor Framework in combination with the Delacor User Event Lib.
My project worked fine so far, with 1 actor and 2 separate nested actors.
I added a third actor that is supposed to handle the dynamic events from the Delacor User Lib.
No this is what happens:
The new nested actor starts and code inside its Pre Launch Init.vi is executed fine. The Core starts running and its event structure reacts to the dynamic events triggered, sending messages to the actor Queue.
But the corresponding methods are not executed.
But as soon as I Stop the calling actor "Error 43 occurred at Stop Msg:Do.vi" pops up and all the methods previously triggered execute.
How can I detect where my actor is stuck or why the messages queued in, are not being handled?
Hope everything is clear.
Thank you for the help
Solved! Go to Solution.
Are you relatively new to AF? If you're new, maybe check inside Actor Core.vi to see how you placed the helper loop (event handler) and how you placed the Call Parent Method. It sounds like maybe your event handler is running first, then the parent method (message handler) is running after. Probably they should be running in parallel.
Anyway, for debugging where it gets stuck, you want to make the problem Actor Core.vi display when running. Then you can Show Block Diagram and debugging is pretty normal from there.
This is my nested actor, quite simple. I already debugged until here. The events are being handled. But "switchOn.vi" is not executed until I stop the actor.
I am unable to debug "Send switchOn.vi" or its "Do.vi", since they are reentrant.
You almost never need to live debug Send or Do vi's, as Send just enqueues a message, and Do just calls the method for whatever you're doing. As long as they're wired up right you should be fine. The method itself can be made non-reentrant so you can debug it just fine.
Also, you *can* debug reentrant VI's, but it's not super obvious. Once the reentrant vi is in memory (as in you've called it at least once), open the main vi instance, then click View, Browse relationships, Reentrant items, and you will see a list of the reentrant clones of the original vi.
All that said, if you made Send and Do via the auto-generator and haven't modified them, and switchOn isn't executing, then that means one of a few things. Either:
1- the Actor Core that receives the user event isn't firing the user event (meaning Send isn't being executed), or
2- the Actor that receives the message is stuck doing something else.
I can only debug a picture of code so much, but it looks like you're sending the switchOn message to the same actor that handles the user events (that looks like Read Self Enqueuer, not Read Caller, but it's hard to tell).
If I had to guess, either your Send got messed up (make sure all wires are connected and nothing unwired is defaulting to empty enqueuers or something), or some method that is called earlier is not allowing Actor Core to continue executing.
One option would be to try making a new message that just opens a popup or something. Try sending *that* message. If that message fails, then Actor Core is broken. If that message succeeds, then something with your switchOn message is broken.
Last: I've found the MGI Monitored Actor toolkit to be extremely helpful when debugging actors. You just make your top level actors inherit from Monitored Actor instead of Actor, and now you get to see all of the things coming and going to each Actor. It's available on VIPM and it's free. Like all of MGI's stuff it's super useful.
Thanks for the help.
It was your second guess, the Actor that receives the message is stuck doing something else.
One of the methods in the Pre Launch Init re-called itself creating a loop.
But I am still wondering how I can detect something. With the QMH I could simply monitor the queue size f.e.
I will have to check out MGI Monitored Actor toolkit.
p.s. The image I uploaded hat perfect quality, have you tried looking at it in full screen mode?
Anyway thanks for the help. And the trick with debuggin reentrant VIs. This is totally new to me.
Glad you got it sorted.
Re: your other points: The Monitored Actor toolkit will give you info on the Actor's queue and I think you can see individual messages with it. It's a bit different from a normal queue though since the message queue is object based, so "viewing" a message isn't as easy as it is with a string-based queue.
About the image, I could see the image just fine, I just couldn't see Pre-launch init, or what was going on in any methods, what upstream actors were doing, or what any methods were trying to do.