From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »
cFP-2020 watch dog handling
Aaron_G
Active Participant
03-21-2005 08:19 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
There are two different watchdogs with FieldPoint/Compact FieldPoint controllers, the network communications watchdog and the RT watchdog.
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).
Because the communications watchdog controls the IO which is also (possibly) being controlled by the embedded LabVIEW code, it is recommended not to use the comm watchdog when embedded code is running (hence the reference to not using the comm watchdog in the help). In reality, the comm watchdog does work on the cFP-2020 as you have found from your configuration setting the outputs to false.
You mention that the outputs go true after 5 minutes. Is there anything (another computer, embedded LabVIEW program) that may be turning the outputs on?
The Reset Option is supposed to re-boot the controller, in which case the relay outputs will initially turn off until the controller finishes booting, at which point the power-up values will be applied. These are configured by you via MAX.
To set the outputs programmatically from an embedded LabVIEW program you would use set occurance option to trigger a high priority loop to write the outputs.
Regards,
Aaron
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).
Because the communications watchdog controls the IO which is also (possibly) being controlled by the embedded LabVIEW code, it is recommended not to use the comm watchdog when embedded code is running (hence the reference to not using the comm watchdog in the help). In reality, the comm watchdog does work on the cFP-2020 as you have found from your configuration setting the outputs to false.
You mention that the outputs go true after 5 minutes. Is there anything (another computer, embedded LabVIEW program) that may be turning the outputs on?
The Reset Option is supposed to re-boot the controller, in which case the relay outputs will initially turn off until the controller finishes booting, at which point the power-up values will be applied. These are configured by you via MAX.
To set the outputs programmatically from an embedded LabVIEW program you would use set occurance option to trigger a high priority loop to write the outputs.
Regards,
Aaron
- « Previous
-
- 1
- 2
- Next »
