Global Variables still don't work with NXT Brick! Desperately need help!

[EDNEDN]

We have been trying and trying to get global variables to work with the NXT Brick.  We have the problem reduced down to a very small code base.   Everything seems fine until we try to tarket the code generator to the NXT.   At that point, we get errors on both of our VI's that share the global variable.  But it won't tell us what it doesn't like.

Please...  Please...   Please...   Can somebody that knows about this stuff please load up our module and see if you can tell us what we are doing wrong?    We really really need help!

What we have is one VI watching for a button to be pressed on the NXT.  When that happens, it increments the global variable that is used by the other VI.  The other VI will play more and more beeps as the global variable gets incremented.   (at least...  If we could get this to compile and run, that is what it is supposed to do)

Thanks so much!

[pallen]

It's been some time since I've worked with NXTs, and I don't currently have the software installed on this PC.  So I can't test whether Globals work at all on the NXT. 

What I can do is offer a suggestion to try something else.  My suggestion is to try what's known as a LabVIEW 2 Style Global or a Functional Global.  (Sometimes called an Action Engine) 

Just drop this VI where you want to send or recieve data.  It's a pretty simple VI, so have a look at the code to see how it works.  You can use this method to pass any kind of data to multiple locations.  Just remember that with any global variable that you need to be careful about race conditions. 

[Jokelnice]

HI,

According to your comment I can say this ..

1. Local variables do not work in the target of the Lego NXT, unless you work in Host mode, (which is how I think you are working)

2. So that the use of global variables? .. The main function of the global variable is to share information between applications, which can not be done with the Lego NXT Target.

recommendations

1. It is advisable to work in Target mode, with the Lego NXT

2. According to the description made about what you want to do with the program, you just need a program to do this and not two.

The program looks like this:

[EDNEDN]

We understand this test program could be done as a single program.   We constructed the test program because we wanted a simple case that failed so it would be easier for people to help us.  

The reason we want to use global variables is because our main program will read in several types of light sensor configuration data and we are being forced to pass that into every sub-Vi and it's sub-VI's to make sure it is available to what ever needs it.   Loading these configuration values into global variables would make things much easier because any sub-VI that needed it could just access it.

We will examine the other option suggested with the Functional Global.   Hopefully, something will work out for us.

[EDNEDN]

Hi Patrick!!!   I think what you are suggesting will work for us.   Can we ask you are couple of questions?

We need 4 different global variables.   Would we create 4 different instances of this VI with each control panel changed to reflect the name of it's global variable?   

And from a code generation perspective, how does this VI work?   I'm thinking when a value gets written to it, until that value gets changed, its available on the output.   In our case, we can set our global configuration data just once at the start of the program.   But what happens if you need to change the value again and again in different VI's ?   Doesn't the code in this VI get replicated and result in many places where data is being stored instead of just one place?  

Anyway...  Thank you so much for the suggestion!!!!  

[EDNEDN]

Hey Patrick!!!  We made a copy of that VI for each global variable we needed and changed its control panel to reflect the variable's name.   And then we did just as you suggested.   Any place we needed to reference the global variable, we dropped that VI onto our block diagram and set the mode to either read or write.

We haven't tested things very hard yet, but it sure seems like your idea works for us!   You are a life saver!  

Thanks so much!

[pallen]

Glad to hear that worked for you. 

Functional Globals are simple code, but very useful.  Understanding how they work is important though. 

The key to the Functional Global is the uninitialized Shift Register.  What that means is that whenever you run the VI, the value in the shift register is the value that was written there on the last run.  This means you need to make sure that you always write something to your FG before you try to read from it. 

A functional global isn't limited to just one variable either.  You can have as many variables as you can make connectors for.  Or, use clusters and you can pass anything you want in a 'group'. 

Good luck with the rest of your code!

[EDNEDN]

Is it necessary to use the 'Init' function?   Can I just write to the shift register once before I use it?   From looking at the functional block diagram it would seem that would be OK, but I'm seeing some erratic behaviour and I'm wondering if I'm getting a bad value occasionally from the global variable.   Also, is there any problem with multiple threads reading the same global variable and causing a race condition?  I'm not doing that yet, but I don't need any extra problems!!!

Can you explain how this works?  The reason I'm asking is I'm confused.  I thought on the NXT Brick, each VI got replicated by the code generator for each time it is used.   If that is the case, then it would seem the approach used to impliment this VI would not work because there would be shift registers all over the place in the generated code, but only one holding the correct value???

Any way...   Thanks so much for your help so far...   And Thank You for any further guidance you can offer!!!

[pallen]

You guessed right, you can just write to the FG if you want rather than initialize it.  However, it's usually a good programming practice to have an Initialize 'state' where you know for sure things are initialized.  Using the same variable in multiple locations isn't a problem.  You just need to know where you're writing to it. 

You shouldn't be getting an occasional 'bad value'.  Use a breakpoint to see when you're writing to the FG.

There's some info on how the FG works here:  http://labviewwiki.org/Functional_global_variable

---

EDNEDN wrote:  I thought on the NXT Brick, each VI got replicated by the code generator for each time it is used.   If that is the case, then it would seem the approach used to impliment this VI would not work because there would be shift registers all over the place in the generated code, but only one holding the correct value???

---

I'm not 100% sure about this.  What you're writing here would suggest that every SubVI would be reentrant.  I don't think this is the case.  I quick scan of the programming guide didn't indicate that it was.

I'm not sure where you're at in your project.  But my company put together some training materials that might be helpful.  http://nxtmastery.com/

Good luck.