How to do auto action during teleop in Labview?

We are trying to determine how to have some preset routines which will operate while in teleop. We would like to be able to push a button and have the arm go to set position, fire a pneumatic, turn on a bag motor for .5 sec., retract piston, and then back up.

We know how to do this sort of programming in the auto code without pushing a button, but we are having trouble to get same to implement while in teleop.

You probably need to look into doing these tasks in a different loop. Doing them in Teleop.vi would be very difficult.

You might also consider using Command & Control. I am one of the KC CSAs feel free to PM me and we can get into more details. If you guys really need help I might be able to come out there sometime

I usually put those kinds of actions in Periodic Tasks.vi

2 Likes

We have never used Periodic Tasks. We used the flat sequence structure for auto last year with decent success. Our thought was to use the same sort of idea but have it initiate after pushing a button. We would place the flat sequence in the Periodic Tasks? And then how do you trigger the periodic task.

Thanks for the assistance.

Periodic Tasks.vi is always running.
Put discrete activities into their own independent While forever loop, so they keep running and checking for the next button press.

I’ll make an example and add a picture to this post in a minute.


Periodic Tasks.vi (18.4 KB)

2 Likes

We might take you up on the offer to help if you are available later in the season. Right now we just want to get the robot assembled and kind of operational. We can “brute force” a lot of things in programming, but we would really like to see if we could make our coding a little bit more elegant.

1 Like

You would probably want to add a boolean to your robot global data and then in Teleop.vi write to that boolean.

Then in Periodic tasks you would read from that global and if it is true you would do your sequence and then at the end turn it back to false so you don’t run the sequence again.

This has several problems you will likely run into:

  1. This is a static plan, once you start it you can’t really get out of it unless you add some more complicated extra code.
  2. You may consider using a “State Machine” instead with your various steps. That would allow you to check if it wants to get aborted between steps and allow you to easily create new routines with the same steps without having to copy the code.
  3. None of these really consider how you would do two different steps in parallel without making a new step that contained both of them. Command and Control really helps with this!

Thanks. Did not realize it was that simple. We were over thinking it

Maybe consider creating a sub vi

Why would you choose this option over the one Mark posted? You can read the joystick press locally in Periodic Tasks. His feedback loop ensures it is only read the single time.

Is there a reason you’d want to use a global variable (violating one of coding’s most sacred rules) and set up a situation where it is being written two in multiple locations? This sounds like the start of a potential race condition that isn’t exactly a fun thing to debug.

Agreed that what Mark posted is better. I posted this well before he posted his code. I really don’t get much practice doing things “simple” like this as we do full C&C.

The reason to do it is that it is a lot simpler then some alternatives (like setting up a notifier assuming you couldn’t read the joystick in periodic tasks). There are a lot of things in this simple example I would not recommend for my reasons above but I understand its value in its simplicity.