motor programming
 

We need to make a motor turn to a certain point when a button is pushed and stopped even though the button is still being held.

Re: motor programming
 

I don't know what part of the goal you are having problems with. Would it help if you could get just a single indication that the button had been pressed, and not have to worry whether or not it had been released?

Re: motor programming
 

What we want to happen is when button A is pressed it will turn the motor for .5 seconds and button A will still be held down to continueslly turn another motor.

Re: motor programming
 

Treat them as two independent actions.

Do the .5 sec motor action in Periodic Tasks (here's an example from last year-note the joystick Get is no longer correct)
Do the while holding action in Teleop (another example, only implement the button 2 part of this example)

Re: motor programming
 

Here's how I would do it. This code can go in either Teleop or one of the Periodic Task loops.

The part with a green right-facing feedback node and a "greater than" is a standard LabVIEW idiom for getting a single TRUE pulse when a button is first pressed.

The part at the top left is computing a boolean output saying whether or not the current tick count has reached a saved value, and setting that value to 500 ms in the future when it gets the "button has just been pressed" signal.

Re: motor programming
 

ok, so next question is when we release button A we want the motor to go in the opposite direction for 5 seconds and stop. How would I do that?

Re: motor programming
 

It sounds like you need to use a state machine, there's several tutorials at This LabVIEW Tutorial Site, it sounds like you would have a forward, second motor, and reverse (or more descriptive for what those motors do). A state machine can be implemented in either periodic tasks or in Teleop (only caveat is that when done in Teleop, one either needs to insert a while loop that only runs once (constant on the terminal), or use the main program while loop and pass the data in and out of Teleop.

Re: motor programming
 

So the motor that will run constantly will control our elevator, when button A (move up) is held down or button B is held down(move down). The motor we want to run for 5 seconds one direction when button A or B is pressed will release a brake mechanism then when button A or B is released it will spin the motor back 5 second to the original spot to reengage the brake.

Re: motor programming
 

If you had given a fuller description of your requirements to begin with, we could have avoided giving half answers that don't quite do what you want. Keep that in mind for future times when you need more help than you let on. :-)

Is it possible to add some feedback to your "brake" system? Installing a pair of limit switches, so the software can tell when it's fully engaged or fully released, would help. If you can do that, the programming gets a whole lot easier.

If sensor feedback is not possible, then the suggestion of a state machine makes sense. You need a place to store the current state, either a global variable or a feedback node. You need to identify the inputs, in this case the A "up" and B "down" buttons. You need a timer, which the tick count code I presented can provide. And then you need to define what conditions cause the code to move from state to state, and what the motors are supposed to do in each state.

Re: motor programming
 

Mr. Anderson has made a good point, sensor feedback on the position of the elevator is more likely to work than timing - (that way the system can know if the brake is engaged yet or not). If contact through a limit switch is undesirable (which it may be in your case) you could consider a potentiometer or encoder on the brake motor or you could get a little adventurous using the IR sensors or a magnet and reed switch to detect of the brake is in proximity or not.

With regards to different actions in Timed tasks and teleop, it is advisable to only control a manipulator (including all subsystems of a given manipulator) in one place, in part for debugging (why is it doing that? . . . oh, it might be getting a signal from this other vi over in a different part of the code . . . not a good idea) and for simplicity (understandably).

Re: motor programming
 

Thanks for all the help but I am very confused. This is the first time I have used LabVIEW so some of the things you guys are suggesting isn't making since to me. Also our team doesn't have the resources to get some of the senors you are suggesting. Can someone give me an example to just make the motor turn for 5 seconds when button A or B is pressed and then turn 5 seconds in reverse when button A or B is released? Again thanks for all the help.

Re: motor programming
 

I think this does what you ask for one button.
However, adding a second button can bring some additional complexity to handle pressing both buttons at once and avoiding letting the release of one of them from trying to engage the brake with the other button is still powering the elevator.

It has two separate elements.
The hold the button action happens in Teleop.vi
The Disengage/Engage brake happens in Periodic Tasks (this can also be implemented using a state machine).

The important point is that the joystick can be checked and acted on anywhere as many times as you need.
In the Periodic Tasks example, one action must complete before the other action can occur, but you might want to restructure it a little to force an Engage to only follow a Disengage and vice versa. For the Periodic Tasks segment, I'd probably nest the Engage behind the Disengage in such a way that you cannot have two Engages or Disengages in a row.

When adding Button B you'll have to be careful that the motors do not get two conflicting orders at the same time.

In adding Button B to the Teleop code you'll have to use Selects to prioritize one button over the other.

Re: motor programming
 

Where do i find those green arrows?

Re: motor programming
 

Feedback nodes are in the Structures subpalette, along with While and For and Case blocks. They start out black when you place them, then change color to reflect the type of the wire connected to them. In this case, green for boolean. They point to the left by default, but can be switched to point the other direction on their right-click menu.

Re: motor programming
 

What is the wait 20 for in the bottom left corner?

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.