FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

cFP-2020 watch dog handling

Hello-

I'm looking for help configuring the RT watch dog so that I can trigger a specific output on my RLY421 module. In a previous VI version, I used the network watchdog feature with a FP-1000 module, but now that I'm imbedding the VI on the cFP-2020, it seems to make more sense to use the hardware watchdog VI.

Thanks in advance for the info...

Dave
0 Kudos
Message 1 of 11
(5,155 Views)
Dave,

The information I presented in the following thread is relevant to your desire to use the watchdog and the differences between the watchdogs. http://forums.ni.com/ni/board/message?board.id=170&message.id=108757

The communications watchdog provides the functionality that you desire. However, the communications watchdog is not very useful when embedded RT code is running. Unfortunately, the embedded RT watchdog (when run on FieldPoint targets) is primarily useful for rebooting the FieldPoint controller and not for setting outputs of a module. However, you can use the RT watchdog to reboot the module and the power-up settings for each channel to set the cFP-RLY-421 to your desired state.

Regards,
Aaron
0 Kudos
Message 2 of 11
(5,153 Views)
Hi Aaron-

Thanks for the quick reply.... Can you explain a bit more why the network watchdog isn't as useful for an imbedded VI as the hardware watchdog? Seems to me that the network watchdog primarily covers the eithernet cable and PC, but it should also trigger if the cFP-2020 drops it's end of the comm....right?

Dave
0 Kudos
Message 3 of 11
(5,146 Views)
Dave,

With FieldPoint Ethernet modules (FP-160X and [c]FP-20XX) a client/subscription model is used for communications. Because the RT controllers can be used as simple ethernet modules without embedding RT code in them, the network watchdog is used for network communications monitoring and will trigger when all subscriptions to the module are released (release can occur programmatically by shutting down the FieldPoint server or due to system failure). This is the same between both RT and non-RT systems. Although it is possible for certain VIs (DataSocket, FieldPoint Network Read) to use the communication interface rather than the local bus interface (as the FP Read/Write/Advise do when running embedded), a decision was made that local subscriptions (originating from the module itself) should be excluded from being counted as subscriptions for watchdog purposes. The communications watchdog only looks at subscriptions to it, not communications from it.

The point of the network watchdog is to protect against communication failures between a host and remote target (whether serial or ethernet) with the assumption that the host is controlling the target and communications failure requires safeguarding the system. It is assumed that LabVIEW code running embedded is providing the control and will not lose touch with its own IO. The RT watchdog is to protect against the LabVIEW code running away with (e.g. infinite loop) or crashing the processor and forces a reboot of the system (if needed) rather than leave the system in an uncontrolled state).

As a side note; on the PXI RT systems the RT watchdog provides some additional functionality (such as external triggers) that is not supported in the FieldPoint platform.

Regards,
Aaron
0 Kudos
Message 4 of 11
(5,144 Views)
Aaron-

Sounds like the hardware watchdog driving a system reset and defining the power up states of the modules is my best course of action. I had tried to implement the hardware watchdog previously, but I'm not certain that I'm implementing it correctly. I've attached a bare bones piece of code (while loop with the watchdog) similar to how I'm trying to implement it in my actual application. Could you look it over and see if I'm missing something?

FYI, in my actual application, the while loop is timed to occur every 1 second, so I'm thinking of using 2 seconds as the timeout value for the watchdog.

Thanks again for all of your help-

Dave
0 Kudos
Message 5 of 11
(5,140 Views)
Dave,

One minor correction to your code. In the Expiration Actions cluster, checkmark the box that says reset. The Trigger line and trigger protocol are not supported in FieldPoint targets, so the trigger line should remain as none.

A possible alternate implementation, though I have never tried it, is to use the occurance option (which is supported in FP targets). You could have a code segment that writes to the outputs and only executes if the watchdog occurance triggers. The drawback to this approach is that if a part of your code has locked the controller (for example a while loop with no delay overloading the processor), the system may not have the resources to allow the code segment to run.

Regards,
Aaron

Edit: Corrected misspelling of one word.

Message Edited by Aaron G on 03-08-2005 11:16 AM

0 Kudos
Message 6 of 11
(5,138 Views)
Aaron-

Thanks for checking that over.... I had the reset box checked in the acutal code... just missed it in the example.

I guess that I can temporarily wire in a variable time for the while loop to verify functionality of the watchdog. If I have more issues I let you know.

Thanks again for all of your help.

Dave
0 Kudos
Message 7 of 11
(5,131 Views)
I use Labview RT with a Compact Fieldpoint cFP-2020 and a relay cFP-RLY-421. But I have a big problem!
The watchdog put default value (1) on the relay and switch on my instrument. I tried to program it with MAX. That put all the chanel at 0 but 5 minutes after, it is all again at 1.
The help said I couldn't use the watchdog configuration of MAX with a Compact Fieldpoint cFP-2020, however I don't know how programming it on Labview.
I really need some help, please...

Thank you.
0 Kudos
Message 8 of 11
(5,069 Views)
Hello-

The watchdog timer is pretty simple to implement in labview. Take a look at the watchdog example VI I posted earlier (~ 3 messages up). You've got two options once the timer triggers: reset the cFP-2020 or run some type of script wired to the occurance terminal. In my case, I used the reset option and defined the power-up states of my 421 module (using MAX) to send me a signal that the cFP-2020 had restarted. The example I posted had the occurance box checked by accident, but hopefully you get the idea.

Hope that helps. If not... perhaps Aaron will lend a hand.

Dave
0 Kudos
Message 9 of 11
(5,064 Views)
I'm really sorry but I can't open your example because I work on Labview 7.0 and it seems that your example used the version 7.1.
I tried the option reset but it resets all the module and I lose the conexion. Maybe, my program is bad.

thanks for all.
0 Kudos
Message 10 of 11
(5,058 Views)