Spontaneous motor skipping?

[360skier]

The watchdog works like a timer. If it doesn't receive a feed command from your code every so often, it shuts down your output. This is to prevent you from setting your motors to full forward, and then lagging the classmate so you can't shut them off.

If you look at the watchdog methods (or blocks if you're using labview), there should be one something like SetPeriod which takes a float. This will allow you to specify the watchdog timeout, in seconds I believe. Making this slightly longer will hopefully stop causing the intermittent motor shutdown you've been seeing.

[Leav]

Originally Posted by 360skier

The watchdog works like a timer. If it doesn't receive a feed command from your code every so often, it shuts down your output. This is to prevent you from setting your motors to full forward, and then lagging the classmate so you can't shut them off.

If you look at the watchdog methods (or blocks if you're using labview), there should be one something like SetPeriod which takes a float. This will allow you to specify the watchdog timeout, in seconds I believe. Making this slightly longer will hopefully stop causing the intermittent motor shutdown you've been seeing.

NO!

I'm not an expert but from what the NI-Guy(tm) at our regional (Go Andrew!) told me, you are not supposed to change the watchdog timeout from it's default (0.5sec?).

That would be like putting a bigger bucket under a leak, instead of fixing the leak.

what you need to do is have a good look at your code, and find out what routine is bogging up the processor. I'm sure many people at the programming forum would have the capability to help you look over the code if you can't find the problem...

Good luck!
-Leav

[TubaMorg]

Originally Posted by 360skier

The watchdog works like a timer. If it doesn't receive a feed command from your code every so often, it shuts down your output. This is to prevent you from setting your motors to full forward, and then lagging the classmate so you can't shut them off.

If you look at the watchdog methods (or blocks if you're using labview), there should be one something like SetPeriod which takes a float. This will allow you to specify the watchdog timeout, in seconds I believe. Making this slightly longer will hopefully stop causing the intermittent motor shutdown you've been seeing.

Yes this is what I meant by widen the setpoint. I apologize for the vague terminology! Avoid the temptation to set it too long, it really is an important safety feature. As leav pointed out, more than 0.5 seconds is too long. Our Java had a default of 0.2 seconds that we changed to 0.4. If your code is getting stuck somewhere for longer than this, it definitely needs some optimization work

[Azores]

I was able to resolve the issue (it seems) by changing the power management settings on the Classmate as well as going into its BIOS and turning off SpeedStep and C-State or something like that (they just seem to reduce CPU power to lengthen battery life). We have a UPS to power the Classmate so battery life still shouldn't be an issue . And if it comes down to it, we have an inverter that works fine as well. I've gone over my code several times and had the other programmers on the team - although I'm the only one who wrote the robot code, we have others who are capable but were too busy with building the rest of the robot - look over it for errors and possible resource reduction possibilities and they couldn't come up with anything either.

[Greg McKaskle]

Do you know what the power settings were? Also, did you try only changing the power settings, or asked another way, was it necessary to change the BIOS?

Greg McKaskle

[Azores]

The power settings were already set pretty well by whoever did it before - while plugged it, everything was set to "Never." They had the battery settings as turning off the monitor and HDD's after 5 minutes of inactivity and everything else to "Never." I changed monitor shut down to 10 minutes and HDD to 15. So nothing really with the power management. I think it was the BIOS settings really that fixed the issue.

[TubaMorg]

So changing the power settings solved the Watchdog issues? Or is the Watchdog still cutting out?

[eugenebrooks]

Some instructions on how to get into the bios and change these
settings would be appreciated. Intermittent watchdog errors
are driving many teams nuts.

Edit: See http://www.chiefdelphi.com/forums/sh...d.php?p=945073

Eugene

Originally Posted by Azores

I was able to resolve the issue (it seems) by changing the power management settings on the Classmate as well as going into its BIOS and turning off SpeedStep and C-State or something like that (they just seem to reduce CPU power to lengthen battery life). We have a UPS to power the Classmate so battery life still shouldn't be an issue . And if it comes down to it, we have an inverter that works fine as well. I've gone over my code several times and had the other programmers on the team - although I'm the only one who wrote the robot code, we have others who are capable but were too busy with building the rest of the robot - look over it for errors and possible resource reduction possibilities and they couldn't come up with anything either.

[Azores]

Yes, changing the power management and SpeedStep/C-State settings (I did both at once before checking for Watchdog again) seems to have solved the issue. Like Eugene's linked thread says, reboot the Classmate and tap delete until you get into BIOS setup. I think it was under "CPU Settings" or something like that. Just disable the SpeedStep and first C-State option, then hit F10 to save and exit. Worked for us, hope it's so simple for you too .

[Greg McKaskle]

I'm asking because I've been investigating the WD errors over the last four of five days. The problem is that even with Max Battery power settings, I can't get repeatable failures. I can see timing glitch differences, but not big enough to cause WD errors. I can repeatably cause other problems by setting power settings to that extreme -- this will be detailed soon.

If you have the time, can you stepwise back out the changes until the problem comes back? Clearly asking teams to make numerous BIOS changes has its risks, so I'm looking for the minimal changes, and ideally, the series of steps one can take to improve the timings. The tradeoff here is battery life.

Let me know your observations. Thanks.

Greg McKaskle

[Azores]

Yep, next chance I have I'll go back and set the BIOS to default and see if the WD errors come back.

[Merle]

Originally Posted by eugenebrooks

Some instructions on how to get into the bios and change these
settings would be appreciated.

While the Classmate is booting up press the DEL key to get into the BIOS screen. When in the BIOS screen click on ADVANCED then CPU CONFIGURATION. I turned both the SpeedStep option and the C-State option to disabled (both were enabled).

I have not tried any variations of these two options (example, one enabled and the other disabled). From the websites I've read and the symptoms I've seen in my testing, my suspicion is the SpeedStep is the one that needs to be disabled, I just took the shotgun approach and disabled the C-State option as well as our competition starts this week. Its working for us so far, more testing with the bits of our bot that we kept tonight.

Merle Yoder
The GRUNTS Team #3146