Solved! Go to Solution.
The global variable is part of the PPL?
I am surprised if that works during development... You are running into the issue that the lvlib (the basis for PPL) is creating a name space. So you are NOT using the same global even if you have the same VI name for the global variable and the same name for the data field itself.
Sorry, I have some issue when upload picture. Now,you can see my project. For easy understand this issue, I creat two easy VI to demostrate it.
You can see this global varible is defined in an llb, and can be access by another llb. However, after build PPL,it can not be accessed
If you create a PPL for DataProcess (which contains the global variable), you have to swap the global variable in TestTask to the one from the PPL "DataProcess".
So you understand what's happening here...
When you build a PPL, it pulls in the .lvlib and also all of the dependencies of the .lvlib.
In your case, when you build Test Task.lvlib into a .lvlibp, it also pulls in a copy of DataProcess.lvlib:GlobalsVariable.vi because it is a dependency of Read GlobalVar.vi.
When your application runs, you end up with two copies of GlobalsVariable.vi in memory:
Test Task.lvlibp:<dependencies>:GlobalsVariable.vi (I'm not sure how PPLs namespace dependencies...whether it's still got the DataProcess.lvlibp)
Because they are different VIs (i.e. in a different namespace), they have their own memory and that's why you can't access the data from the other one.
Your Test Task.lvlibp calls the version of GlobalsVariable.vi it has pulled in from the dependencies.
To fix this - you need to make sure that Test Task.lvlibp calls the version of GlobalsVariable.vi from the DataProcess.lvlibp - you'll need to replace all instances with the version from the PPL. Of course, if you're running DataProcess in the development environment, then it will still be incorrectly namespaced, hence the suggestion of putting your global variable VI into it's own PPL which you then use in both Data Process and Test Task.
As a side note (the other responses are spot on and I can't add anything there) - there are other cheeky ways fo creating a "global" that can be accessed from multiple PPLS as long as they are used in the same application (ie. Application Instance).
A common one I have used before in situations where dependences were simply too tangled to justify the time to manually untangle them is a single element named queue (the name being the important part here). Queues (in particular named queues) are unique in each Application Instance. I you refer to the queue by name in each PPL (and hope for no conflicts - so choose a particular obtuse name or something with some confidence of uniqueness such as a GUID etc.) then the queue will be the same reference in both PPLS at run-time when used by your calling application (your hosting Application Instance).
You can stuff data in and out of them with another advantage being that you can control the operation atomically if needed through an API to the SEQ.
Thanks for your help, Now I understand why it can works in development enviroment but can not works in application enviroment.
It is right to put global variable in its own PPL,but I don't like use this solution,because it will make my project organization structure not easy understanding.
As an alternative option, I would like to make sure Test Task.lvlibp calls the version from DataProcess.lvlibp. But I can not imagin how to implement it.