After resetting our D-link, our Driver Station is telling us that the Watchdog isn’t being fed. We have checked through our code, but everything checks out. Prior to reset, we had no Watchdog issues. If anyone can help please do.
The bridge couldn’t possibly be a problem with the watchdog, unless there is a considerable amount of lag. I would guess it’s something in your code that enters a loop without updating your driving values.
It might be the code. However, we made no changes to anything BUT resetting the bridge…
Code on a robot won’t run the same way every time. It’s certainly possible that some part of your code has never been run until now and it is just now starting to give you errors. My advice is to redeploy and try logging suspicious parts of your code which could end up in a loop.
Are you programming in Labview? If so make sure that you have the Feed Watchdog VI included in your code.
I will certainly try to redeploy, and find possible errors. And no, we are not using LabView, we are using C++.
Is this a Watchdog error, or is this the “MotorSafetyHelper: Motor has not been updated often enough” error?
MotorSafetyHelper errors can be pretty common. They occur if you don’t constant send new control values to your motors. If you’re convinced your code is alright, you can use the SetSafetyEnabled(false) method to disable the MotorSafetyHelper for a particular motor or motors.
Here is the code we are using, its in C++. Please check it and tell us if there is anything wrong with it. We still haven’t found anything in the code, hopefully one of you can.
Is this a Watchdog error, or is this the “MotorSafetyHelper: Motor has not been updated often enough” error?
MotorSafetyHelper errors can be pretty common. They occur if you don’t constant send new control values to your motors. If you’re convinced your code is alright, you can use the SetSafetyEnabled(false) method to disable the MotorSafetyHelper for a particular motor or motors.
Kevin, it is a Watchdog error.
130217.txt (10.5 KB)
130217.txt (10.5 KB)
If it’s not fed, you have to kill it and bury its body in the backyard.
- WPILibrary
The code you posted isn’t using the Watchdog, can you post exactly the error you are seeing and where on the DS you are seeing it?
Also try installing the Driver Station Update 3 from here: http://joule.ni.com/nidu/cds/view/p/id/2263
Then you can look at your Trip Time and Lost Packets in green and blue respectively on the Charts tab of the DS.
I agree that you don’t seem to be using the watchdog anywhere. While there’s a Watchdog that’s a member of the SimpleRobot class you derive from, the SimpleRobot constructor disables it by default. You have to actively enable it for it to do something. If you’re really sure that’s the problem, you can call GetWatchdog to get it, or simply access it directly at m_watchdog. If you put m_watchdog.SetEnabled(false) in your constructor, that’ll guarantee it’s disabled.
On the other hand, your buttons for driving the robot forward,backward, etc. for a fixed amount of time will definitely cause problems and MotorSafetyHelper errors. Putting a Wait() in your OperatorControl while loop is a really bad idea, because it stops everything else and waits. It’s also not likely to do what you want.
If you have MotorSafety enabled, then your robot drive is expecting a new TankDrive or ArcadeDrive or somethingDrive command every 0.1 seconds. If you don’t update it, MotorSafety will disable that motor until you command it again. So you give it that TankDrive(-.3,-.3) command, then wait 2 seconds with a command, which kills your motor, then you command it (0,0).
On the other hand, if you have MotorSafety disable, everything else keeps doing what it was doing just before you hit that button. If your armmotor was going down and you hit the backup button, that armmotor is going to keep going down for two seconds, limit switch or no.
So mostly, you shouldn’t be using a Wait() in your OperatorControl loop.
What is the alternative to Wait? That is what we have been using to release CPU time to other threads. So far, we have not had a problem. Although, we use wait only at the bottom of the code, not inside the code. We use timers for that.