LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Determine Deployment Status / Progress Programmatically

Greetings,
 
My goal is to programmatically deploy a vi to a compactRIO target as well as reboot the controller.  While I have been experimenting with using the Library.DeployLibrary method call, I would also like to show the user the status of the deployment (similar to the Deployment Status window that appears when one deploys a library from within the Project Explorer - showing a status indicator and what files are being uploaded).  I seem to be having issues with trying to deploy a library containing only a vi but that may be the subject of another post on this board.
 
I am using LabVIEW 8.01 and Windows XP Pro.
 
Can anyone point me in the direction of being able to show this status programmatically or if it is even possible?
 
Thanks
 
- Con
 
 
Message 1 of 7
(3,973 Views)
Con-

I am a bit confused about what you are trying to do. Do you want to programmatically deploy a host VI to your cRIO or are are you trying to programmatically deploy a library of shared variables? The DeployLibrary is used to deploy shared variables.

As for reading the status of deployment when using the Deploy Library VI, there is no way to get a step by step confirmation while that VI is executing.

Xaq
0 Kudos
Message 2 of 7
(3,940 Views)

I am trying to have an application that will allow a user to deploy a vi to the cRIO.

Here's whats going on...

I have multiple cRIO boxes that I am monitoring and controlling via one main application.  To do that I have the main application bring up which cRIO's that are actually on the network at that time, then allow the user to open a remote panel to an individual cRIO vi so the user can change/start/stop the cRIO vi.  In some situations after closing that remote panel and trying to open it again, an error message appears stating that the cRIO vi is no longer in memory on the cRIO device.  One way to get it in memory again is to actually deploy from the Project explorer back onto that cRIO.  In development this is tolerable, yet while in actual use, the user will only have access to the main application and not the LabVIEW development environment. So one approach I had thought of was to place the vi in a Library, then use the Deploy.Library method to allow this deployment programmatically.

Any ideas on 1) how to keep that vi "in memory" on the cRIO device or 2) being able to deploy a vi to a cRIO or 3) some other way to do this?

I would ultimately want the user to be able to deploy files, reboot the cRIO, programmatically.

- Con

0 Kudos
Message 3 of 7
(3,931 Views)
Con-

I beleive I understand what you are trying to do now. Lets tackle each problem in order.

1) How to keep VI in memory on teh cRIO. Most likely what is happening here is that you are terminating the program on teh cRIO itself (wither by ending the main control loop or calling quit labview, etc). The VI is not being erased from the flash memory on board, just getting stopped from running. To start the Vi again, you can reset the cRIO (as long as the VI in question is your startup VI).

2) Deploying a VI to teh cRIO. Currently there are only 2 ways to do this. The first, is from the project explorer like you are used to doing. The second, which can be done programmatically assuming you have the internet toolkit or through a command line interface, is to FTP the VI to the cRIO.

3) Rebooting the cRIO programmatically. You can use the RT Reboot Controller VI, located in Real-Time VIs»Real-Time Utilities>>RT Reboot Controller.vi) to reboot a controller over the network (or reboot itself by using localhost).
0 Kudos
Message 4 of 7
(3,914 Views)

Thanks for getting back with a response Xaq!  Let me comment and see if there are some further suggestions.

Xaq wrote:
Con-

I beleive I understand what you are trying to do now. Lets tackle each problem in order.

1) How to keep VI in memory on teh cRIO. Most likely what is happening here is that you are terminating the program on teh cRIO itself (wither by ending the main control loop or calling quit labview, etc). The VI is not being erased from the flash memory on board, just getting stopped from running. To start the Vi again, you can reset the cRIO (as long as the VI in question is your startup VI).

1) By resetting the vi, I am thinking there are two ways - one is actually hitting the "Reset" button on the box (something I dont want to do), the other is actually Rebooting my cRIO (which I am succesful at doing, however, I dont have feedback on whether or not the box is actually done rebooting.  I guess I can hit the Reboot, then go into a loop that Pings the controller and either times out or gets a valid IP address.  Is there another way to do this reset?

Xaq wrote:

2) Deploying a VI to teh cRIO. Currently there are only 2 ways to do this. The first, is from the project explorer like you are used to doing. The second, which can be done programmatically assuming you have the internet toolkit or through a command line interface, is to FTP the VI to the cRIO.

2) I am trying to setup the cRIO vi such that it runs at startup, then I hoped after rebooting, it would be running and be in memory on the cRIO.  I will keep in mind the FTP option - thanks.

Xaq wrote:

3) Rebooting the cRIO programmatically. You can use the RT Reboot Controller VI, located in Real-Time VIs»Real-Time Utilities>>RT Reboot Controller.vi) to reboot a controller over the network (or reboot itself by using localhost).

3) I am donig this as discussed in 1 - thank you.

I was trying to provide more user feedback.  I guess I'm stuck in trying to use timing and my own messages to provide user feedback. 

Thanks again for your suggestions!

- Con

Message 5 of 7
(3,897 Views)
I think you are on the right track. Pinging the controller until it comes back up is a good idea, but the reboot time should be somewhat constant so a simple delay might suffice. Using the reset VI and power cycling are the only ways to rest the controller

As for providing feedback on the state of a reset, you are going to be stuck reporting on the status of steps that you have direct control over, which are few.
0 Kudos
Message 6 of 7
(3,873 Views)
Thanks for your suggestions Xaq!
0 Kudos
Message 7 of 7
(3,863 Views)