OpenGDS GOOP400 Read by reference

[StefanLemmens]

When I create new property node methods for a GOOP400 class using the OpenGDS they look like this :

  

The Write method gets the reference to the data and then modifies it in place.The read method gets a complete copy of the data and unbundles the wanted element. When the object contains a lot of other (large) elements I would like to avoid copying the entire data to unbundle just 1 element. This means also getting a DVR to the object and unbundle the element inside an in place element structure, as shown here :

In LabVIEW 2017 and above I could even use "Allow parallel read-only access." to make sure it's read-only.

Currently I modify such read methods manually each time I create a new one. I know I could update the template but I was wondering if there is any good reason not to do this. Or what is the reason why the original OpenGDS is reading by copying the entire cluster?

[ThomasGutzler]

I'm on your side, I often do the same if I can be bothered. In rare cases I even edit the GetAttributes to entirely remove the cluster out; not sure if that actually helps but it does break the "GOOP/Add Method" a little. You should update the template and create a pull request.

Interesting choice on ignoring the incoming error when you get the attributes.

[pawhan11]

I tend to do the same when I have some time to clean up.  I did not notice any performance change. Removing error cluster is also good idea so it does not hurt the eye. 

[MikaelH]

You are right the read will be much faster if you use the DVR and use the IP Structure to just extract the element you need form the cluster.
I'll update the templates to use this method.

[Michael Aivaliotis]

On 9/28/2018 at 12:01 AM, ThomasGutzler said:

Interesting choice on ignoring the incoming error when you get the attributes

Yes, but ignoring the IPE error out on read as well? I would think that you would want to know if the IPE structure fails completely. This would be a sign of a bad DVR ref.

[MikaelH]

Some test code I made of doing 500 Get Attributes of a class with some large data sets.
I would try to avoid having to much data in the Attribute, but if I need it I might user the Reference Variable Design Pattern GDS can apply to a class.

GetAttribute.zip

[MikaelH]

43 minutes ago, Michael Aivaliotis said:

Yes, but ignoring the IPE error out on read as well? I would think that you would want to know if the IPE structure fails completely. This would be a sign of a bad DVR ref.

The GetAttributes checks the DVR ref and generates a 1556 error if the DVR is invalid, but of course the DVR Ref could be killed externally between the Get Attribute and when the IPE node is executed...there is always a chance.

 

[StefanLemmens]

Thanks for the feedback and for updating the templates.

 

On 9/28/2018 at 9:01 AM, ThomasGutzler said:

Interesting choice on ignoring the incoming error when you get the attributes.

When creating the screenshots I kept the error handling mechanism of the original read. I probably didn't pay enough attention on error handling, just wanted to point out the difference in read by value or by reference issue. 

On 11/20/2018 at 11:19 PM, MikaelH said:

I would try to avoid having to much data in the Attribute, but if I need it I might user the Reference Variable Design Pattern GDS can apply to a class.

The Reference Variable Design is indeed a good alternative if working with large datasets. I wasn't aware of that. One disadvantage of that design pattern however is that the GDS can't create property methods for the referenced variables. They are not in the "Data Fields/Attributes" list of the Create Method Dialog. This makes it more cumbersome to create property methods for this type of attributes.

[MikaelH]

12 hours ago, StefanLemmens said:

One disadvantage of that design pattern however is that the GDS can't create property methods for the referenced variables.

I don’t agree ?, you just need to know where to look ?

Every design pattern that is added to a class, have the ability to add new Method templates and you’ll find them here.

 

This is the same if you add the Active Object Design pattern there is a method templates that helps you send and receive a message form the active process.

BTW, I've created the new version with new templates, I just need to upload them, I let you know when it's done.

[MikaelH]

The new version is ready for download under Untested Version

https://opengds.github.io/

[StefanLemmens]

I wasn't aware of the power of all those design patterns. This makes a great toolkit even greater. This discussion made me realize I have to take a closer look at all those different design patterns.

On 11/22/2018 at 10:23 PM, MikaelH said:

Every design pattern that is added to a class, have the ability to add new Method templates and you’ll find them here.

I tried to add the new method as a property node instead of a normal method. That's why I couldn't find it. Having these templates for every design pattern makes them very easy to use.

On 11/23/2018 at 10:33 PM, MikaelH said:

The new version is ready for download under Untested Version

https://opengds.github.io/

I downloaded the new version and it looks perfect to me. Thanks for updating the templates so quickly.

[MikaelH]

I would love to get more time to show everyone all the nice and fun feature that exists in the GDS tool.
If anyone like to help please feel free :-). I'm aiming to document the "Convert Text based code to LabVIEW" next.
You can always test it and see if you understand how to use it...
You can google come Java or c# Design pattern examples (e.g. Observer pattern), and convert those classes straight into LabVIEW.
I also want to document the API VIs, if you haven't tested them you can find them + examples here:
LabVIEW 20XX\resource\Framework\Providers\Open_GDS\API

 

 

[MikaelH]

FYI, version 1.2.38 has an issues when creating Override methods.
Please use the latest one 1.2.39
https://opengds.github.io/

You won't believe what I had to do to get it working ;-), coding VIs that runs in the project provider application instance is not always easy.
A VI that works fine when you run it normally, could still crash/freeze LV when it's running under the project provider application.
I hope it will be easier in NXG.

[Michael Aivaliotis]

7 hours ago, MikaelH said:

I hope it will be easier in NXG.

😀

[ThomasGutzler]

On 11/30/2018 at 8:07 AM, MikaelH said:

FYI, version 1.2.38 has an issues when creating Override methods.

Does that bug exist in .37 too?

[MikaelH]

No only 1.2.38 has the strange freeze.

[styrum]

On 11/29/2018 at 1:07 PM, MikaelH said:

You won't believe what I had to do to get it working ;-), coding VIs that runs in the project provider application instance is not always easy.
A VI that works fine when you run it normally, could still crash/freeze LV when it's running under the project provider application.
I hope it will be easier in NXG.

So, can you make a tutorial (provide links to info/examples) on specifically that topic: How to make your own project provider, how to add your own items/code to the popup menu on the items in the project editor tree, including your own New..., the same way way Open GDS and AF do? Is this the best place to start? https://forums.ni.com/t5/LabVIEW-Project-Providers/gp-p/bymqyodmkc?profile.language=en

What specific troubles did you run into that are not covered there?

Edited April 26, 2019 by styrum
Found more info

[MikaelH]

Hi
Yes start with the Projected Provider documentation and the look through examples (e.g. the OpenGDS).

I started in LV8.2, and lots of the issues I had, have probably been fixed since then.

But one thing to remember is that it doesn’t (or at least didn’t) like to do things in parallel.

E.g. if you add an item to the project tree (e.g. a new class), then that could trigger some other project provider calls (e.g. a new item added to the project window), so I had to add a small wait after those functions.

If I didn’t do that LV could crash from time to time, that’s why you can find a lot to 150ms wait in the Open GDS code.

Debugging the project provider code is a bit tricky.

You can save a Break point on the BD of the provider VI, and then restart LV.

The first time the code hits that break point the You can debug the code, but after that you Can debug the VI anymore, you have to restart LV again.

 

Make sure you open VIs in the correct application instance if you want to modify them, and always remember to close all the referees opened in the provider VIs.