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