LabView question

[Omar]

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.

[masterspy7]

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

[Omar]

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

[sparks-1784]

Originally Posted by 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.

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.

[Greg McKaskle]

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

[sparks-1784]

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.

[Ziaholic]

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.

[sparks-1784]

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

[Greg McKaskle]

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