Problem with Async VI Agent.vi staying alive

[davidc10]

I'm having a problem when using the Wait function from the Interrupt palatte.

The problem seems related to the Async VI Agent.vi staying alive when the calling VI goes idle.

I've attached a small VI to demonstrate the problem.

The same type of problem has occurred when I have run projects based on some of the example code - and the only work around I've found is to use an Abort Invoke Node on Async VI Agent.vi when my top level VI closes. (But this required changing the library scope of Async VI Agent.vi from Private to Public, which is not an acceptable fix.)

Thanks,
David

[Greg McKaskle]

Interesting. The purpose of the Asynch VI Agent is to own the FPGA Ref and any other appropriate shared I/O refs so that modifications to the framework that result in the first I/O being called from a dynamically loaded piece will not define the lifespan of the refnum.

The Asynch Agent explicitly inspects the state of the RobotMain VI and keeps the refnums alive until that VI goes idle. The some additional cleanup code was later added to the agent.

Can you clarify if you see the agent stay active when the RobotMain is idle? Can you open the agent and probe the VI name whose state it is polling? If this is not RobotMain, but winds up being another VI, that would be the thing to fix.

If you feel you need to send me stuff, send a PM and I'll give you contact info.
Greg McKaskle

[davidc10]

Greg,

I think I see it now. Async VI Agent.vi dies when the top caller of Start Communications.vi goes idle. (When you said it was tied to Robot Main.vi I looked a little deeper).

Now, if you look at the small example I attached yesterday, you'll see that I don't call Start Communication.vi; but the way Start Async Agent.vi is written, Start Communication.vi itself gets passed as the top caller - even though it isn't even in memory.

So if Async VI Agent.vi is waiting for the top caller to go idle - Start Communication.vi in this case - that's not going to happen. Since it was never loaded it's exec state is going to be "Bad", not "Idle", and Async VI Agent.vi doesn't terminate.

Often when we would re-work some of the FRC examples we would remove the Communications VIs since we weren't using them. That is why this problem has occurred before, but never in a full robot project.

Having Async VI Agent.vi bound in this way seems to impact the modularity a bit, but now that I'm aware of it I can work around it.

Going further though: most of the examples I have run without the Comm. VIs do not throw an error even when re-started many times, (with Async VI Agent continuing to run between re-starts). But if the code includes the WaitOnInterrupt.vi then there is an error - on the 3rd re-start in my example.

So I still don't know if there's a problem with WaitOnInterrupt.vi, but I will dig a little deeper.

Regards,
David

[Greg McKaskle]

I left out the info about how it determines what is the top VI. As you noticed, since only one Start Comms is really allowed in a working app, that was selected as the element to use to ID the main hierarchy. As you noted, the FPGA ref can stay alive and be shared amongst many hierarchies, even ones that start and restart. We also noticed that interrupts act up on the third use and were not able to get to the bottom of it last year. We believe it is likely a deeper bug in the RIO driver.

Greg McKaskle

[davidc10]

OK. Thanks again, David