LabView question

[dekker120]

ok.. I looked at the examples for creating a latching button... but does anyone know how to create a delayed button... (i.e. you press a button and it retains the value of true for x seconds/milliseconds and then resets to false).

[Ziaholic]

I'd use a state-machine sort of case structure, with a shift register.

When the button is initially pressed, you enter into the START state and read the current time, add your offset time and write it into the shift register. You'd also write the next state into the shift register ... named something like "WAITING".

In the WAITING state, you'd check the current time and the stored time in the shift register. If the current time is still less than the stored time, stay in the WAITING state. Once the current time is greater than the stored time, you exit the WAITING state.

There is a good example of State Machines and shift registers at the LabView Mastery website.

[dekker120]

Ok... Could you post a pic with an example of that... (As you may have noticed, I am the electrical guy... We lost all our programmers... And I am somewhat lost)

[Racer26]

Attached is a JPG of a VI i just wrote that does this.

Click the button, button stays down for 1000ms (1s) and then comes up.

[kws4000]

Can this be dropped directly into the TELEOP subvi and used to run solenoids just the way it is?
Right now all I have are the solenoids being called and being fed the joystick value TorF, and they are just sitting inside the "Execute Default" case structure. I know these have to be maintained for at least 30ms; how can this be worked into your example?

Thanks

[Racer26]

I don't think it can. I have not used LabVIEW for the FRC robots, I use it in my work, however, my understanding of how it works says you couldn't simply drop this in. However, you can adapt the concept of it (measuring the time between now and when you pushed the button).

On a simplicity note: Why not just have your drivers ensure they hold the button down for at least 30ms? 30ms is not a very long time, and chances are good that your drivers already ARE holding the button for this long. I remember always having to code my robots to trap the rising edge of a button, because if i used the buttons on/off state, I would read many more "on"'s than one.

EDIT: ie.

 
if( oldButtonState == off && ButtonState == on) {
//do some stuff
}
oldButtonState = ButtonState;

30ms is 0.03s. Roughly 30Hz, which is right around the same speed our eyes operate at.

[kws4000]

[quote=1075guy;916533] I remember always having to code my robots to trap the rising edge of a button, because if i used the buttons on/off state, I would read many more "on"'s than one.


What do you mean by "the rising edge of the button"? and "many more on's than one"?

[kws4000]

Han on, here's an image of where I'm at.

[Racer26]

a button is a digital signal. It can either be on or off. The transition between the on and off states is called an edge. It is described as rising (off->on) or falling (on->off). You can either just use the state of the button (on or off) to drive your code, or you can use the edge to drive your code.

Consider a 'start' button, that causes a sequence of things to happen.

If you trigger it on the state of the on button, what happens when the button is "on" for more than one consecutive cycle?

If you trigger it on the rising edge, (ie. the button was off on the last cycle, and its on now), then it doesnt matter how long you hold the button.

Which method you choose depends on the action you want.

EDIT: In order to do this, you must store the state of the button from the previous iteration.

EDIT2: I just built a small VI to clock my mouse click. It takes me on average 40ms to quickly click and release the button on my mouse. I saw times as low as 8ms on a particularly fast cycle.

[kws4000]

I posted just a minute before you while you were writng your response. Scroll up and find enclosed attachment of where I am on coordinating solenoids.

[Ziaholic]

I had a similar problem to solve, so I whipped up a quick VI to show you what's involved in getting the trigger to set off a timed sequence that lasts longer than the 20 msec DS packet times.

You could simply keep what you've got, and tell the driver to just tap the trigger, and it'd work OK. Your 30 msec requirement is only 2 "cycles" of the standard 20 msec main-loop timer. Tapping the button would pretty much get what you want.

But if you want the SW to take care of it for you, and allow for "driver error", or if you need it to last for 300 msec, then you'll need to get familiar with shift registers.

This isn't exactly cut/pasteable into your code, this is advanced stuff. It'd be safer for you if you created it for yourself ... maybe using the attached pics as a guide.

One of the pics shows the TRUE case, where the trigger has just been sensed as going from FALSE to TRUE. The other shows the FALSE case which gets executed until the driver2 lifts and eventually re-presses the trigger.

I didn't make a third pic, but the unshown case in the FALSE pic has nothing in it at all. While that inner-case is TRUE, you're doing nothing, waiting for the timer to go off.

[Omar]

This VI will detect a “rising edge” of a Boolean In and will latch and hold the Boolean output high for a set amount of time passed in as HoldTime. The hold time is in sec.

Feed the joystick button into the Boolean In and connect the Boolean Out to what you wish to control.

This VI is set to “Reentrant Execution” with Preallocate clone for each instance so it can be use in many different places and get will keep separate time.

Omar
Huntsville, AL

[kws4000]

Ziaholic, thanks for the assurance that I just have to hold button 1 in order to achieve the same effects.

Omar, I'm not exactly sure how your sample VIs work, except that they do work.

Anyway, thanks a whole bunch, all of you!

Now, to get the robot over the hump with a half dead battery...

[Omar]

Originally Posted by kws4000

Omar, I'm not exactly sure how your sample VIs work, except that they do work.

You would only need it if you needed precise timing that repeats each time you press a button.

When you first press a button the VI calculates the release time and stores it in the Feedback Node.
Each time around your outer loop the VI is called and checks if the release time has been passed. If so it set the output to false.

If you press and hold the button or press and quickly release the button, you will always get an active high for the same amount of time defined by release time.

[lucoytoa]

Omar, where should I save the codes to work? I've deployed the 2 codes but my 2nd joystick is still not moving