Data Variable Toolkit

[Aniket Gadekar]

Hello Everyone,

I have created this feature to create named variables of any data type in memory and access its value from any part of data code which is under same scope using its name.
This variables stores instantaneous value. Best use case of this toolkit is acquire data set variable values & read from any loop. Do not use for Read-Modify-Write
Once variables are created in memory, you can be grouped them and access its values using names.
You can create variable for any data datatype & access its value using its Name. I have tested this toolkit for memory & performance, which is much faster than CVT & Tag Bus Library

Please check and let me know your suggestions. use LabVIEW 15 sp1

BR,
Aniket Gadekar,
aniket99.gadekar@gmail.com

DataVariableToolkit.zip

[LogMAN]

Cross post: https://forums.ni.com/t5/LabVIEW/Data-Variable-Toolkit/td-p/4032397

[hooovahh]

Thanks for your contribution.  A couple of things.  Using polymorphics for this type of thing can become a pain pretty quickly.  I had a similar thing for reading and writing variant attributes and used scripting to generate the 60+ data types I supported.  But even then there were times that the data type wasn't supported.  This also added 120+ extra VIs (read/write) adding to loading overhead.  The more modern way of doing this is with a VIM that adapts to the data type provided.  Your VIs were saved in 2015 when VIMs weren't an official thing, but you say you use 2018 where it is.  Back then I'd still support doing this data type adaption with XNodes.  Posted here is my Variant Repository which does similar read/write anything including type def'd enums and clusters.

Putting these in a global space that any VI can read and write from is pretty trivial.  All that is needed is a VIG, functional global variable, or even global variable in a pinch.  This will keep data in memory as long as the VI is still in memory and reserved to be ran.  This has other benefits of easily being able to load and save data from a file since it is all contained in a single place.  Also with this technique there are no references being opened or closed, so no memory leaking concerns.  Performance-wise I also suspect your method may have some room for improvement.  If I am writing 10 variables 10 times, looking at your code that will mean 100 calls to the obtain notifier, 100 calls to the send, and 100 calls to the release notifier.  I suspect reading a variant, and then calling the set attribute 100 times will likely take less time and processing power.

[smithd]

14 hours ago, Aniket Gadekar said:

I have tested this toolkit for memory & performance, which is much faster than CVT & Tag Bus Library

So I took a quick peek, nothing too detailed, but from what I saw there is pretty much no way this is unequivocally faster than the CVT or the tag bus. With the CVT it might be possible this approach is faster if you give it the worst possible load (10000000 simultaneous readers, each of which is reading a random, constantly changing name), but in any sane case you'd lookup a reference beforehand and then write to those, and the write time is bounded at basically the same performance as any reference-based data access. For tag bus...its literally just a cluster with an obscene number of different data types in big arrays. Data access is just indexing an array. There is no way in labview for data access to be faster than indexing an array. In contrast you are obtaining a queue by name which involves several locks, doing a lookup, and writing to the queue which requires another lock. The CVT only needs 1 lock and tag bus requires zero. Memory I'll give you.

Its also worth you looking at this:

 

[Aniket Gadekar]

21 hours ago, LogMAN said:

Cross post: https://forums.ni.com/t5/LabVIEW/Data-Variable-Toolkit/td-p/4032397

Hi, I wanted to share this tool also on LAVA. This above mentioned post is posted by me.

 

[Aniket Gadekar]

21 hours ago, hooovahh said:

Thanks for your contribution.  A couple of things.  Using polymorphics for this type of thing can become a pain pretty quickly.  I had a similar thing for reading and writing variant attributes and used scripting to generate the 60+ data types I supported.  But even then there were times that the data type wasn't supported.  This also added 120+ extra VIs (read/write) adding to loading overhead.  The more modern way of doing this is with a VIM that adapts to the data type provided.  Your VIs were saved in 2015 when VIMs weren't an official thing, but you say you use 2018 where it is.  Back then I'd still support doing this data type adaption with XNodes.  Posted here is my Variant Repository which does similar read/write anything including type def'd enums and clusters.

Thank you for your attention & time. I think using variant data type you can read/write any data type. Also, Most of the users are still using LV2015 so i kept this code in 2018. 

 

21 hours ago, hooovahh said:

Putting these in a global space that any VI can read and write from is pretty trivial.  All that is needed is a VIG, functional global variable, or even global variable in a pinch.  This will keep data in memory as long as the VI is still in memory and reserved to be ran.  This has other benefits of easily being able to load and save data from a file since it is all contained in a single place.  Also with this technique there are no references being opened or closed, so no memory leaking concerns.  Performance-wise I also suspect your method may have some room for improvement.  If I am writing 10 variables 10 times, looking at your code that will mean 100 calls to the obtain notifier, 100 calls to the send, and 100 calls to the release notifier.  I suspect reading a variant, and then calling the set attribute 100 times will likely take less time and processing power.

I tried to avoid FGV in this feature/toolkit due to some limitation of it. If you wanted to load/read variables from file you can develop that logic outside. I think obtaining queue/notifier reference, set value & close reference for 100 times is much cheaper than calling FGV 100 times. I saw your "Variant Repository" and it was nice, But each time you have to connect wire and pass data in subVI's, to perform read/write operation. Where as in my toolkit you don't have to at all.

Again, this feature can store large data also and can be accessed by Named reference.

Please let me know if you have any suggestions.

[Aniket Gadekar]

13 hours ago, smithd said:

So I took a quick peek, nothing too detailed, but from what I saw there is pretty much no way this is unequivocally faster than the CVT or the tag bus. With the CVT it might be possible this approach is faster if you give it the worst possible load (10000000 simultaneous readers, each of which is reading a random, constantly changing name), but in any sane case you'd lookup a reference beforehand and then write to those, and the write time is bounded at basically the same performance as any reference-based data access. For tag bus...its literally just a cluster with an obscene number of different data types in big arrays. Data access is just indexing an array. There is no way in labview for data access to be faster than indexing an array. In contrast you are obtaining a queue by name which involves several locks, doing a lookup, and writing to the queue which requires another lock. The CVT only needs 1 lock and tag bus requires zero. Memory I'll give you.

Its also worth you looking at this:

 

Thank you for your kind attention & valuable time.

I checked this functionality, In this you are using Queued message handler to request for read/write. I thing it will increase latency to read/write variable if there are many request. We never know how many times developer will call read/write operation. So instead, I obtained reference directly without any message request. And VI Register uses implementation similar to FGV, which i tried to avoid.

This toolkit strictly not used for Read-Modify-Write operations, Since each feature can have pros-cons. Again, Thank you for your time. Please let me know if you have any improvement suggestions.

[Neil Pate]

Aniket, thank you for posting this and congrats on starting your journey with lavag 🙂

[Aniket Gadekar]

1 hour ago, Neil Pate said:

Aniket, thank you for posting this and congrats on starting your journey with lavag 🙂

You are welcome Neil.