Quote:
Originally Posted by wilsonmw04
Here is the code. I'm really looking for some Labview/NI support. However, if we can't find the cause of this lag we will be dropping Labview and going to robotC where we have heard there isn't this lag issue.
|
First...
You don't need to use "Read Packet Flush.vi" this year because the Samantha Module uses USB, which doesn't suffer the 5 packet buffer problems that Bluetooth does.
Next...
To drive your wheels you are running tank mode, and you have TWO Move MotorS (group) VIs, that are each controlling one wheel. That's OK, but you are using the "Multiple Motor" version of each one. So you are passing each one an array of motors, that only contains ONE motor. This will double your processing. I suggest changing these to single Move Motor VI's by clicking on the pull-down list below them and chosing "Move DC Motor" (Without the Group or Multi option). This will require that you also delete the Arrays of DC motors an inputs, and replace them with Single DC Motor inputs.
Finally
I suspect that your lags are really due to the MANY 0.7 second delays that you have in your servo processing code. Whenever you hit an arm function you are moving your servos and putting in a big delay. This delay will prevent the code from processing any new joystick inputs. Yeah... it will be sluggish.
The best way to do this (As shown in the templates) is to read the controls in one loop, and then share the button actions via local variables. Put your servo actions in another loop that can run independantly.
I also noticed that you have set your Message timeout to 10 Ms. (Going into FTC Robot Status). I can't imagine this is helping.
This tiemout is for detecting loss of link. 1000 ms Is more than adequate.
Phil.