LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

object oriented

I am learning object oriented in labview, and I have serveral questions.  

 

1. If my class data has 10 data members, do I create one accessor VI for each data members or do I create only one accessor VI and create a cluster for the data members?

2. One advantage of using a class is to eliminate cluster.  If that's the case, does that mean method vi in a class should not have a cluster as an input or ouput (except for the error cluster)?

3. Sometimes, a class vi would have additional inputs besides an object.  If that's the case, should these additional input become data members of the object's class?  This way, a method VI will always have 2 inputs, object and error cluster.  

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 1 of 3
(2,515 Views)

@jyang72211 wrote:

I am learning object oriented in labview, and I have serveral questions.  

 

1. If my class data has 10 data members, do I create one accessor VI for each data members or do I create only one accessor VI and create a cluster for the data members?

2. One advantage of using a class is to eliminate cluster.  If that's the case, does that mean method vi in a class should not have a cluster as an input or ouput (except for the error cluster)?

3. Sometimes, a class vi would have additional inputs besides an object.  If that's the case, should these additional input become data members of the object's class?  This way, a method VI will always have 2 inputs, object and error cluster.  


For non of your question exist clear and simply "always good" answers.

 

1 + 2) If the data is loosely related then yes you should actually treat them as independent elements to access. However there is no rule that forbids clusters as a data member. If the data belongs logically together you should most likely treat it as a compound element rather than a skalar element. For instance consider the coordinates of a rectangle. While there can be something said to allow individual access to each element I would most likely treat it as a cluster of 4 elements first and maybe add extra accessors for the individual elements if that seems helpful.

 

3) There is no rule about what a VI must have. If you create dynamic dispatch methods, you obviously need the object reference input (and output). An error cluster is always a good idea too. Many methods take some other parameter that somehow influences the behaviour of the method, but again there is no rule that states they have to. 

Rolf Kalbermatter
My Blog
Message 2 of 3
(2,486 Views)

I typically create individual accessors for each individual item in my class private data. I then make these all available through property nodes (see screenshot). That way, when I am on the block diagram, using a property node, I have all of the options available. Even better is when I'm working with a class that is a descendent class of a different one - then the property node shows all data items (that you created accessors for), separated by lines to indicate which data items belong to which class.

 

OOP.PNG

 

It's fine to use a cluster. The only time I would create an accessor for a cluster is if I would be immediately using that data on whatever block diagram, as a cluster. My rule of thumb is basically, if I would be using an unbundle function immediately, then just create individual accessors. If you will take that cluster and pass it into something else, then create an accessor for the whole thing.

 

3. Not necessarily. For example, maybe you have a class that handles UDP communication, so your data items are IP address, remote port, local port, UDP connection ref, etc. Perhaps you want to send a string, so you create a write VI. You would need a string input, to contain the data that you want to send, but that data itself can be forgotton once sent. You don't want that as part of the class data. Taking that a step further, perhaps you are creating an instrument driver or some kind of hardware abstraction layer, and the commands are ultimately sent via UDP, and thus need to be formatted as strings. However, you want to create a VI that takes in more intelligible data and does the conversion for you.

 

So let's say you're controlling a motor, and you want to set the speed to 5000 steps/s. The UDP command for your particular controller is something like "SP 5000, 5000<checksum>;" for example. You create a VI that has a numeric "Speed" input, so the user of that VI only has to give it the actual speed number. Then, inside the VI, the string is formatted correctly, the checksum is calculated, and then using the class private data, the message is sent.

Wes Pierce
Principal Engineer
Pierce Controls
Message 3 of 3
(2,455 Views)