[FTC]: Lag and Teleop (Labview)

[iblis432]

While working on the code i have a question that I was wondering if anyone knew. Is the NXT capable of handling flat sequence structures with multiple frames this year? I know in the past multiple frames were not allowed, but this year I'm not getting a broken vi icon on my run button, but I don't have the robot with me right this second so I don't know if it will maybe say something when I try to download the code.

[iblis432]

I have just finished a revised version of how teleop code. I think I've ironed out most of the problems, but I would like to submit it here for review while I'm waiting on a chance to work on the robot.

The zip file contains the revised version known as 0035 teleopstate.vi plus all the subvis. All of the comments and context help data is up to date, and the front panel contains information the vis.

[Ether]

Originally Posted by iblis432

I have just finished a revised version of how teleop code. I think I've ironed out most of the problems, but I would like to submit it here for review while I'm waiting on a chance to work on the robot.

The zip file contains the revised version known as 0035 teleopstate.vi plus all the subvis. All of the comments and context help data is up to date, and the front panel contains information the vis.

See attached screen shot.

By saving the vi in LabVIEW9, you have significantly reduced the pool of people who would potentially be willing and able to help you.

[iblis432]

my understanding is that 2009 is the only version of labview you are allowed to use in FTC. I know when FTC first started with 8.5, but after that 2009 was what came in the kits. I have both versions on my computer, and if I have time i'll make a similar one in 8.5 if I find we are still having problems, otherwise I will keep the format in 2009 until I have a significant reason to change it.

[Ether]

Originally Posted by iblis432

if I have time i'll make a similar one in 8.5

See attached screenshot.

You don't have to manually reconstruct the vi in a different version of LabVIEW.

Just use the "save for previous version" menu item from the File drop-down menu.

[iblis432]

I am not allowed to save it for a previous version because I do not have the password to save certain FTC toolkit vis.

The code was just tested on the robot however, and everything is working perfectly. It is all thanks to the suggestions here. Thanks so much.

[aklego]

Greetings,

I went through your code and pointed out a few changes that will further boost speed. Mainly, I edited one your subvi's to avoid the use of waits. Function is unchanged and details are on the block diagram. Caveat: This code is untested!

BTW, nice use of LabVIEW's documentation features. In my experience, very few teams use them.

Best regards.

[wilsonmw04]

I must say, I was not expecting such a strong response from the CD community. I am humbled by such Gracious Professionalism :-). We shall endeavor to pay it forward.

[iblis432]

The robot locks up with your edits, I have a few ideas why: you placed a while loop in my subvi, since this vi was in another while loop, it could be causing the lockup. You also had all the state numbers minus 1. so you had state 1 always going to 1, 2 always going to 2, so they never moved forward. Otherwise, I completely understand all of your comments. The switcher was not something I had thought about, but is certainly something I'll remember. As for the shift registers, in FRC I always use them, but they are a bit of a pain in FTC because the only structure that supports them is while loops, and those cause the robot to lock up if you place them inside of each other. In FRC I just use a for loop where n = 1. it's true i could have the state and timer values go in and out of the subvis as controls and indicators, and use the entire teleop while loop for the registers, but by that point it's more ugly than it's worth, considering it gives a milisecond reduction in lag. Plus although we did have those counters in there, they didn't seem to freeze anything up when we tested running the arm and the drivetrain at the same time. And finally, I had my suspicions about the usefulness of the hz limiter, and you finally confirmed it.

While I'm reverting back to my version of most of the code, I still must thank you, I learned a lot from your edits that can be used in FRC.

[aklego]

Greetings,

As you state, there is a problem with my case numbering and this is causing the hang. Oops. There may be other errors as well.

The while loop, however, is not an issue. At first glance it looks like it will cause a stall but that is not the case. A false constant is wired into the "continue if true" conditional terminal. This has the same effect as using a for loop with n=1. For further information:

http://zone.ni.com/devzone/cda/epd/p/id/356

Best Regards

[PhilBot]

Originally Posted by iblis432

I have just finished a revised version of how teleop code. I think I've ironed out most of the problems, but I would like to submit it here for review while I'm waiting on a chance to work on the robot.

Hi

Looks much better now.
Some suggestions:

1) You should put a small time delay in the lower control loop (maybe 25mS). This will prevent the arm control loop from hogging all the spare CPU cycles when it's not doing anything.

2) Your "Enable" logic is not quite right. You don't want to be exiting the arm control loop based on the enable flag. Both loops should run forever (FALSE wired to terminator), but the Enable indicator should be set by the Robot Driving Case Structure (True if driving, False if disabled). Then if you want to use this indicator to also disable your arm control (good programming practice), then put a case structure in your arm loop to do-nothing if the "Enabled" local variable is false.

3) Your Button 5 code turns on the NXT motor if the button is pressed, but doesn't turn it off when the button is released....

Hope this helps.

Phil.

[iblis432]

Yes, I see now, I thought it was a true statement the first time I saw your while loop.

And yes, I am aware the motor stays on, it was intentional for our purposes. Just putting the motor on break was causing the motor to still be moved at least far enough that batons would escape, so we have it continue moving until we need to open it back up. I'm experimenting with alternative so that we don't burn up the lego motor.