motor programming

[itwasntme455]

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.

[Alan Anderson]

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?

[itwasntme455]

Originally Posted by Alan Anderson

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?

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.

[Mark McLeod]

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)

[Alan Anderson]

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.

[itwasntme455]

Originally Posted by Alan Anderson

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.

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?

[mshafer1]

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.

[itwasntme455]

Originally Posted by mshafer1

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.

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.

[Alan Anderson]

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.

[mshafer1]

Originally Posted by Alan Anderson

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.

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).

[itwasntme455]

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.

[Mark McLeod]

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.

[itwasntme455]

Originally Posted by Mark McLeod

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.

Where do i find those green arrows?

[Alan Anderson]

Originally Posted by itwasntme455

Where do i find those green arrows?

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.

[itwasntme455]

Originally Posted by Mark McLeod

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.

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