100% cpu and twitchy too

[team_4224]

We are a rookie team and with our telop code we are getting random twitchies and 100% cpu usage, do we have to much code in telop or is it a networking problem. There is a copy of our telop code attached.

[Greg McKaskle]

Your teleop is certainly not doing too much. It may be throwing errors, or the slowdown could be elsewhere in your application.

First, check the Diagnostics tab to see if errors are piling up. They are often due to misspellings in the I/O names or old code that is updating channels that were never opened, etc.

The parallel code could be vision or periodic tasks, and they could be causing the teleop to run more slowly since most of the CPU is taken up by them.

Greg McKaskle

[team_4224]

Thanks.
We have disable vison and only the compressor control loop is in periodictask.vi and still get the same problem. Also when we run the code we get
Watchdog Expiration: System 1, User 0
Watchdog Expiration: System 2, User 0
Watchdog Expiration: System 3, User 0
Watchdog Expiration: System 4, User 0
and so on.

[Greg McKaskle]

Do the system watchdog messages correspond to the twitches? If so, look at the charts tab and see if you have lots of lost packets. That also correspond.

Greg Mckaskle

[ablahblah]

I'm still somewhat inexperienced with LabView, but I've never fed Watchdog in Teleop, or frankly, did anything with Watchdog; I just let the default code handle that. The programmer of my past team never did either...though Watchdog has shown that it does function, confirmed with the system watchdog expiration messages when the robot goes to teleop/auto disable. My first team, doing java, had to mess with it since that code I think is built ground up, but I've never done anything with it in LabView.

Teleop doesn't seem to be doing anything that can overload the cRIO though. The bot just keeps twitching, and it doesn't stop doing that within a reasonable timeframe, right?

[Greg McKaskle]

If you didn't explicitly Open and enable the watchdog, you do not need to feed it. Watchdogs are a useful concept for making systems safe, but a few years ago, all languages moved the watchdog underneath the RobotDrive and other outputs and made the feed be a part of the update.

I agree that your teleop isn't causing the CPU usage or the twitches, but since I haven't seen the rest of your code, I can't tell you where the issue is. If you want to solve it yourself, look at vision and periodic tasks. Specifically, look for code that is setting the twitchy motors in parallel with teleop.

Greg McKaskle

[Peck]

Just a quick recommendation, cheek the wireless in the area, The driver station says cpu is at 100% as a default when you loose the packets related to cpu level. If there are to many wirelesses on the same frequency, connection starts to suffer (yes, that is the reason for the no unnecessary wireless networks in competition area) and that can manifest as packet loss which can cause the cpu to show 100% and can also give you microscopically small loss of coms which results in a twitchy robot.

[Greg McKaskle]

Actually, if packets are lost, CPU usage usually drops. This is true for the default LV framework, and I believe for C++ and Java too. If packets don't arrive, some parts of the system will run timed tasks, but other portions will stay asleep.

While it is possible for an excessive number of wifi networks to impact the connection to the robot, especially on 2.4 GHz, this will not cause CPU usage to rise on the robot. The charts tab will show whether the robot is losing comms, getting watchdogged, or running as prescribed. If you post a photo of the log file viewer, I can help point out the patterns.

Greg McKaskle

[Peck]

Originally Posted by Greg McKaskle

Actually, if packets are lost, CPU usage usually drops. This is true for the default LV framework, and I believe for C++ and Java too. If packets don't arrive, some parts of the system will run timed tasks, but other portions will stay asleep.

While it is possible for an excessive number of wifi networks to impact the connection to the robot, especially on 2.4 GHz, this will not cause CPU usage to rise on the robot. The charts tab will show whether the robot is losing comms, getting watchdogged, or running as prescribed. If you post a photo of the log file viewer, I can help point out the patterns.

Greg McKaskle

kk, i was speaking on what the software sub team told me to watch for when driving the robot at our regional. they may have altered something.