Unpluggin the Ethernet is Different Than Turning Off The Server!

[solarburnDOER]

Hi All,
I am working with a cFP2020 with a 4 space backplane. I am running Labview 8.0 RT. Have not gotten around to putting in the latest set of CD's I just got sent. I have the whole setup on my desk here and am noticing a potential problem for my application. Was hoping that someone could explain this to me?

I am building a vehicle, with the cFP on the vehicle and a PC controlling the vehicle. Mostly Im turning on lights and reading sensors on the vehicle, but I am transmitting some commands.

My perfect world would be that if I lost communication between the vehicle and the PC, that the vehicle would recognize this within a reasonable ammount of time (1-2 seconds) and stop itself. I would like a whole routine for "com failure" to run if that is the case.

My questions:

It does not look like I want to use the fieldpoint watchdog because everything I have read indicates that on a watchdog com error, the fieldpoint shuts down. Am I wrong? Should I look further into this?

I wrote my own watchdog. It sends messages back and forth on shared variables. If a message is late, it turns off a light (using cFP led's on the main module.) The PC VI is running as part of the project. The Vehicle VI (on the cFP) is compiled as an application that runs on startup. I have experimented alot with failure situations. The following work fine:

- Stopping the PC VI that communicates with the vehicle VI. The light on the cFP turns off fine.

- Stopping the Shared Varaible Engine. "Undeploy" on the shared varaible in the project. The light turns off fine. Infact both the PC and the Vehicle VI's register the dissconnect with their lights.

The following does not work right:

- Unplugging the ethernet link! The VI on the vehicle (cFP) is still running (got another blinking light going), however it takes 11-16 seconds for the light to turn off, indicating the disconnect. This is quite a bit longer than the other methods that work fine (those are about 1-3 seconds). Can anyone think what is going on?

I know this seems like an essoteric question, but it gets to the protocal for the cFP. Should I be running my PC VI as an application? I am running it in the project.

Thanks
Kevan -

As an aside, is there a way to deploy an application and have it run immediatly upon deploy. I am having to reboot to run the application. I notice different performance if its running from the project v. it running as an app. Since I will be using it as an app in the final product, I want to test it that way.

Thanks Again -

[Aaron_G]

Kevan,

The quick answer is that most NI ethernet protocols are implemented with 10 second timeouts. This is different than the undeploy in that stopping the shared variable engine will send unsubscribe messages rather than timing out. (Note: I am making an assumption on how the shared variable protocol works because it is partially based on the older Logos protocol used in Fieldpoint, and that is how the closing works for Logos).

As for the watchdogs, there are two watchdogs in [c]FP RT modules; the RT watchdog (which can reboot the controller) and the network communications watchdog (which can set one or more outputs to a desired state on loss of communication).

For a very rapid communication link disconnect, implement the shared variable as a boolean that has it's state inverted every half second. Have the [c]FP controller read the variable and look for changes in the state of the variable. If the variable does not change at the update rate (with some small margin for timing), then you have probably lost the link prior to getting a full network timeout.

Regards,
Aaron

[solarburnDOER]

Aaron,
 
Thanks for the explination. I was using the time stamp of the recieved message to determine a disconnect. I tried your method and it works fine. Good to know there is a reasonable explination for all of this.

Thanks Again,
Kevan -