Loop not running fast enough error.

[DocWu]

Since day one, even with the default code, we have had the following error:

ERROR <Code< -44061 occurred at "Left and Right Motors" in the VI path: Robot Main.vi  FRC:  The loop that contains RobotDrive is not running fast enough. This error can occur if the loop contains too much code, or if one or more other loops are starving the RobotDrive loop.

We've had a lot of general suggestions, but nothing that has solved the problem. Various other erros pop up from time to time, but this one is a constant. We have had trouble with communications with the robot, even when tethered. Trouble deploying while debugging and developing code. Frequent errors during deployment with "Unable to connect" and "Target in use" type errors. It has run just well enough to be able to compete once deployed permanently through "Run as startup" but all this has slowed down our programming to a crawl to the point we have had a hard time finishing anything but a basic autonomous routine.

One suggestion we've had is the "Profile Performance and Memory Window." This often shows our processor at 97-98% but hasn't given any clue as to what to do about it. We have increased delay times in loops everywhere we can find one because we were told that was one thing to try. It hasn't helped.

At this point, we've managed to do well at the regional we went to. We are now preparing to go to the Championships and trying to simulate the current code on a previous years robot. We need help. Is there anyone who would be willing to look at our project and see if they could spot any problems? I'd be happy to zip up the whole thing and send it to any expert willing to try to help.

Thanks

Edit: I am having trouble creating a reply on this board for some reason, but it's letting me edit this posting. I'm adding Default Robot Project-3-10-2011.zip as an attachment (hope it's not too big) for anyone who can look at it and advise us. This code is a snapshot of what we had at the Pittsburgh Regional.

Thanks to Davis for replying. We are using another laptop for programming and running the driver station on it when testing. We use the Classmate on the field. We've had even more difficulty staying connected if wwe try to use one laptop to program and keep the Classmate online for a driver station.

We were not aware of the Read MJPEG.vi camera code at the time. We started removing the camera code at some point. It may still be in the code I've posted. It didn't seem to help. Although I would like to try the Read MJPEG fix, as we were using the camera only as a visual aid...

I didn't use any Watchdog VIs. It was my understanding that they were replaced by the Safety Config VI, which I didn't try to change either. I hope to try setting a longer timeout next time we work on it.

You said "Also, if you are using the code with it set up in the (begin/teleop/finish VIs) then I do not reccomend using delays in the program." I don't know what you maen by "it" so I can't comment.

We  reimaged the cRio to cure the "unable to connect" issue several times. We also used the "no app" DIP switch at times. That usually got us back to programming, but it's still such a time-waster that it impeded our progress a lot. Our last session on the work robot went much better, with us being able to deploy and test code repeatedly with minimal connection errors, but we don't have any explanation why it suddenly behaved itself.

Message was edited by: Albert Gritzmacher My apologies for not opening another reply to the reply, but for some reaason, the reply links only show a "Javascript:void(0);" link. I thought it might be Firefox 4, but IE and Chrome are doing it to me as well... This is the only way I can add to the discussion at this time.

[43803490]

Hi,

So, about the processor.  Are you using the Classmate PC? Also, are you using the Read MJPG Camera set up?

         If so, the FPS rate has been noticed to be to fast for the computer. (So my team always uses my personal computer, which is allowed at competition this year)

I'm not sure if you have tried this, but when my team had this error, it would freeze up and temporarily lose communication.)

     So, I had to incorporate the watchdog and tell it to just feed. (I am going to mess with the safety config stuff this week to see what that does)

Also, if you are using the code with it set up in the (begin/teleop/finish VIs) then I do not reccomend using delays in the program.

And, I get deployment issues a lot, but whenever that happens I just reimage the cRIO. (even made a document that makes it much more understandable)

If issues still occur, I can take a look at the code and test it. (but would probably have to be after this week since my team's first regional starts Thurs.)

Let me know how this helps,

Davis Catherman

[sciencewhiz]

Compressor Start is a very heavy call, as it actually starts up a parallel loop every time you call it. The more times you call it, the worse it gets. In periodic tasks, you're calling it every second. You should call the compressor start in begin once and never call it again.

[DocWu]

Regarding Compressor Start:

I'm sorry. I didn't realise I had gone to a version that far back. We did exactly what you suggest a while ago.

Any other suggestions?

[nathand]

Don't have time to look at your code right now, but one thing that comes to mind is, do you have any loops that run as fast as possible (no wait of any sort inside them)?  If so, those loops will starve the processor of time to do anything else, including running your main loop and communicate with the driver station.

[43803490]

Hi,

I would add the Watchdog declare, and Watchdog Feed, and Watchdog close.

I understand that it says watchdog is not necessary this year, but when my team, and another team at a pre-ship competition had this problem, i was able to fix it by adding the feed function for the watchdog.

About the time delay, I didnt see your code posted at first and now that i saw it, what I mentioned isn't needed.  (by "it" i meant "the code" but that was iff you used only the begin/autonomous/teleop/finish VIs)

I simply use my laptop for anything involving the robot (coding, deploying, running, etc.)

I don't understand the issues with reimaging helps for random times or not, but it just does. ( I am adding the document that i organized for reimaging the cRIO which makes it simple).

I have every now and then managed to reimage the cRIO without certain steps, but other times not.  But whenever I have reimaged exactly how it describes, it has always worked.

Hope this helps,

Davis Catherman

[DocWu]

Davis,

Thanks for the help. Adding the watchdog vis is worth a try. I assume the open goes in Begin.vi, close in Finish.vi. Where should the feed go? Robot Main, Teleop, Autonomous or all of the above?

Your reimaging proceedure looks good. Haven't had any problem doing that of late, but the step-by-step is good to have.

Al

[43803490]

Al,

My Feed for the Watchdog goes in the Autonomous, and Teleop. (But those are the only places where I have the actual code).

So, if any of your code includes extra loops, I would reccomend adding it their as well.

Also I wrote that guide before the new robot radio, so instead of using wired, you can connect directly to it using AP setting on the radio, and on the computer- connect to the wireless network of the radio.

Hope it works,

Davis Catherman