Unable to restart VI on target using VI Server.

[Christiana]

I am able to run a application on a target (cFP-2010) using vi server. I am unable to restart the application without rebooting the target. I have used the Real Time System Manager to monitor the VIs. The execution state of the main VI changes from "top level" to "bad" when the VI stops. I have tried placing my VIs in a library on the target as well as building an application targeted to the cFP-2010. Both methods result in a single good execution on the target, then the VIs status changing from "top level" to "bad". I would like to be able to restart the application on the target from a laptop via VI Server without having to reboot the cFP-2010. Any suggestions or ideas why this is happening? If you need more info
rmation, just ask.

[Greg G.]

That's really, really strange. I've never heard of a VI going into the "bad" state like that. But here's one idea for a workaround: Try completely closing the VI after the first run and making sure it is no longer in memory. Then load it again. Perhaps that will put it back into a runnable state.

[aasenjo]

grenoble,

This sounds like something we might want to take a look at. The only way I can think this would happen would be if a subVI of the application was reserved for running (or running) even after your application finishes execution. This could happen if:

- One of your SubVIs was also called dynamically and somehow was kept running after the application is done.

- You were sharing subVIs with some other VI running on the system. This is similar to the point above but means that if your application launches another VI, then quits, the second application in turn dynamically calls another VI which shares a SubVI with the first one. This is the only way I have been able to reproduce the behavior.

It could be something else, but let me know if this
raises any red flags for you.

I attach a sample LLB that should show the behavior even when running on the host:

- Open all three VIs
- Run Top Level.VI
- Hit the Stop button in SubVI.VI
- After the 2 second wait in Top Level 2.VI, Top Level.VI should show a broken arrow.

On the target, the Real-Rime System Manager is a great tool that should help you see debug this behavior. Make sure you show SubVIs in the VI list (Disable the Show Top Level VIs Only)

Let me know if this helps,

Alejandro

[Christiana]

I took a look at your example. It demonstrates the problem you are suggesting well. The top level target vi called mainRT.vi waits for all the sub VIs to stop executing before it quits. Today, I ran the host (vi running on the laptop) and the client (vi running on the cFP target) both on the laptop to see if I would still see this behavior. They ran great. I could always restart the client. This behavior only happens when I run the client vi on the cFP target. Copies of my host and target vis can be found at ftp://ftp.ni.com/incoming/
The host library is named "7061777 main host.llb". The top level VI is main host.vi. The client library is named "7061777 mainRT01.llb". The top level VI is mainRT.vi. I had the local NI rep come today and look at
it. He has someone working on the problem but I do not have a support reference number yet. The reference number used to name the files on the FTP site was for another issue.

[aasenjo]

grenoble,

I took a look at the VIS. They are not narrowed down and setup itself would take me a while to get it to run on a target over here, but here is what I can suggest by looking at them.

- If you have your application setup as a Start-up Application, then the controller will load it when it first boots up (unless you have disabled this). This might cause problems once you try to close your reference to the VI. Play around with the startup settings (don't load it at startup) to see the results. Based on the way the host is setup I don't think you need to load the application at start-up.

- Try to make sure you close the reference to LabVIEW that you open in the host VI before you try to run it again.

- Use the Real-Time System Manager to monitor the state of the subVIs, one of those VIs will probably change its state after the VI executes, all parent VIs will change with it, but other subVIs should not be affected. THis can hint at least what VI the issue comes from.

Make sure support follows up on this one by providing a smaller piece of code that they can replicate the issue with, this will save everyone time. The initial tests would be to have a mock-up of your application, with just the general structure and seeing if you get the same effect.

It's not much but it's all I can think of right now, let me know if you find anything else.

Alejandro

[Christiana]

---

@grenoble wrote:
I am able to run a application on a target (cFP-2010) using vi server. I am unable to restart the application without rebooting the target. I have used the Real Time System Manager to monitor the VIs. The execution state of the main VI changes from "top level" to "bad" when the VI stops. I have tried placing my VIs in a library on the target as well as building an application targeted to the cFP-2010. Both methods result in a single good execution on the target, then the VIs status changing from "top level" to "bad". I would like to be able to restart the application on the target from a laptop via VI Server without having to reboot the cFP-2010. Any suggestions or ideas why this is happening? If you need more info
rmation, just ask.

---

Follow Up
To fix the vi restart issue, I had to keep main.vi in memory after it was finished executing. I did this with a state machine. The state machine runs in the WAIT state and monitors a bit named GO. The GO bit is toggled using VI server between a laptop and the cFP CPU. When GO is false, the state does not change. When GO is TRUE, the state changes to the RUN state. The RUN state contains all of the code to run the system. When the code is finished executing, the next state is WAIT where it monitors the GO bit again.

Thanks NI for your help.