LabView question
 

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

Re: LabView question
 

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.

Re: LabView question
 

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)

Re: LabView question
 

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.

Re: LabView question
 

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

Re: LabView question
 

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. 30ms is 0.03s. Roughly 30Hz, which is right around the same speed our eyes operate at.

Re: LabView question
 

[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"?

Re: LabView question
 

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

Re: LabView question
 

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.

Re: LabView question
 

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.

Re: LabView question
 

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.

Re: LabView question
 

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

Re: LabView question
 

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

Re: LabView question
 

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.

Re: LabView question
 

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

Re: LabView question
 

Store the VI files anywhere on our hard drive. Where depends on how you have your code organized.
Then add the VI to your robot project under Team Code. Or some where else depending on how YOU have your code organized.

If you where asking where to place the VI inside your program the short answer is any where you needed it.
I need to know more about what it is you are trying to do.

The Hold and Release is well suited for the teleop loops for any action you need to be true for a set amount of time.
It is designed to be inside a continuous loop, keeping track of a timer. You set it by driving the Boolean In HIGH. The Boolean Output State will then go high. You keep calling the VI inside your loop and the Boolean Output will remain high until the HoldTime has passed. As you constantly continue to call the VI when the HoldTime as passed the Boolean Output State will go low turn off what ever you had it connected to.

Tell me a little more about what it is you are trying to do.

Re: LabView question
 

Omar, I am trying to adapt your hold and release for my teleop program. It is to delay a solenoid firing. The solenoid is usually always true, but when it gets a false value, I want a slight delay in the false getting to the solenoid. (because this false value is also going to another action, and I want that action to complete first).

action A
Action B - solenoid firing

So it would go like this
Solenoid firing
button pressed which activates action A and B
action A completes first
action B completes later because of delay

So since it is going from true to false, it would be the "falling edge", right? So I would wire the boolean into hold and release, but invert it going in so it adapts for the rising edge that yours is built for, right? Then I invert it going out of the hold and release. Will this work for me?

EDIT: Forget the inversion part, I see the VI has the option for falling edge. I will test this out

Re: LabView question
 

Well you want something a little different. You want to delay the reaction to a Boolean changing state.
You want to “hold back” the Boolean state by some amount.

This is what I came up with.
My first cut was fairly simple, but failed in what was to happen if the BooleanIn changed back to it’s original state before the delay timed out?
So I had to rethink it.

Each time the Boolean In changes state I calculate the delay time and take the state and “queue” them in an array.
Then I check the 1st item in the array to see if the time has passed, if so the Boolean state is passed to Boolean out and that item is removed from the array.

If the array is empty the current state of Boolean IN is just passed to Boolean Out.

The Boolean Out state will track the Boolean IN state but delayed by a set about of time.

This VI is Reentrant so you can use it in multiple places

Enjoy

Re: LabView question
 

Hi. I was using this example to provide a similar timer for kicking, automatically retracting and then waiting another delay to ensure the 2 second rule is followed. However, there is a note on the screen shot for the vi that I cannot seem to figure out how to do in Labview.
To quote the screenshot, "In order to paste this structure in the Teleop.vi, you'll need to put the shift register onto the outer while loop of Robotmain."

My question is; I can put a shift register onto the Robotmain while loop, but how do I connect it to the Teleop vi? It seems as though I need to create some connectivity between the Teleop.vi and the shift register, but I am 'fishing' around in Labview and can't seem to figure that out.
Any advice would be appreciated.

Re: LabView question
 

There are two common ways of keeping state data from iteration to iteration. The comment is encouraging you to pass the data into the subVI, out of the subVI, and then recirculate it in a shift register in robotMain. This will work fine, but it involves modifying the connector pane on the TeleOp. To do this, you right click on the upper right icon on the panel of TeleOp, Show the Connector Pane, and you add controls and indicators to the connector.

The second way of doing this is to keep the state data private within TeleOp. Unless you need to modify the data in Robot Main, this is actually the method I'd suggest. To keep the state data private, you use a shift register or feedback node within TeleOp. If you do not figure it out, post again with the issue you got stuck on.

Greg McKaskle

Re: LabView question
 

Thanks.
I did in fact add a connector to the Teleop.vi and tried to connect the shift register in robot main. I was able to put the shift register on the while loop in robot main, but I have a single connection point in the teleop.vi when it seems I should have 2 connections (one for each side of the shift register). I am a little confused as the timer value passes through one of my case structures (tapped off to check stored time against current time) and I am not sure what labview 'part' to connect to the input and output of the timer value passing in and out of Teleop.vi (I have an Enum connection on the input side, but I'm pretty sure that is incorrect).
As far as your suggestion for 'private' data, that would be fine as well. I did not have a while loop within teleop. Can I just put a while loop around the teleop 'execute', default case statement in and run the while loop continuously? Or can I just use the feedback node to pass data within teleop (I could guess on how to do this, but would appreciate help).
In looking at this last night - I didn't want to 'muck' around too much with robot main's modular design, but I am a Labview novice still and I didn't know another way to do this.

Re: LabView question
 

The thing that my example pics don't show is the unbundle and bundle operations that I typically perform when using the RobotMain shift register. (My pics show a single variable, but my/our team code has a cluster of data in that shift reg)

In any of the VI's that use the shift-reg, upon entry I unbundle a couple variables out of the shift-reg, act on them, then if there is an update, rebundle it into the shift-reg on the way out of the VI.

If you haven't checked it out yet, I'd recommend the FRC Mastery video on state machines. That's where I learned about using shift registers.

http://frcmastery.com/try-me/state-machines/


Greg's advice on keeping the data private is good. The primary reason I/we are doing things in the RobotMain while loop is we found ourselves doing the same thing in both TeleOp and Auton ... so we use the same variables in either case and it made sense to just wire up the same shift-reg to both our Teleop and Auton VI's.

Re: LabView question
 

I went through the FRC mastery videos for the shift register topic. I guess I have to do it again after working in Labview for a bit. I find that the best way to learn this is to use the application, but that can be slow.

I do not have access to the videos here (at work), so I am relegated to watching it at home.

I can see that you could use the same timer in Autonomous and why you'd want the shift register in that while loop - makes sense.

Thanks for the help...I'm getting there (slowly but surely).

Re: LabView question
 

For the private implementation, you can use either the feedback node or you can add a loop that executes for only one iteration and place the shift register on the loop. You do not want a continuous loop or your teleop will not return in time for another teleop packet to be processed.

There is very little difference between the runtime behavior of the shift register and feedback node. The shift register can be grown to hold multiple iterations of data, but the feedback node is slightly easier to initialize. The choice of which to use is largely a matter of choice.

Greg McKaskle