Quote:
Originally Posted by keehun
Yes. There is a WPI library block which gets input a boolean(?) which I think is tied to some low level vxWorks call. When vxWorks doesn't see it, then it probably stops the .rtexe and decides to tell the DS that the Watchdog has sadly starved to death. (figuratively)
|
The watchdogs are actually implemented on the FPGA. So when the cRIO gets a new TCP packet it feeds the FPGA system watchdog. And if you enable the user watchdog and call the feed subVI... you are feeding the FPGA section for that watchdog. Again, this is explained in more detail at:
http://decibel.ni.com/content/docs/DOC-2957
Quote:
I highly doubt it is anything but the code..
This, I highly doubt, especially if it was only your robot with this problem.
|
Yes exactly. If you say... set up your user watchdog to have a 0.5s time out... and you only feed the watchdog every 1s. Then your motors will cut out for half of every second.
The .rtexe doesn't get stopped. Your code keeps running just like before, but the FPGA gets set to a fail safe state, where no outputs are usable. You can still read in anything and run like normal, but when either watchdog is tripped no outputs are available.