Variables, Cameras, and Wait

[dfu1234]

THANK YOU!

Ok, so, I REALLY like the idea of putting all that processing onto the computer, but I need help with how to actually incorporated it. Do I just extract the folder somewhere and then add the folder via import, or should I put all of these in their proper file location?

Offputting it to a computer also means I can do the actual math instead of a look-up table .

Thanks for all the detail information on the camera. I will try to incorporated (well, not try. HAVE to) later, when I meet up with my team. Let's hope the none-encoded SPIKE is easy enough to set up.

And, the wait command is like this. In Teleop.vi, I want to use a button to change a Boolean variable back and forth. So, I currently have a sort of t flip flop with the button and the variable as the inputs. Here is a picture of it:

Before anyone comments on a glaring flaw in this, there will soon be a while loop in it with button nine the determinate.

What I want to avoid is this: Person presses button 9; Gyro is true. Next tick: Output false into gyro. Next tick: HEY LOOK! Inverse Gyro is true and Button Nine Pressed is true. Let's output and change it! Next tick: etc etc so on and so forth. Considering how fast ticks are, this could utterly screw me. THAT is what I want a wait command/block for.


Team 3595 Massive Attack thanks you heartily.

[dfu1234]

Um, in which vi do I put the math? And, what are the output variables? Like I said earlier, I am completely new to labview. After putting this in the project, I am at a loss of what to do. Please help. We are literally at competition right now (practice day, but still.)

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

[blackflame2996]

just extract it anywhere, all of the dependencies are in the folder. open the project, and build the exe to use the dashboard. sorry it took so long to respond, had a regional.

[MAldridge]

This is my solution to the toggle (see attached). At some point, I will do a write up on the advantages of doing it this way. Essentially, you put 'Grand Unified Button Handler' in your periodic tasks in a 15Hz loop and read your joysticks into it there; then you pull the outputs into a global and read the global wherever you need it. In the GRUB main vi, there is a control labeled 'latched?' you set which ones are latchable and then you set current as default, that way you can quickly change a button from latching to non-latching without rewriting large sections of code.