Libraries locked after running

[Drew.Rankin]

OK. So another dead thread, but I tried exposing all the actors as they were launched as suggested and they all close when I exit the application. However, the AF associated libraries are all locked and there are a bunch of messages lingering in the system.

I have two actors (both DAQmx) on delayed messaging successfully closing down; however, a third actor that is talking to a serial port (simulated for now) that is not closing down properly and is hanging everything up. Not sure how to proceed, I have the stop actor overrides programmed the same way for all the delayed messaging actors. I even tried detroying the notifier in the stop actor override, but that hasn't seemed to help either. Checked out the AF template build Alpha actor and I have copied everything - well copy isn't really the word, but it's close - as it is there.

Kind of bummed, as I have been trying to hack my way through this all afternoon. Would really like to get this put to bed.

I have put the project on my public DB at (PM sent)

This is the project I have spoken about in other discussions.

Thanks,

Drew

[Drew.Rankin]

Well, after a while longer, I have a working project. I ended up using the Beta Actor method of timed updates to my serial interface actors. Still not sure why this is necessary to do. It is not as clean as the Delayed Send messages. I would still appreciate any feedback.

Thanks,
Drew

[User002]

Drew,

Not sure what help it is as you seem to have been quite thorough in your investigation.  You must be the 1%, as I fell into the 99% of AQ's "Actor Left Running" group.  I found mine using the application instance and looking through running .vis at their callers.  You might try looping through .vis in memory and looking at their run state and call chain.

Marty

[AristosQueue (NI)]

fairlyFunctional wrote:

Not sure what help it is as you seem to have been quite thorough in your investigation.  You must be the 1%, as I fell into the 99% of AQ's "Actor Left Running" group.  I found mine using the application instance and looking through running .vis at their callers.  You might try looping through .vis in memory and looking at their run state and call chain.

Unfortunately, "VIs in memory" won't give you the clone VIs, only the real VIs. Which means you won't find any top-level VIs if the problem is an actor left running.

Drew: Were you remembering to stop the "Send Delayed Messages" VI in your Stop Core.vi? That would definitely account for the hang. (Basically, when you start a delayed message, the output is a Notifier that you can use to abort the delay... you need to fire that notifier either in your Stop Core or at the end of your Actor Core [be sure to do it even if there's an error on the error wire]).

Also, I should mention... one of the most common reasons for things not stoping is that your stop messages are fired in Actor Core and you've used the error wire to serialize them. When an error occurs, the firing of the stop signals won't happen. Use a flat sequence structure instead of the error wire to do the serialization.

[Drew.Rankin]

Yes, the Stop Core sends the Stop all further messages.

Good on the serialization. Not sure right at the moment, it's been a while since I had a look, but I will check that out. I do know that I am checking for errors on the message calls, I know that some are serialized, some are not. Most of the time, I don't really care if the messages are handled sequentially, but sometime it does matter. I will have a look for sure.

Thanks!!

Drew

Message was edited by: Drew.Rankin -- Where's the KUDOS button???

[elset191]

I'm not 100% sure, and this is certainly anecdotal, but I think in the past I tracked this down to the Time-Delayed Send Message.  If I copy and pasted that VI to start multiple timed messages I got the actors staying locked problem.  If I dropped a fresh one from Quick Drop my actors did not hang.  Again, purely anecdotal, and it was a while ago so I can not confirm that's what happened.  It doesn't make any sense to me why it would do that (if it even did)

Today I ran into the actors staying locked in one of my projects and it indeed turned out to one of them not actually stopping.  Showing the actors saved me on that one.