Jump to content

Need LVOOP Object VIs in lvdata library


Recommended Posts

It would be nice if there were some VIs for dealing with LVOOP Objects, at run time. One VI that I would love is one that could convert an LVOOP Object to a cluster (and vice versa). Ya, I know that this would violate encapsulation (shhh... don't tell AQ), but it would allow us to do stuff like create flexible object serialization tools.

Link to comment

Ah, got it.

I've got a calibration object with name, physical channel, scaling, etc... The object has methods to save to and load from XML file. I've coded the serialization into the object. (Hope I'm using the terms right.) Wouldn't this be the appropriate place?

Tim

Link to comment

Ah, got it.

I've got a calibration object with name, physical channel, scaling, etc... The object has methods to save to and load from XML file. I've coded the serialization into the object. (Hope I'm using the terms right.) Wouldn't this be the appropriate place?

Tim

Ya, that's a good place to do it yourself.

Link to comment

FWIW this is a work around I use at the moment when I want a human readable file.

Adding a non-type def cluster to group the items I want to flatten to disk

post-10325-0-45710900-1316474894.png

Here is (part of) a Class API

post-10325-0-43799300-1316474900.png

The Read From Disk method delegates read/writing to another object (so I can change file format etc...)

post-10325-0-63252500-1316474898_thumb.p

In this example the Base File Class writes a config file (OpenG style) I have a reuseable VI from my own library:

post-10325-0-14389600-1316474941_thumb.p

That is a wrapper for the OpenG VIs to guarantee certain functionality

post-10325-0-27900600-1316474896_thumb.p

I can handle file versioning to (not shown here).

In this example this creates a nice config type (settings) file.

The cool thing about OpenG is that this supports inheritance - as long as the variable names are unique up the chain - I can write to the same section.

I have found that MGI VIs do not allow this as they write the section as a string as opposed to key-value pairs (config API).

I have to say using the native XML is much easier tho.

----

Jim have you done any prototyping of your idea?

  • Like 1
Link to comment

I have often wanted similar features to Jim, or mainly some way to perform type reflection at runtime so as not to violate the very important encapsulation. This would allow for some very powerful serialization methods to be (dynamically) defined. I would also love to explore the possibility of late binding should such a system ever exist, but that's a whole other can of worms...

JG's idea is interesting though, as it still allows automatic serialization via the anonymous cluster. I like it! Extra kudos for the serialization method itself, if it's dynamic each level in the hierarchy gets a crack at serializing. Even more kudos for abstraction the file interface!

Edit: I misread part of your last post, doesn't look like there is an abstracted file interface. What can I say, it's late and I'm tired. Also appears not to be a way to "like" a post from the mobile version of the site. /sadface

Link to comment

Edit: I misread part of your last post, doesn't look like there is an abstracted file interface. What can I say, it's late and I'm tired. Also appears not to be a way to "like" a post from the mobile version of the site. /sadface

I am on iphone and can like using the button on the top right hand corner of a post (tick symbol).

I might be misinterpreting 'Abstract File Interface'? But the File Interface Class is a dependency from another package. The Interface Class' default behavior is to use OpenG format (as using LVOOP why just have an functionless based Class and extra Child? - I prefer less work :) )

One issue with the implementation is that the interface (as in a Connector Pane context this time) is a variant. This may seem a little dirty but it means the Cluster does not have to be a type-def (preventing issues of a TD Cluster in a Class) and that the File Interface can be re-used across or in other Classes.

Link to comment

We, too, would very much like to serialize objects more easily.

We actually do serialize objects to XML now, but we write a serialization method for each class (and this method calls the parent method, if applicable). Writing a custom method for each class is a fair amount of work and undesirable when there opught to be a framework that supports this automatically. (Note that the native XML functions do provide a framework that serializes objects, but the XML format is not satisfactory for all purposes, as stated elsewhere previously. In particular, if an object has a default value the generated XML just says that, rather than specifying the actual values, which makes the XML output to any application that doesn't have the exact same class definition. NI could just make a new version of their XML VIs that would format data better--which is probably pretty easy--and that would probably be a fine solution for many of us. In the meantime LabVIEW developers need to do this, and that is I think why we are having this discussion.)

Using a cluster within an object will also work (we do use this approach, actually, with configuration files, although for this purpose we use the native XML VIs), although it doesn't support (I don't think) writing parent data or objects within the cluster. More importantly, there ought to be a way to serialize every object, not just a cluster within the class. (Using a cluster does negate some of the points of using an object in the first place, like maintaning history, although this is more important in some situations than others.) Mostly, I don't think developers should have to do this. It should be easy (trivial, actually) to serialize objects, in my opinion, to an interchangeable format such as XML. (Java and other languages have frameworks to do this. Why don't we?)

  • Like 2
Link to comment
  • 3 weeks later...

Well, I would start with just recognizing that the variant is an LV class. From what I posted here, it seems I did find a way of finding out (although I don't remember what the code looks like).

Alternatively, since OpenG is now in 2009, we can probably use the vi.lib variant VIs, which I assume do tell you if the variant is a class, so if it's a refnum, you call the vi.lib VI to get the actual type. Optionally, we could also ditch the entire type string code and simply use the vi.lib VI for everything and simply make a lookup table for all the existing OpenG types, but that might have performance and backward compatibility issues.

Link to comment

Well, I would start with just recognizing that the variant is an LV class. From what I posted here, it seems I did find a way of finding out (although I don't remember what the code looks like).

Alternatively, since OpenG is now in 2009, we can probably use the vi.lib variant VIs, which I assume do tell you if the variant is a class, so if it's a refnum, you call the vi.lib VI to get the actual type. Optionally, we could also ditch the entire type string code and simply use the vi.lib VI for everything and simply make a lookup table for all the existing OpenG types, but that might have performance and backward compatibility issues.

Yes, the VIs that ship with LabVIEW do support determining if a variant contains an LVClass instance.

post-17-0-12963200-1318192122.png

I'm fine using this where needed, but I'd love to have a native implementation in the OpenG LabVIEW Data Tools Library.

Link to comment

Yes, the VIs that ship with LabVIEW do support determining if a variant contains an LVClass instance.

post-17-0-12963200-1318192122.png

I'm fine using this where needed, but I'd love to have a native implementation in the OpenG LabVIEW Data Tools Library.

I have previously exposed these VIs in this package but I have always thought it would be good to expose these VIs in the OpenG LabVIEW Data Library as a linked sub-palette.

I will start a new thread if there is any interest?

Link to comment

I'm fine using this where needed, but I'd love to have a native implementation in the OpenG LabVIEW Data Tools Library.

Just to clarify, I meant adding the LV class value to the OpenG enum and then modifying Get TDEnum from Data__ogtk.vi along these lines:

post-1431-0-24995500-1318230063_thumb.pn

The alternative implementation might be faster, because it hopefully does not require flattening the variant.

Link to comment

Just to clarify, I meant adding the LV class value to the OpenG enum and then modifying Get TDEnum from Data__ogtk.vi along these lines:

post-1431-0-24995500-1318230063_thumb.pn

The alternative implementation might be faster, because it hopefully does not require flattening the variant.

Hi Yair. Thanks for the clarification. I see what you mean.

I'd be curious to know if this is much faster.

Link to comment
I'm fine using this where needed, but I'd love to have a native implementation in the OpenG LabVIEW Data Tools Library.

I'm confused. Please define "native implementation". That VI is doing exactly what LV does under the hood in the C++ code. I'm not sure how much more native you can get.

And, to answer Yair's question, no, there's no flattening of the variant involved.

Link to comment

I'm confused. Please define "native implementation". That VI is doing exactly what LV does under the hood in the C++ code. I'm not sure how much more native you can get.

And, to answer Yair's question, no, there's no flattening of the variant involved.

Native implementation, to me, means that it uses primitives other than a Call Library Function or Code Interface Node (unless it's to call to LabVIEW.exe and the code is guaranteed to work at Run Time in both desktop and real-time).

I guess I don't really trust stuff that's inside password protected VIs and that's not in the palette. It could get removed or put into an LVLIB and scoped as private ;)

Link to comment

Hi there,

I recently wished the OpenG "Get Cluster Element by Name" would work on OO wires...

I looked a bit deeper into this, found out that OO wires unsurprisingly aren't mere clusters but that their flattened form is documented in the LV wiki.

So I began to write a VI that parses the flattened OO data and returns the contained data clusters. Here is it:

post-15449-0-18486900-1318531504_thumb.p

Admittedly, I felt a little bit dirty when writing this code :-)

Looking for another solution I stumbled upon the LV XML primitives. As mentioned before, these can be used to do much the same, with some limitations. I was only interested in readonly access of basic data types, so it worked for me:

post-15449-0-09304800-1318531522_thumb.p

I never used these methods in production code, however.

candidus

  • Like 1
Link to comment

I recently wished the OpenG "Get Cluster Element by Name" would work on OO wires...

I looked a bit deeper into this, found out that OO wires unsurprisingly aren't mere clusters but that their flattened form is documented in the LV wiki.

So I began to write a VI that parses the flattened OO data and returns the contained data clusters. Here is it:

This is very cool. How do you use it in practice? For example, how do you get the Class Private Data Hierarchy (Type)? Is there any way to obtain this from Object in?

Link to comment
  • 3 months later...

I have figured something out: That sucks...

Joking aside: It seems we can obtain the data type information, but we have to use LVClass references and property nodes to get the ancestor hierarchy. I created a small ClassInfo library and an example:

ClassPrivateData.zip

However, there's another way to get the data of the current class only:

post-15449-0-67283600-1327524708_thumb.p

It uses the VI "Get Mutation History.vi" from vi.lib to get the class private data type as Variant.

That's all far away from being an OpenG-ready solution but at least it seems to work in the runtime engine of LV2010.

I had problems with the runtime engine of LV2009, the VI executes but becomes broken after it has finished.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.