11-11-2010 04:48 PM
I have been using local variables to access the front panel controls/indicators from multiple places in my vi. Some of the indicators are used many times in different cases. Is there some other way to do this? shift registers? or is local variables the best way.
11-11-2010 05:59 PM
Local Variables are almost NEVER a good choice to do what you are proposing, for a multitude of reasons which have been talked about extensively on this forum. Yes, shift registers are the best. If you can't access the data with a S/R, because the data has to be read/written in a separate loop or inside a VI, then the Queue or Notifier can be used. Again, avoid the local variable - you are setting yourself up for misery.
11-11-2010 07:38 PM
I did try searching the forum, but there are so many articles. I read one article from a certified developer and he says that local variables are the only way to access front panel controls and indicators. I could not find any thing on how to do that will shift registers; can suggest how to do that?
11-11-2010 07:53 PM
If you are going to quote a post, provide a link to it. In certain conditions a local is the only way to do certain things. A local is NOT to be used to simply make a block diagram 'neater' to avoid long wire runs or bad design.
11-11-2010 07:57 PM - edited 11-11-2010 07:58 PM
There is one more best option compared to local variable is using the functional globals. You can change the functional globals anywhere in any VI and update the value of the control or indicator in the front panel in a place like timeout in the Event structure.
11-12-2010 07:13 AM - edited 11-12-2010 07:20 AM
Manatee,
Attached is my controversial demo showing several ways to access data. This is more for communicating between loops. Download all three VI's into a folder and run the big one. (I should have zipped them but for some reason I can't at the moment).
As Dennis alluded, some people will use locals simply to keep from having to wire stuff - the way you might see an electrical schematic using "port entries" or off-page net labels to hook up wires so that the schematic does not have a lot of crossed wires. DON'T do that in LabVIEW. This is a programming language, not a graphics program.
Regarding functional globals, they are great, as the other poster mentioned, and my demo shows the use. When you get time, read Ben's post about Action Engines, which are the same as functional globals (in their simple form at least) and are also the same as LV2 Style Globals, so don't be confused if you see those three terms used interchangeably (functional globals, action engines, LV2 style globals).
11-12-2010 07:47 AM
Ok, thanks. I have downloaded the vi's and will be looking at them. Thank you for being patient with me. What spurred this thread for me is having to clean up someone else's code who used local variable's for everything. In my study of labview I have read over and over again, not to use local variables; so I am trying to reconstruct the program without local variables.
11-12-2010 07:51 AM
Nice Example Broken Arrow.... Good...
11-12-2010 08:47 AM
@br.anand wrote:
Nice Example Broken Arrow....
Thanks. The reason I said the demo was "controversial" is that I've posted it before and had negative response. It needs to be understood that there are many ways of passing data, and this demo simply shows some of them, for better (Queue) or worse (global). The demo doesn't pass judgment, just data.
![]()
11-13-2010 09:46 PM
Well, lets say you have a case structure with many cases, each of which report back to the front panel. Well in one case there are three visa writes, each of which expect an acknowldge back from the serial device. So then in this case alone, it requires three writes to the same front panel indicator. Well I can directly wire one to the front panel indicator, but what to do with the other two writes? Local variable: global variable: shared variable? if I could figure a way to get the three writes wired to the indicator, then I could succeed at data flow programming. Its as if I have failed at data flow programming when I have to resort to any kind of variable.