Variables, Cameras, and Wait

[Mark McLeod]

Do not put loops or waits in Teleop.vi
That would freeze your response to the driver controls and your robot will become jerky and uncontrollable running off to who knows where while your Teleop is waiting (and not processing new packets).

You need to find someone at the competition with you to look over your shoulder and give programming advice. Most events have a Control System Advisor (CSA) who you can ask for help. Pit Admin will know how to get you in touch with them. Also, check with nearby teams or Pit Admin/Help Desk may keep a list of teams that offer programming assistance.

[Greg McKaskle]

The problem with the code you attached is that it is simultaneously setting Gyro to the value of !(Gyro && Btn9) and to (Btn9 && !Gyro). Your code doesn't really say which should go first or last, and really, you probably meant to set the Gyro global only once on that diagram. If you wanted an if/else, that is called a case statement.

Perhaps what you were wanting to do was to invert Gyro once when button 9 is pressed, regardless of how long it is held. That would be more like the attached. It says that if the button is now true, but in the last message was false, invert the variable Gyro (except I didn't use a variable but a label).

If you wanted something else, please describe the desired behavior thoroughly and I or someone else can show how to do it.

By the way, the node I used, the feedback node is a special variable with very tight scoping so that it works well in parallel environments. It is a wire. No, its a variable. Actually its a piece of diagram state data that guarantees one reader, one writer, and allows for initialization. A related entity is the shift register.

As for your urge to use variables. It is a necessary part of many nonfunctional languages since they have no other good way to transfer data. It may be useful to think of a wire as an unnamed variable that you assign on the upstream/left end and read from on the downstream/right ends. Again, it is guaranteed to have one writer each iteration, and not only does it deliver the value, but allows the downstream element to execute. Functional languages like portions of LV, are very different from procedural languages, and strange at first, but very powerful and often very simple once you understand a few concepts.

Greg McKaskle

[blackflame2996]

I agree, variables are not necessary in LabVIEW. there are very few things that cannot be done with wires and feedback nodes. their main application in our code is transferring info between two sub VI's where wires, for some reason, did not work.