functional global variable memory allocation

[SergeB]

Hi there everyone and thanks in advance for any answers.

In my code, I am using a functional global variable to store an array of values so that I can read them later.

The user doing the testing uses 3 different executables. So he runs the first .exe, the test runs and the VI stop indicating the end of test, then he opens the next  executable, it runs and then stops, etc. My question is if I use a FGV to write the value while the first executable is running and then try to read the value while the 2nd or 3rd executable is running, will the value still remain in memory? At what point does the memory space for the data get erased? I did a little testing running 2 different VIs and writing and reading from FGV and it seems to work but there were times where the array of data was empty.  I'm not sure what I did to to get an empty array so I am trying to understand how it works. Any advice is appreciated.

Thanks!

Serge 

[GregFreeman · Accepted solution]

No, the variable will not persist between applications. You would have to write the contents to a file on disk, then reload them. May I ask why there are 3 applications? Seems a state machine and a single application would be a better solution.

[crossrulz]

Once an application is done and closed, all of its memory space is also closed.  Furthermore, a FGV is only application specific, meaning that it can't be used to talk between application instances or applications.  I'm with Greg, just make one application that calls the three VIs needed in a state machine.  With a single appliation instance, you can store the data in a FGV for the other ones to be able to read.

[SergeB]

Hi GregFreeman and crossrulz,

Yes, I agree on using a FSM. Unfortunately, this is someone else's code. I am simply adding a feature to it. There is a good amount of work needed to make it better and it is simply not worth it at this time. In addition, it won't be around for much longer.

You both answered my question. I was hoping I would have to avoid writing to file but I can still do it in the background and then delete the file when I'm done.

What if the user was doing this in LabVIEW and not using an executable, would it have the same effect?

Thanks,

Serge

[GregFreeman]

---

@SergeB wrote:

Hi GregFreeman and crossrulz,

Yes, I agree on using a FSM. Unfortunately, this is someone else's code. I am simply adding a feature to it. There is a good amount of work needed to make it better and it is simply not worth it at this time. In addition, it won't be around for much longer.

You both answered my question. I was hoping I would have to avoid writing to file but I can still do it in the background and then delete the file when I'm done.

What if the user was doing this in LabVIEW and not using an executable, would it have the same effect?

Thanks,

Serge

---

I think in this case the data would persist as long as the FGV didn't leave memory. Admittedly, I believe this is a poor way to do it. I don't like giving people access to the dev environment. It isn't that hard to write to a file, and if it's not a ton of data you can do it pretty quickly by just using array to spreadsheet string. I'd just turn your FGV into an Action engine, add a case for "write file" and "load file" and you'll be done. Just during each application startup, call load file, and each applications exit call save file. That's all you'll need to do and it should be simple. You can keep all the work within the same VI. So, now you'll have four cases "set, get, read file, write file." When you read the file, use spreadsheet string to array to get it back in an array format, and store it in the action engine. I also wouldn't delete the file, just use "create or replace" when you open it.

[SergeB]

Oh yea, definetly. The question was only to help alleviate my own curiosity. Not planning on having the development environment available.

Good call on the action engine, will do.

thanks.