LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Creating and manipulating an instance of a class or object

Solved!
Go to solution

Hi there, 

As will probably be immediately obvious from the subject and attached project, I am new to Labview and OOP. 

 

The ultimate aim of the program I am tasked with creating requires me to control different channels of different instruments and perform measurements. The number of possible instruments and channels means using classes to pass data between I/O VIs seems the most useful solution. 

 

I can do most of the nitty gritty I/O work, but am falling at the first hurdle when it comes to Classes and Objects. 

My understanding is that I can create a class containing all of the variables I might need for a given channel, and then create an object for each specific channel, and populate those with the relevant data. 

 

Attached is the most basic attempt to this end. A program which creates a class of one numeric indicator. 

I then "Create two objects of this class" (I am almost certain this is where the issue is, and I suspect looks overwhelmingly stupid to anyone who knows what they are doing).

Using the sub VIs associated with the class, I then try to change the data within Object 1, without affecting object 2.

 

This seems like such a simple step that no tutorials/Labview Help articles/forums cover it. 

Thanks

0 Kudos
Message 1 of 9
(6,626 Views)
Solution
Accepted by Stefis84

There is no reason for that local variable to be there - just wire the test class object into the subvi. The reason the you are seeing the broken wire is that the local variable is of of type 'LabVIEW Object', and not your Test Class - even though the run time instance of the class is of the test class, LabVIEW has no way of knowing this at edit time, so the wire is broken. 

 

I am guessing you have experience in other languages - variables aren't used in LabVIEW they way they are in other languages. In LabVIEW, you can almost think of the wire itself as the variable - once you branch it (assuming it isnt a reference of some sort) you have a new instance. So in your test example, just wire the test class directly to the sub VI and write a value. Then create a parallel branch of the wire and drop another read/write subvi on that branch - you will see that the data modifications to the two classes are completely isolated.

0 Kudos
Message 2 of 9
(6,605 Views)

Thank you for this! I see what you mean about wires 'acting as variables'. It is an interesting concept to get used to...

In order to refer to the object later in the program without drawing a wire across it's entire lifetime, is it best to create an array of such objects and refer to them by index? What would you recommend as a local variable 'equivalent'

Could you create a for loop auto-indexing objects to an array, for example?  

0 Kudos
Message 3 of 9
(6,600 Views)

It really depends on what you want to do with them - if you are going to operate on the classes in the same way repeatedly, (Initialize All, Read From All etc) then storing as an array may be a good option, but there is really no right or wrong answer. You could also store them in a look up table of some sort, like a variant attribute table, or some other custom type of look up table. Yes, you can iterate of an array of objects with a for loop. 

 

I don't know what the scope of your project is, and this may be a bit too much for someone new to LabVIEW and OOP, but here is a link with lots of details on a well designed measurement abstraction framework, including the code itself.  

https://forums.ni.com/t5/LabVIEW-Development-Best/Measurement-Abstraction-Plugin-Framework-with-Opti...

0 Kudos
Message 4 of 9
(6,596 Views)

I'm not very experienced with object oriented programming in LabVIEW, so we can learn together! Just so we're clear: you want multiple objects which you can write and read data from independently of each other. I whipped up a project that does this the way you want to, have a look. 

 

A couple of things:

  • As far as I understand, it's one object per class. So if you want multiple objects, you need multiple classes. 
  • I utilized a parent/child strategy with these objects. This means that there is a parent with all of the functional VIs you want to utilize within it. Then you create those same VIs (same name as well) within the child, so that when you call them in the case structure they all refer to the same VI functions
  • Create a child by right clicking the class, going to its properties, and changing it's "Inheritance" to the parent. 
  • Try to stay organized using folders 

Let me know if this helped you or if I totally misunderstood what you're trying to do!!

0 Kudos
Message 5 of 9
(6,594 Views)

 


@Kai456 wrote:

I'm not very experienced with object oriented programming in LabVIEW, so we can learn together! Just so we're clear: you want multiple objects which you can write and read data from independently of each other. I whipped up a project that does this the way you want to, have a look. 

 

A couple of things:

  • As far as I understand, it's one object per class. So if you want multiple objects, you need multiple classes. 
  • I utilized a parent/child strategy with these objects. This means that there is a parent with all of the functional VIs you want to utilize within it. Then you create those same VIs (same name as well) within the child, so that when you call them in the case structure they all refer to the same VI functions
  • Create a child by right clicking the class, going to its properties, and changing it's "Inheritance" to the parent. 
  • Try to stay organized using folders 

Let me know if this helped you or if I totally misunderstood what you're trying to do!!


An object is an instance of a class - you can have as many objects per class as your program requires. Think of it this way - a car is a class. YOUR car is an object. When your program uses a class, that is an instance of the class (an object), and there is no reason you can't have more than one instance of the class (unless you specifically designed the class to only have one or x number of instances.)

 

Also, if the data is applicable between different child classes, there is no reason to add that data to the children in addition to the parent - remove the numeric data field from the child class, its already in the parent class, and can be accessed through accessors. 

0 Kudos
Message 6 of 9
(6,584 Views)

Ah, gotcha! Thank you. Instead of making multiple classes to represent my "channels" I could just wire the class to multiple objects which are all wired to different instances of the "Read" and "Write" VIs, right? Also when you mean remove the numeric data field, do you mean the extra VIs I created in the child classes or the enum const.?

0 Kudos
Message 7 of 9
(6,573 Views)

 


@Kai456 wrote:

Ah, gotcha! Thank you. Instead of making multiple classes to represent my "channels" I could just wire the class to multiple objects which are all wired to different instances of the "Read" and "Write" VIs, right? Also when you mean remove the numeric data field, do you mean the extra VIs I created in the child classes or the enum const.?


Yep - also there's no reason you can't just drop multiple object constants on the block diagram either - each on is its own unique instance. I usually wrap up the objects in a 'constructor' method that will include inputs required by the object. 

 

I mean the extra VIs, and the data in the child class private data. When you create a child class, that child class contains all if its parent's data (and its parent's data, all the way up the class hierarchy.) You just cannot directly access it without using an accessor, as all class data in LabVIEW is private. 

0 Kudos
Message 8 of 9
(6,567 Views)

An object is an instance of a class. If you have a class you can create multiple objects or instances of it. It is not true that for each object you need a class.

0 Kudos
Message 9 of 9
(3,434 Views)