Functional Globals in LV 8.5

[GobbleDiGhoul]

Hello all!

I've been struggling with making a functional global in LabView 8.5. I'm a very new programmer, my job is basically to learn LV online and check/optimize code left by a previous programmer. His code uses a large number of local variables, many of which feed into custom subVIs, so I was thinking that functional globals may be a good way to improve the code. I've read that local variables are something of a no-no, but he uses them for passing specific data between a producer/consumer loop (apart from data in the queue). However, I've been having difficulty grasping the concepts behind the functional globals, and when I've looked for examples in the forums I have only found examples from older/newer versions that won't work for me. I think that some esserntial concept is eluding me.

So, I have three questions if you all have time.

1) How exactly do functional globals work?

2) Are they possible in LabView 8.5? My company doesn't want to update for fear of damaging the code we have.

3) Might functional globals be faster than local variables?

Thank you all for your time!

-Gobble

[johnsold]

Gobble,

1). Look at Ben's Nugget on Action Engines.  An Action Engine is an enhanced functional global.  Basically the functional global is a subVI containing a while loop with an uninitialized shift register which does one iteration of the loop each time the subVI is called.  The Uninitialized shift register retains the last value until it is called again.

2). Yes.  They have been used since LV 2.  They are sometimes called LV2 globals, because LV did not have a native global variable at that time.

3). They may not be faster but they will not cause race conditions which is one of the major problems with standard local and global variables.

Lynn

[Ben]

Here is a link to the Nugget Lynn mentioned.

Two points to add:

AE's are faster than locals.

When you design your AE, include an Action for each operation performed on the data and do the work IN THE AE to ensure you don't have race conditions.

have fun and I hope that Nugget helps.

Ben

[GobbleDiGhoul]

Thank you, Lynn!

I have seen Ben's nugget on action engines (I thought I bookmarked it, but I can always just search it) but I haven't been able to successfully construct one on my own. I assume that is my own mistake, but I think it's because I'm confused by the "uninitialized shift register." When I tried to build a FG that looked like the attached image (from Ben's nugget, thank you Ben!) all the wires broke, and I'm unsure why.

However, if FG aren't faster than local variables, then they may not be of use to me. I have looked through the program several times, and there are no circumstances I can see where a variable can be written and read at the same or bad times. I would still like to replace them as a matter of good programming practice, but I might just push them down on the priority list, and hopefully my knowledge of labview will be greater by the time I get there.

Thanks for your time and answers, Lynn!

-Gobble

[GobbleDiGhoul]

Thank you, Ben!

I'll try reading through the nugget again, hopefully this time I'll catch whatever I missed. I do think this would be a good way to improve my predecessor's code.

-Gobble

[Ben]

THe wire to the SR will break if LV is confused about what it should be (what type) where the wire comes from (multiple sources) or if you are not specific (wire different types in different actions).

Use yoour help window with the wire tool selected and read what LV has to say about the wire when you float over it.

Take care,

Ben

[GobbleDiGhoul]

Thank you for that troubleshooting advice, Ben. I am getting the warning "wire is connected to an undirected terminal." Now that I look it is plain to see that labview doesn't know how to direct the data. However, while this is a simple error, it is one I have not come across before and I don't know how to fix it. How do I indicate to labview which way the data is to run?

Also, attached is my program (LV 8.5). Sorry I didn't attach it before, I figured the solution would be simple. It is pretty much identical to Ben's from the nugget. In the future I will always attach programs when my company will allow.

[RavensFan · Accepted solution]

You have two mistakes in your VI.  One in the Write case, the other at the stop terminal.

The error in the write case is what is causing the broken wire.  You have create a wire segment with two sources (one from the shift register, one from the control).

[johnsold]

In the Write case you have two wires connected to sources.  One is connected to Number In and the other is connected to the left terminal of the shift register.  Remove the wire segment between the left tunnel of the case structure connected to the shift register and the vertical wire coming from the Number in tunnel.  You will end up with a connection from Number In to the right side of the shift register and no connection to the left side of the shift register inside the Write case.

Lynn

[GobbleDiGhoul]

Raven and John,

Thank you both very much! I see my mistakes now, and it's obvious that I'm still sorely lacking in my understanding of labview. The program works now, but I think I'll wait before implementing it.

-Gobble