LabVIEW and re-running an Actor-Framework app

[skol45uk]

Hi

Anyone got any experience of this kind of problem. Its probably simple but I am unable to see what the problem is....

I have written a simple AF application (Main, 1 x Root, 1 x Nested)

When I open LabVIEW, Load my project, and Run the Main.vi, the app works fine.

I stop it, and I can see that all actors have stopped because all the locks are extinguished in the project view.

When I try to run it again (right-click Main.vi > Run), the Root actor runs, but the nested actor has something wrong with it.

If I shut down the LabVIEW environment, and reload the project, it works again.

Some memory from one execution to the next is inducing problems.

As I have not used AF for long, such nuances of behavior are beyond me. Is this normal?! Is it my code or the AF code?

What might I not be doing in terms of cleanup when the app stops?

Thanks

[BertMcMahan · Accepted solution]

A couple things come to mind. It's usually an issue with reentrant clones when this kind of thing has happened to me. It's usually not an issue with the AF itself.

1- Uninitialized shift registers have their data persist across starts/stops, so if you're storing state info you have to manually initialize it (note that this is an issue if you launch multiple actors as well, so you should always manually initialize all internal states)

2- First Call? primitives work a little weird with reentrant clones. Every time I've tried to use one in AF I've regretted it and wound up with extremely annoying bugs. I've always had to remove it and manually initialize my states.

Without seeing your code that's the best my magic 8-ball can do.

[skol45uk]

Thanks very much for your reply. It helped a lot. Just by giving me confidence in AF not being the cause.

I did a "Reinitialise to Default" at the start of ActorCore.vi of the nested actor. Don't really know WHY this seems to have worked, but its a big step for me.

Thanks.

[BertMcMahan]

Glad it's working. Do you have any uninitialized shift registers in Actor Core? Any unwired terminals? If you post your code we could take a look at it.

One thing that's easy to gloss over is the fact that Actor Core is a Shared Clone. Most VI's are non-reentrant by default, so changing it to reentrant is usually intentional. When you create the Actor Core override it auto-sets that function. When you call the same VI multiple times (to create copies of the same actor) you could wind up sharing data between each of the clones inadvertently. Manual initialization fixes all of that.

[Jonzarwal]

Just to understand better what was going on, maybe you should add a simple error handler on the error in of the parent method actor core of your nested actor.

To me, at your second execution, there is an error on this wire and your actor doesn't start properly. If true, an error will pop and you will find out where it comes from. Remove the simple error handler when you're finished with debugging.