Temporally Deploy a VI on cRIO and then revert?

[bradh]

I have an application deployed on a cRIO.  The front panel is served using the Webserver.  The application is set as start-up.  The application gets it's time information from a discrete IRIG input.

In the event of IRIG being unavailable for an extended period, we have developed a utility application that uses the RT Set Time VI.  This VI is then deployed (not as start-up), the user sets the time, and the chassis is rebooted.

What is the behavior of the chassis supposed to be after the reboot.  Is it supposed to go back to the original deployment with the webserver interface or with no application running at all?

[viScience]

I have a similiar system, except that I use the software time sync (IEEE1588 PTP) to sync the cRIO time.  In the event that I am not receiving time sync, I can send the cRIO

a NSV message which causes the cRIO to set its time to whatever time was embedded in the message.  I do not need to reboot to have this time take effect.  If you do reboot then

your startup application that you last deployed will restart.  (Unless you have the noapp dipswitch set to off).  You could also use viserver to call a vi on the cRIO that will set the system time and you still do not need to reboot to do this.

[bradh]

Great ideas on how to handle remote time setting.... my problem is that I can not go back in and modify the orginal code (has completed verification testing) invalidating completed verification tests  .

Just to verify though, I was a bit un clear on the response about deployment behaviour.  If I:

1) Build/set as start-up/deploy application "A",

2) Then I later build/deploy (not set as startup) application "B". change the chassis clock with application B

3) Reboot

What happens after the reboot.  Is app "A" running, "B" running, nothing running.  I had thought that it was app "A" runs - but I am not sure why I made the assumption.

(I don't have the dip set for "no app")

[viScience]

In answer to you question... App A will always run after reboot if it was set to be the startup app. 

I think I understand what you are trying to do.  Making a remote vi server call from the host PC

will work since you will not have to modify the orgininal App A.  All you need to do is create a 'Set Clock'

vi that will execute asynchronously when call by vi server.  You will be able to pass the vi a time string as part

of the call by reference.  Of course you will need to FTP the vi to the file system on your rt target.  BTW, that can

be done programmatically by the host as well.

[billko]

Nobody addressed the issue about going backward/forward in time to deploy this. 😄

[nathand]

---

bradh wrote: 

Just to verify though, I was a bit un clear on the response about deployment behaviour.  If I:

1) Build/set as start-up/deploy application "A",

2) Then I later build/deploy (not set as startup) application "B". change the chassis clock with application B

3) Reboot

What happens after the reboot.  Is app "A" running, "B" running, nothing running.  I had thought that it was app "A" runs - but I am not sure why I made the assumption.

---

My understanding is that nothing will be running; I don't have an RT system available to test that, though.  B will be on the cRIO.  A will be overwritten when you deploy B.  I'm not sure why it's useful behavior to have a deployed application that isn't running.  If I remember correctly, there's an INI file on the cRIO, called something like ni-rt.ini, that contains the path to the startup application.  You might be able to come up with a scheme where you copy B to the cRIO under a different name (instead of deploying it within LabVIEW), then edit that file to point at B instead of A.  When B exits, edit the file back to point at A.  I've never tested something like this, and can provide no assurance that it will work - but it might be worth a try.

[viScience]

Yes my mistake.  I think Nathan is correct in that app B will overwrite app A if it is deployed from the project.  As Nathan suggested you could rename B and then redeploy A but you will not be able to selectively run them from the host.  You would need to have a app C that could selectively run A or B, that is why I think it will be easier to do this with vi server from the host calling a simple vi on the rt file system that sets the clock.