Joystick Button One-Shot (a.k.a. Rising Edge) Detection

[Ziaholic]

I've used this picture a couple times in recent days ... used to help provide advice on joystick buttons and throttle.

Now the shoe is on the other foot and I'd like to ask for some advice.

I wasn't the SW mentor last year, but I seem to remember a VI/block that let you detect the rising edge of a joystick button. I can't seem to find it in this year's LabView installation.

In the linked picture, buttons 3,4, & 5 are used to determine the next state of the Drive state-machine. The image shows some code from the Normal Drive state. When 3 or 4 or 5 is pressed, I set some variables and the next time through the loop, the state will change to the next state. After the maneuver is complete, the state goes back to Normal.

Problem is, if the driver leaves their finger on the button, then it will only stay in the normal state for one cycle, then immediately transition into the maneuver again, over and over and over. I'd rather require the operator to press the button again.

My current band-aid solution is to use a timer (not shown) where I grab the current time when the button is pressed, add a one-second offset, and store it in the Drive shift register. While the current time is less than the offset time, I disable the buttons by AND-ing them with a FALSE. When the current time is greater than the offset time, I re-enable the buttons by AND-ing them with a TRUE.

It'd be a lot cleaner if I could simply drop a box in there that would detect the rising edge.

Any tips/tricks/advice would be greatly appreciated.

Thanks.

[Joe Ross]

Here's what we did. http://forums.usfirst.org/showthread.php?t=10544

[Doug Norman]

Take a look at the Joystick Button Latching example we added this year. It will show you how to do it. Once you understand it, you may want to create a simple subVI that can be put in a loop to do the same thing.

[Alan Anderson]

I use a feedback node and a tiny bit of logic to get a single "true" pulse output when the input changes from false to true. It's so simple that I don't feel a need to encapsulate it as a vi.

[Ziaholic]

All very good advice. Thanks.

The Labview example is good ... but it's a latching toggle ... and I'm in the market for a one-shot. I could use that structure to create a one-shot, but I'd prefer a more elegant solution.

I've never used one before, but wouldn't a simple feedback node be able to help me. That is, I'd only enter into the new state case if the button is TRUE now, and was FALSE the last time thru.

I'll play with it at this afternoon's session and report back later.

Thanks again.


[edit] ... Nice one Alan! That's exactly what I was picturing in my head.

[Doug Norman]

Here's a code snippet (picture) that does what you want. You could put this in your loop, or you could make it a subVI. If you make it a subVI to be used in multiple places, be sure to make it a reentrant subVI. That way it will allocate separate memory for each call. To make a subVI reentrant go to File>>VI Properties>>Execution and choose Reentrant execution.

[Ziaholic]

I'm not familiar with that double-lined-arrow icon in Doug's pic ...

I don't have access to Labview at the moment ... what's it called?

[Alan Anderson]

Originally Posted by Ziaholic

I'm not familiar with that double-lined-arrow icon in Doug's pic ...

I don't have access to Labview at the moment ... what's it called?

It's an "implies" gate. The output is FALSE only when the first input is TRUE and the second input is FALSE.

[Ziaholic]

[shrugs] It might do the same thing, with the same number of gates, but it's easier for me to read the simple "AND" with the previous inverted value.

Ta-MAY-toe, Ta-MAH-toe ...

Thanks again.

[Omar]

I like to use the the greater than/less than on booleans for edge detect

[Racer26]

Originally Posted by Omar

I like to use the the greater than/less than on booleans for edge detect

That certainly is elegant.

Theres also a VI in the OpenG toolkit, (can be acquired through the VI Package Manager) which is called "Boolean Trigger" it takes a boolean in, and has a rising edge and falling edge output.

I never much liked Feedback nodes... They make it difficult to comprehend whats going on. To me a shift register makes more visual sense, despite being functionally the same.

[Alan Anderson]

Originally Posted by Omar

I like to use the the greater than/less than on booleans for edge detect

That's beautiful.

[D Peterschick]

Is there anyway to use a limit switch to stop a motor and then be able to restart with Joystick?

[Alan Anderson]

Originally Posted by D Peterschick

Is there anyway to use a limit switch to stop a motor and then be able to restart with Joystick?

Do you mean to use the joystick to move the motor in the opposite direction, away from the limit? That's easy. Just have the limit switch keep the motor control value from going less* than zero.

Or do you mean to use the joystick to cause the motor to ignore the limit and go past it? You can do it, but it goes against the usual purpose of a limit switch, and I'd have to know more about the system before giving any advice.

(* or greater, depending on wiring)

[Omar]

Originally Posted by 1075guy

I never much liked Feedback nodes... They make it difficult to comprehend whats going on. To me a shift register makes more visual sense, despite being functionally the same.

I agree, I use Shift Registers far more often than I use Feedback nodes because I too find the feedback node harder to comprehend.

But in this simple application I like the less real estate that the feedback node uses

Posted is another way to implement a Boolean Edge detect that 1075guy speaks of.

Omar