LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Strange combination of shift registers and boolean variables

Hi!
 
I've been given the task to improve a labview code made by someone that has left the company (and can't be reached) and came across this strange subVI which I have attached.
The VI is apparently supposed to read the boolean state of four buttons and light four corresponding LEDs accordingly. The whole subVI is put in a while loop that executes only once. Inside the loop the state of the buttons is read, which is OK, but then the values are wired to a shift register i connected to the while loop. The values are then retrieved from the while loop and compared to the former ones. My boolean algebra is a bit rusty, but as far as I can see the result of the ensuing manipulations is equivalent to lighting the lamps if the buttons return "1".  Do any of you have an idea why the designer has gone about this simple job in such a complicated way?
 
1) Why use the while loop that executes only once? Why use a while loop AT ALL in this case?
 
2) Why wire the booleans to a shift register?
 
I'll be grateful for any suggestions. The file is unfortunately in labview 8, an attempt to save for 7.1 failed.
 
regards,
Einar
0 Kudos
Message 1 of 9
(1,079 Views)
I didn't look at it, but typically, XORing the previous value with the current value will tell you that the control has changed. You may replace this with the event structure in newer versions of LabVIEW.
0 Kudos
Message 2 of 9
(1,067 Views)
Einar,

The get_buttons.vi is an example of the so-called functional global or LV2-style global. The while loop with uninitialized shft register(s) retains the previous value of the booleans to be compared to the current value. The logic in this VI does form a Switch to True detector. Each time the VI is called the LEDs will be true if the corresponding button changed from False to True since the previous call to this VI.

This structure (VI containing while loop with uninitialized shift register which executes one iteration on each call) is a very useful means of passing data between different parts of a program without some of the disadvantages of a local or global variable.

Lynn
Message 3 of 9
(1,067 Views)
Many thanks to both of you!
 
Your explanations make sense. The lamps controlled by this subVI were apparently used as indicators for which buttons the user was "allowed" to press.  It will take some time to figure out exactly how it all fits together, but I'm a huge step closer to understanding it now. As I understand it, there are many ways to both retrieve button states and turn LEDs on and off. Is the method used in "get_buttons" the preferred one, do you think?
 
regards,
Einar
0 Kudos
Message 4 of 9
(1,046 Views)
Einar,

It may depend on what you are trying to do. The Event structure is intended to make the user interface easier to program. The event structure presents both the current and previous values of a control, so you could do this without the shift register. If you end up rewriting the program, look at the event structure. If it is working well now, what you have should be OK. LabVIEW often provides multiple ways to solve a problem.

You can also use property nodes to control whether a a control is Enabled, Disabled, or Disabled and Grayed Out. You can use this to manage the user's access to controls at different states of the program.

Lynn
Message 5 of 9
(1,033 Views)
Highlighted
Einar,
 
While you are at it, here are some tips to streamline and simplify the code.
 
The original programmer used what I would call the "cluster detour" to indexing an array. Very long ago (LabVIEW 4?), this saved some diagram real estate, because "index array" was not resizeable, but now it just convoluted coding and jumping through extra flaming hoops. Smiley Surprised
 
I suggest to do the boolean math first, then index out the elements at the end. Why not operate on the array instead of each element seperately? See how much cleaner the diagram looks and there is no change in functionality. Smiley Happy
 
 
(The "first call?" in needed else the shift register remais at a zero size array).
 
Compare with the original:
 

Message Edited by altenbach on 03-15-200609:00 AM

Message Edited by altenbach on 03-15-200609:17 AM

Message Edited by altenbach on 03-15-200609:18 AM


LabVIEW Champion Do more with less code and in less time
Message 6 of 9
(1,023 Views)
Sorry, my above draft won't work because the array will have zero size from the shift register. You need to add a "fist call?" and initialize the array once.

LabVIEW Champion Do more with less code and in less time
Message 7 of 9
(1,013 Views)
I'm impressed! I've never gotten so much help from a discussion forum before. Thanks again!
 
Einar
 
 
0 Kudos
Message 8 of 9
(991 Views)

Hello Einar!

Glad you enjoy the forums and the help that you can get here. Otherwise I don't really have anything to add, all the other users input; explanations as well as ideas have been excellent!

Some information about this kind of variables can be found here:

http://zone.ni.com/devzone/conceptd.nsf/webmain/82e60e34e609c22a862569f8007e3f4a

The reason why many uses this kind of variable compared to local and global variables is well documented but this come from the 'LabVIEW Style Guide' manual
"Avoid the use of local variables when you can use a wire to transfer data. Every local variable that reads the data makes a copy of the data."

Regards,

Jimmie A.

Applications Engineer, National Instruments

 

 

 

Regards,
Jimmie Adolph
Systems Engineering Manager, National Instruments Northern European Region

0 Kudos
Message 9 of 9
(952 Views)