VI Data Spaces and LVLIBP/PPL - creating a truly singular instance

[Moray2000]

Hey,

my Scenario:

I have one executable and multiple modules which are built into packed libraries. The executable is just an entry point at the deployment PC and depends on these underlying libraries. One of those libraries contains also an central FGV and is used by some other PPLs. 

my Problem (or maybe misunderstanding):

I have to make some changes to one of the modules, so i open it with its project in my LV development system. This module depends on some data from the FGV PPL to allow me to debug and try it out properly. The data could be provided by just starting the executable and let it initialize everything - but when i do that, the instance of my module loaded in the development environment is not able to access any data on this FGV.

Looking through through some other forum entries it seems to me that each instance (the executable and dependent PPLs / the project in the dev environment) each load their own instance of the FGV PPL. 

My Questions:

Is that true that LV loads multiple instances?

Can you prevent this behaviour?

Shouldn't non reentrant behaviour of VIs prevent that already?

[Mark_Yedinak]

This is true. You would need to package your FGV into its own PPL and have all modules and PPLs use that single PPL with the FGV. To be honest, I would probably scrap the FGV and use a singleton class with a DVR to replace it. Again, this would be in its own PPL but a singleton class provides more functionality than a FGV.

[Moray2000]

The FGV is already in a separate PPL - other components/modules also have their own PPL too.

...so non-reentrancy is only valid in the scope of each project or PPL instance (and for their dependencies loaded with them)? Is there a way around this - i.e. only having truly one instance of this FGV in memory, shared between whoever calls it?

[Mark_Yedinak]

I would suggest changing your FGV to a class and use a DVR for the private data. Then callers would use accessors to get the data they want/need. We do most everything in classes now so it has been some time since I have really worked with FGV. I have not really tested using them across PPL boundaries. I do know that classes with their data in DVRs will work across PPL boundaries since you are accessing the data via accessors. In your initialization you can create the instance of the singleton class and then pass it's wire around your code. The DVR will guarantee that branched wires will be accessing the same data set.

What exactly are you storing in your FGV?

[Moray2000]

You may be right that LVOOP might be more sophisticated - I would just have to rewrite a lot of code 😕 The FGV is just for storing some paths, runtime parameters and references, nothing fancy.

This FGV is also working past PPL boundaries, as long as they are loaded in the same context (i.e from my exe/root library). But when i want to access this data from an Project in the development environment for debugging it wont share. A DVR would? 

[paul.r]

If an FGV doesnt work to do what you are trying to do, I don't see why a DVR would. If Mark has been able to use the same instance of a PPL in an exe and the development environment simultaneously, then your problem is likely not rooted in using an FGV but something else. 

Are you 100% sure you are pointing to the same PPL in the development environment as your built .exe is using?

[paul.r]

---

@Mark_Yedinak wrote:

This is true. You would need to package your FGV into its own PPL and have all modules and PPLs use that single PPL with the FGV. To be honest, I would probably scrap the FGV and use a singleton class with a DVR to replace it. Again, this would be in its own PPL but a singleton class provides more functionality than a FGV.

---

How do you create a singleton class without a FGV? 
 

[Moray2000]

I'm quite sure i'm referencing the same PPL in all cases. 

For example I can force the same behavior by creating two projects in the development environment and leaving them open simultaneously. Both are using the same PPL FGV (loaded from the same path) to store some data - and both projects seem to use different memory instances and are not sharing the data 😕

[paul.r]

Strange, I thought doing this was straightforward - I believe I worked on a project where we were using the same instance of a PPL between Teststand and completely separate .exe, but I built up a little demo and I am seeing the same issue as you - even with my FGV returning its path and indicating that the path between the built .exe call and the development environment call is exactly the same, they still don't seem to be sharing the same instance.  

[Mark_Yedinak]

---

@paul.r wrote:

---

@Mark_Yedinak wrote:

This is true. You would need to package your FGV into its own PPL and have all modules and PPLs use that single PPL with the FGV. To be honest, I would probably scrap the FGV and use a singleton class with a DVR to replace it. Again, this would be in its own PPL but a singleton class provides more functionality than a FGV.

---

How do you create a singleton class without a FGV? 
 

---

I didn't notice that the OP was trying to share information between an active application and the development environment at the same time. That will not work. The DVR or FGV will be in different memory spaces and thus will be different. In cases where I have had to share data between applications I use TCP based messaging to share the data. There is no other way. Based on the type of information that the OP is storing in the FGV, I would suggest that a configuration file is used which is read and then used by the application. This is relatively straightforward. You could use a common path to store the configuration file. The default application data folder on Windows (7 and above) is c:\Program Data. Create a subfolder there for your application and place the configuration file there. Both the development environment and the built application will be using the same config file.

As far as a class using a DVR without a FGV it is quite easy. The cluster of the class private data contains one or more DVRs to the actual private data. To instantiate the class you would use a Create method which would initialize the DVRs. The class wire will need to be passed through the code but all instances regardless of branches will be seeing the same data since everything is stored in DVRs. Copying the actual DVR reference is not a problem.

If you want to use the class without passing wires around then the class itself would have to use a FGV to get the DVR in order to access the data. In practise though, I generally don't do thing "wirelessly".