Robot Drive Not Running Fast Enough

[mshafer1]

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.

[Greg McKaskle]

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

[BitTwiddler]

Originally Posted by mshafer1

It is the get DevRef.vi - now, hear me out.

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.

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.

[The_Waffleing]

Originally Posted by mshafer1

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.

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.

[Greg McKaskle]

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