Data delay between Crio and DS

[Tom Line]

We are running the Crio from our computer in labview, currently there are major delays in drive values and other data between the robot and the joystick, about a one to two second delay. Is this normal, or is there something else slowing us down other than running off the computer?

[paulcd2000]

Running off the computer slows you way down, but one to two seconds is huge. Do you have any complex vision code? that can slow stuff down.

[Greg McKaskle]

This sounds just like a behavior of the initial code. Have you updated the DS, cRIO, and you dev libraries to 3.0?

If this isn't it connect the serial cable from cRIO to a terminal program. That will tell a lot.

If there are lots of messages streaming to the serial, that will in fact cause this delay.

Greg McKaskle

[Tom Line]

Greg, can we send you our code to take a look? We're really at a loss.

[Greg McKaskle]

Sure. PM me I suppose.

Greg McKaskle

[Tom Line]

Greg - thank you. At this point we tracked the issue down to the vision code. We took that out for now since we are working on the drive train and traction control today.

Once we try to add it back in, you can be sure I'll be contacting you

Thanks again!

[Greg McKaskle]

Not seeing the code, my guess is that the vision code was placed directly into the tele loop. This will seriously delay processing tele packets that are streaming in at 50Hz.

Instead, try putting the camera code to run in parallel and update a global or local variable describing where the target is. Then incorporate that into your fast tele loop or you auto loop.

Greg McKaskle

[PurpleHaze]

We are having the same issue with delay. Our camera code causes the robot to have a delay with receiving inputs of about a second. It is running in its own parallel loop, and yet it affects the whole system. We've got less than 24 hours till we ship, and we need to get this up and running... Help?

[Alan Anderson]

Originally Posted by PurpleHaze

Our camera code causes the robot to have a delay with receiving inputs of about a second. It is running in its own parallel loop, and yet it affects the whole system.

Add a Delay VI inside your camera loop to keep it from running at full throttle. Suitably chosen, that delay will give the rest of your code a chance to run.

[Tom Line]

Actually, we took the example labview code, copied it and pasted it directly into the vision processing .vi in the advanced framework. This caused a 1 to 2 second delay in everything we did.

We've got the next week or two to work with it since we held our controls system back (THANK YOU GDC), so we'll start working on getting the lead out of the routine on Friday.