Using local Variables for Shift Registers in LVLM

[Philbot]

In working through the various FTC/Tetrix VIs. I noticed some places where Local Variables are used in lieu of Shift Registers.

eg: Read Button States.vi

I know the NXT doesn't support free-floating Shift Registers, but It does support Shift Registers as part of a loop structure.

When learning LabVIEW with FRC, I learned that an "immediate exit" Loop structure (one that only executes once) can be used to replace stand alone Shift Registers, simply by adding the Shift register to the loop.

I guess this is commonly used in "Functional Globals", and in the case of the NXT, the only way to get a global variable.

I've also always been told to avoid using Local varibale unless absolutely necessary (kind of a LabVIEW mantra).

So this has prompted some questions:

1) Is there something with the NXT that makes Local variables more acceptable in this instance. 

2) Should the single-execute loops be avoiled (when used primarily to host shift registers).

3) Are the local variables initialized to the value that is displayed on the Front Panel.

4) Is there iny difference with regarding the scope and reentrancy of Local Variables vs Loop Shift Registers if the VI is used in several places?

Thanks for any guidance on this.

Phil.

[Kevin_F]

Hey Phil,

As far as local variables are concerned I would say that there are plenty of cases when coding in LabVIEW where they are the right choice. The general concern with local variables comes when you start using them instead of dataflow (just wiring two things together on the block diagram).  If it is a case where you cannot wire between the two locations where you need the data value - for instance in multiple cases of a case structure then it is perfectly ok to use local variables.  If you start to need a lot of local variables in your code then you may want to think of a way to restructure the code.  Local variables have a few downsides - they reduce readability of code because they create breaks in the datalow paradigm, if you are not careful you can introduce race conditions to your code if you are writing to the same variable from multiple places, and they create an extra memory allocation every time one is used.  Functional global variables help solve some of these issues since they only allow once access to the variable at a time and thus help prevent race conditions. They also use only a single memory location and are thus a little less memory intensive than using multiple local variable copies. To answer the rest of your questions I would say that using functional global variables (single-execute loops within a SubVI) is perfectly fine. Local variables are initialized to the value on the front panel.  Functional global variables are non-rentrant so they can only be used by one section of code at a time while Local Variables have no such restriction and are thus more likely to have race conditions.  Please post back if you have any additional questions on this.

[HunterSeeker]

1)The main issue with local varibale in LabVIEW is race conditions, if you don't control the execution order it can be hard to predict what will be stored in a varibale at any given time. In LabVIEW using data flow always protects from race conditions, you can enforce dataflow by connecting NXT terminals using seqence structures and error wires. As long as you make sure you have consistant behavior variables are fine.

2) Yes, you should use Functional Global Varibales. They are a great way to store data of all differnt kinds and build logic into your storage (IE running MAX or AVG) Be sure to check out Webcast 5,6&7 for more FTC specfic info on shift registers and state machines which can also be build into a functional global. In order for a functional global to be non-rein.

3) For local variables you can think of the front panel as the place where the data is stored, that value is the default. but you will need to go to Edit>Make front panel values default to lock in your setting so they will remain when you save and close.

4)Functional Globals are great if you need to use them in lots of places and want to add in security (mutex). Becasue the are non-retrant by default (File>VI Properties>Excecution), only one execution thread can use it at a time, but you can still have race conditions if you don't enforce data flow.

For more info on this topic check out this blog from one of our LabVIEW gurus. Brian introduces "Action Engines" which can be an awesomely powerful tool for programming.