LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Read write parent "public" data

Solved!
Go to solution

Struggling with LVOOP. 

Problem: I need to write/read parent data without calling corresponding override child method(s). 

 

For example:

I have motor class with current "position" as class data.

There are different motors with different interfaces, each has its own data, interface specific.

Position read/write methods in Parent are regular bundle/unbundle class data.

Override vi for write Position in child is moving motor.

Override vi for read Position in child is reading position from motor directly and writing it to "public" position. Ooops, it calls the child write position method, but I do not want to move motor, I just need to store last position in class data

 

Possible solutions (all ugly):

1) Make parent only method for writing/reading the same data and call it from child vi? Duplicate a lot of parent methods, just not override them.

2) Add switch "just data access" in methods - property nodes become unusable, 

 

3) Have tried in child method to convert (to generic) class to parent and hoped it would call parent method, but it still calls child methods.

I have attached attempt of #3. 

Unsip, open project, open "test parent only access.vi", run it. If it shows "child write call", then it is calling child position write instead of just writing to parent data.

"Initted?" in parent data allows (is supposed to allow) to switch between reading from motor or from class data. Also does not work, because it is trying to call child read position recursively.

test parent access.png

0 Kudos
Message 1 of 5
(3,097 Views)
Solution
Accepted by topic author Alexander_Sobolev

Not a LVOOP expert, but I would say you've made a design mistake by overriding what *should* have been a parent-level accessor method.

 

In LVOOP, class data is always private.  Children cannot directly access the "parent part" of the data that rides along on their object wire.  Private data is always mediated by functions defined at that same level of the class hierarchy.

 

If children need to read or write the parent-level data, they must do it via a parent-level accessor function.  Such access must be defined in the parent to be available. 

What follows from this is that these kinds of accessor functions should *not* be overridden.  Nor should they have dynamic dispatch terminals.

 

To fix: rename your parent level accessor functions to "get Position" and "set Position".  Change the object terminals so they aren't dynamic dispatch.  Make the functions either protected (for child-only access) or public, but *not* private.  I'm guessing you could inline them if you're concerned about layers of function calls and execution efficiency.

 

Make new dynamic dispatch parent-level functions with the original names "read Position" and "write Position".  Have these call the parent-level accessor functions you just renamed and reconfigured.   LVOOP children can still override these functions.  But when a child needs to update the parent-level position data, it does so via an explicit call to the parent accessor "set Position".

 

At least that's how I'd be inclined to approach it.  Tip: make use of the ability to define an icon template for each member of the class hierarchy.  Make each class distinct to help yourself see when you're calling something defined at the parent level vs. something defined at a child level (and also be able to see *which* child level).

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 5
(3,080 Views)

So #1 is official solution =(.

Why is it so inconvenient? So good concept, so bad implementation.

Regarding icon, adding library graph affects automatic text positioning and I can not position 1 line of vi icon text where I want it to be (it will either overlap with border or in the center of remaining area). Text in library icon does not affect vi text positioning, so in test class collection they are different for parent (motor) and child (# 1). 

0 Kudos
Message 3 of 5
(3,040 Views)

RE: solution #1


@Alexander_Sobolev wrote:

1) Make parent only method for writing/reading the same data and call it from child vi? Duplicate a lot of parent methods, just not override them.


So yes, there's a parent-only method for writing/reading the parent-only data.  And yes, you would call that parent method from the child vi.  But no, you wouldn't need to further *duplicate* parent methods.  You'd just *call* them.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 5
(3,028 Views)

@Kevin_Price wrote:

If children need to read or write the parent-level data, they must do it via a parent-level accessor function.  Such access must be defined in the parent to be available. 

What follows from this is that these kinds of accessor functions should *not* be overridden.  Nor should they have dynamic dispatch terminals.

 


A quick comment- while it's usually a good idea to not override accessors, it's not always a bad thing. For example, if you are doing range checking of inputs to accessors, that could be done in a dynamically dispatched child VI that overrides the parent accessor. You'd do your child-class-specific range checking, then use "Call Parent Method" to actually set the data in the parent's function. Call Parent Method is required though, as the child class cannot directly write to the parent's private data (like Kevin said, class data is *always* private).

 

I would agree that "Set position" as a command to move a motor should not override the accessor function that simply sets a variable in the parent. An accessor and a method to actually "do stuff" are typically two separate things with separate responsibilities. Kevin is right- the accessor to store the last read data into the parent's private data should not be overridden by a command to read the position from the motor..

 

Also, FYI you can set up any method to be able to be called via property node, not just accessors.

 

Also also, To More Generic Class doesn't actually change the data on the wire. It only lets LV set the wire type. Methods called on a parent wire will still use the child methods. It's kind of the whole point; LabVIEW decides which specific method to use on something without you having to convert it to its most concrete type before calling the function.

Message 5 of 5
(3,018 Views)