Paramaterizing Case Statements
 

Hey all, i have a quick question. I know that in C, we could use variables in case statements (e.g. if(time_elapsed<time_to_intercept){...} (where time_to_intercept was calculated earlier in the code)). Is there any way we can do that in Labview?

Thanks!

Re: Paramaterizing Case Statements
 

Yes. And no. (there, that was simple, right?) :p

The problems is that your question is not as simple as it may seem. It really depends on exactly what you are asking.

Yes, you can perform a calculation and wire it to an indicator and then use the indicator's local variable later in the program to read back the value. However, in general, if you can keep your value in a wire (i.e. instead of using local variables), your code will be faster and use less memory.

Note that for the size of the FRC projects, this is really not likely to make a difference in performance, but it's something to keep in mind as you use LabVIEW.

If you are asking if you can actually evaluate expressions as part of the case statement itself, then the answer is no. All of the case expression needs to be evaluated up front prior to the actual case statement.

What you could do is use enumerated types or strings to help make the case statement more legible. If you pass in the enumerated type or string for which you wanted to execute code, the case statement would display text for each case (more like a C switch statement).

Re: Paramaterizing Case Statements
 

http://zone.ni.com/reference/en-XX/h...ce_structures/

You can use a range for your cases, as described in the page above.

Re: Paramaterizing Case Statements
 

That was what i wanted to know. Thanks. i'll deal with it by doing the logic outside the case structures and giving the results as booleans.

Re: Paramaterizing Case Statements
 

This question seems pretty much wrapped up, but I'll add one thing.

Because of dataflow, writing to a local in one location and reading for the case in another is usually not what you want. The local may well be read immediately, before you code writes to it. Wires don't do that. So to summarize, watch for race conditions and think in parallel when using local or global variables.

Greg McKaskle