12-12-2016 09:52 AM
Hi everyone,
I want to share a couple of arrays to another VIs on the same PC. I decided to use Network Streams but I couldn't be sure about that. Do you think that it is a good idea to use NS or not? Do you suggest a better method? I want to build an optimized way to share data.
Thanks in advance,
Emre
Solved! Go to Solution.
12-12-2016 10:37 AM
VIs in the same project/executable? If so, use a Queue. Much simpler.
12-12-2016 10:48 AM
crossrulz,
Thanks for your quick reply. I didn't explain enough, sorry for that.
I've been developing an application for cRIO 9082 (Windows version). I'm already using DMAs and transfering a lot of data so I didn't want to use queues, That's why I looked for an alternative method and Networks Streams came up to my mind. I just thought that it may be better if I use network rather than memory. Do you think that I'm wrong with this idea?
Thanks in advance,
Emre
12-12-2016 10:59 AM
Using the network will still use the memory. You are just jumping through even more hoops to get your information moved than a simple queue would (and possibly using even more memory). If you are worried about memory usage, you can limit the number of elements can go into a queue when you initialize it.
12-12-2016 11:02 AM
I didn't know that it would be worst. I'll stick with queues again. Thanks for your interests.
Best regards,
Emre
12-13-2016 04:21 AM
I frequently use a simple Functional Global Variable with a built in semaphore for sharing a data set across multiple asynchronous VIs. You 'do' have to be careful to avoid race conditions but FGVs provide a very quick and effective way of sharing data across asynchronous processes with very low overheads.
12-13-2016 07:34 AM
Are you writing to your FGV from multiple locations? If not, do you really gain that much from the non-reentrant? Why not just use a global variable to share data across VIs or a shared variable if you're going across multiple projects? The FGV sounds like it's not really being used as intended there if there isn't any "functional" component to it. We already have global variables. That's what you get once you remove the function.
12-13-2016 07:58 AM
The gain I get from this method is in terms of processing overhead and simplicity of use (less wiring). Global Variables are much slower than FGVs. In my applications I implement some of the features of a queue (read/write/initialise/get_status) so the object is a true Functional Global.
As I say, this is a simple method of exchanging data in memory with low overheads and simplicity of use but I am sure that the purists can point out the disadvantages in it. It is just a suggestion of what can be done.
12-13-2016 08:11 AM - edited 12-13-2016 08:12 AM
Hi Sipic,
I wrote a Nugget on a LV code Construct called an Action Engine found here.
When properly implemented, it can be viewed as a Fucntional Global with built-in semephores.
Please review that nugget to learn more.
The key detail of developing a proper AE is to ensure that all modifications of the data encapsulated in the AE are performed INSIDE the AE.
I hope that helps!
Ben
12-13-2016 08:31 AM
@Sipic wrote:
Global Variables are much slower than FGVs.
I'll take you up on that bet: A Look At Race Conditions, Are Global Variables Truly Evil?
So just to clear things up (and make sure we are all using the same terminology):
1. Go read Ben's nugget (Action Engine)
2. A Functional Global Variable, as the community is slowly changing to define it, is an Action Engine with just "Get" and "Set" states (ie "Write this value to the register" or "Get the value from the register"). If this is the case, you are not protecting any "critical sections" of code (ie Read a value, do something with it, and write the updated value back).
3. Based on (2), a FGV is functionally exactly the same as a Global Variable.
4. Global Variables are faster than FGV and are faster to create (go check out my benchmarking from the above links).
Conclusion: FGVs are truly evil!!!