Re: motor programming
 

It's a throttle. It makes it so that the joystick button is only checked every 20 milliseconds inside the large While loop. Without it, the code in that loop will be running As Fast As Possible, which is undesired for two reasons. First, new joystick data only arrives every 20 milliseconds, and there's no point in checking any faster than that. Second, and more importantly, if the code is running without any delays, it can starve the rest of the program of CPU resources.

Re: motor programming
 

The wait 20 is in there because this loop is designed to be dropped in Periodic Tasks and run in parallel with Teleop (which should contain your drive code). The wait command actually releases the processor to do other things for a split second then come back and rerun this loop.
Please note two things. 1) the code posted by Mark is a snippet, you can download the picture and drag it into LabVIEW and it will turn back into code.
2) it is advisable to move the part that he has labeled labeled for teleop into the loop (one joystick gets values, one index array, three branches of the button value) - mostly because these actions are related (increase cohesion).

Re: motor programming
 

I advise against moving the part intended for Teleop into the loop. If you do that, the elevator motor will always run at least as long as the brake motor. A brief tap of the button will not result in a brief movement of the elevator that way.

Re: motor programming
 

Please don't add superstitions. That's actively harmful.

As Alan said, the code must be separated.

Re: motor programming
 

Perhaps I should have been more clear.

Re: motor programming
 

In what way is your proposed change superior to what Mark posted?

Re: motor programming
 

That won't work right either. While the brake motor is running, the button state isn't being read. I don't have LabVIEW installed on the computer I'm using, but it looks like the brake motor is going to continually run five seconds in reverse, then pause for an instant and do it again. I suspect some of the wiring is swapped from where it ought to be. However, adding the other button for the other elevator direction won't be straightforward. You're overthinking things and getting requirements confused with theoretical "best practices" that are based more on hearsay than on reality.

Re: motor programming
 

I was missing a case structure, but we need to remember that the point of FRC is not to develop hacks and bad programming habits.
As far as not reading the joystick again during the entire engage/disengage of the break, that is almost necessary unless a sensor is implemented or they choose to implement a piston or some other two state actuator.

Re: motor programming
 

Again, I don't have access to LabVIEW to look at the other cases, but it still looks like your code is going to require the elevator to run for at least five seconds when the button is pressed, and will require it to stay stopped for at least five seconds when the button is released. That does not meet the requirements given by the person asking for help.

And it still doesn't account for the second button.