Robot Drive Not Running Fast Enough
 

Our robot is working perfectly, but we are having some problems with the robot drive. The RoboRio keeps sending a message to the dashboard about the robot drive not running fast enough. Please help!

Re: Robot Drive Not Running Fast Enough
 

Does it send the message when the robot is Teleop Enabled or only when Disabled or in Autonomous

You can check by Enabling in Teleop then clearing the DS log window to see if the message is still being sent, or by checking the recorded DS Log.

Re: Robot Drive Not Running Fast Enough
 

The Error usually pops up when Teleop is enabled.

Re: Robot Drive Not Running Fast Enough
 

That means your Teleop processing is taking longer than 100ms.
If you'd like to attach your Teleop.vi we could check it for low code.
Generally, no delays, no loops, no massive amounts of complex code.

If the msg occurs just once, then there is not much cause for alarm. It could just be a startup delay.
If it repeats regularly, then the user code is too slow.

Re: Robot Drive Not Running Fast Enough
 

Can someone explain where and why this startup delay is occurring?

Re: Robot Drive Not Running Fast Enough
 

There are a few common reasons for this that I sort of brush over.

For instance, while the default code running at startup doesn't typically throw any "too slow" errors, it will during autonomous because the motors aren't used in there by default.
However if the identical code is run in debug with all it's attendant front panels and comms back to the laptop we might see one "too slow" message during initialization. More msgs will appear as we just drag any front panel around.

Another possible cause might be the addition of code somewhere that takes longer to initialize, for instance a Gyro that has a default calibration time of 2 seconds.

Re: Robot Drive Not Running Fast Enough
 

Here's my code:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Wait how are you practicing with your robot after bag and tag.

Re: Robot Drive Not Running Fast Enough
 

We have a practice robot.

Re: Robot Drive Not Running Fast Enough
 

The code doesn't look slow, although I can't see what's on the reverse of all those cases.

-80 is an odd choice for powering a motor, but it gets truncated to -1 anyway.

Re: Robot Drive Not Running Fast Enough
 

Mark McLeod has made some good points. And like him, I can't see what is on the other sides of the case structures, but there is one thing I am aware that will cause a delay and you have enough of it for it to potentially be your cause.
It is the get DevRef.vi - now, hear me out.
If I count correctly, there are six of these in your code, 1-joystick, 1-drive, 3-motors, 1-dio. Assuming this is the only joystick, drive, and dio opened in your code, they will not be the cause I am attempting to point out (although not closing them in finish.vi can contribute, so make sure to do that). Rather, it is the 3 open motor DevRef.vi's that I am looking at primarily. If you open the get DevRef vi you will find that it calls something like the attached DevRef Example (this one is of the WPI_MotorControlGetSetRefNum.vi).
http://www.chiefdelphi.com/forums/at...d=14244940 68
If you go to the the block diagram, and open context help, you should notice that the search 1d array that I have drawn an arrow to in the attached image is a linear search. This means that it always starts at the first item in the array, and goes through the array until it has found the index of the refnum name. It then uses this index to get the DeviceRef to pass out.

This means that the more of a given device is used, the more time is spent searching per call.

Example, three motors are used, let us say for the sake of convenience that the order in which their Device References are attained is the order in which they are sorted.
For the first motor, the search finds the correct refnum at the first index, and we are done; however, for the second motor, the search will not find the correct refnum till the second index (i.e. it had to run more instructions), not too bad. But then, to find the third motor the search will start at the first (index 0) not find it, check the next one (index 1) not find it, and finally check the third index where it finds the correct refnum.
This doesn't sound too bad until you consider that in our example, the WPI_MotorControlGetSetRefNum.vi is taking a certain amount of time to run, then almost twice that on the second, and almost triple the original time on the third. - In other words, the indexing and checking in the vi occurs six times per Teleop.vi call in our example just for the motors.

A Solution,
don't use the WPI_MotorControlGetSetRefNum.vi in Teleop at all. One can wire the DevRefs for the motors (and really for everything) from the begin vi to Teleop.
This is what I started doing 6 years ago, and I haven't had this error since then (except in situations where I did setup to use the set/get DevRef vi's for quick tests).
I have attached a picture of what it might look like in Teleop and in Main.

Note: if the multiple wires going to Teleop disturbs you, bundle all the DevRefs in Begin, set the cluster as an indicator and wire it across to Teleop (it takes significantly less time to unbundle than to search)

I will post a tutorial on my website this weekend explaining more LabVIEW tricks to make this method of optimizing Teleop even easier, but this should take care of the error.

Re: Robot Drive Not Running Fast Enough
 

Let me add a few things.

The default project contains a VI in the Support Code folder called Elapsed Times.

If you drop it into teleOp and open its panel, it will tell you the ms delta between calls to it, thus the scheduling time of teleOp itself. This is a pretty simple way to see whether this happens a lot, only when a certain button is pressed, etc.

You can also look at log files to pinpoint when the messages occur and how often. In the DS, click on the Logs... button and it will open the viewer. You probably need to scroll to the bottom to find 2015 logs. Flip through a few and see if you find any that are representative. Or better yet, send the robot through a practice match, and look at that log.

The default view of the log is a graph and along the top of the graph are green and blue dots for each control packet sent and processed. They are generally so dense that they look like a line. But they are independent dots. Just below this you may see some red or amber circle markers indicating error or warning messages. If you hover over those, the messages box in the lower left will give the details for the message. This is useful because you can get a sense of when and how often the messages regarding slow teleOp are arriving. You can see if they are only at the beginning of auto, the end, during teleOp every time a certain action is performed, etc. You can also switch the tab above the graph for a list showing only the messages. This will help scan for particular messages and give a sense of who many. The timestamps tell you when, but it is hard to draw a mental picture compared to the graph.

Finally, back on the graph, if you see a period where interesting stuff is happening, you can click and drag a box left-to-right around that point of the match and it will zoom in. You can then start to see the dots for packets. You can see if the messages indicate that you are processing teleOp packets, but not updating motors, or not processing them at all.

In fact, if you will post a log file (.dslog, .dsevent, and possibly .pdplog) that contains representative data, I'll be happy to look at it and I can be more detailed as to what it suggests about your robot code.

The log files are in the c:\Users\Public\Documents\FRC\Log Files directory and the info is saved in a couple files with a matching timestamp. Either attach the individual files or zip a timestamp pair and post it.

Greg McKaskle

Re: Robot Drive Not Running Fast Enough
 

Hmm, you just made me realize that we've accidentally put a bunch of RegistryGets inside of the enclosing while loop in our autonomous code so our code keeps doing this name search on every pass. No wonder we were getting the "not running fast enough ..." error in our autonomous.
Thanks for the epiphany. I guess RegistryGets are not as harmless as they would seem.

Re: Robot Drive Not Running Fast Enough
 

I'm curious as to how you were able to create those GetRefNums nodes considering that I too am having a similar problem however I am not familiar enough with Labview itself to go about creating those.

Re: Robot Drive Not Running Fast Enough
 

Let me add in again. I'd encourage you to measure the CPU load and the time of the loop. Registry Gets are a pretty simple subVI that was created for each type of I/O in order to allow teams to build apps without needing to immediately modify connector panes or types on the connector pane.

They have a cost, but that cost is quite low. The arrays that are being searched are ten elements or less, and this is generally not the reason for the message of the OP. My advice is to use them once inside of teleOp or Auto and then wire within the subVI.

I failed to mention the profiler in the previous post, but if your logs show that you are indeed using most of your CPU, and that is why you are missing deadlines, then the performance profiler is the tool that will tell you how much CPU a given function consumes and how often it was called. There is nothing wrong with cleaning up the numerous getRefs, but it may not solve the original problem and may wind up being busy work.

Greg McKaskle

Thank you very much a everyone!