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.