LabVIEW
Object Oriented programming not sure how it works
Solved!
@govindsankar wrote:
In my previous doubts I have spoken about taking various measurements. With your help I was able to do it and I thank everyone who helped me.
Some references would be helpful, although we can do without.
@govindsankar wrote:
But my new problem is with object oriented programming. I am trying to do object oriented programming, but now it just looks like a project with many VIs.
Many VIs is no problem. Tons of simple VIs are preferred over tons/10 VIs that are complex.
In OOP, you'll often end up making a VI that does almost nothing. That is only odd when you start. You'll get used to it, and when done properly, you'll grow to appreciate it.
@govindsankar wrote:
So as mentioned one of my VI collect different measurements from a board and show it as a GUI. This data are temperature readings and the board is a thermo board and I have created a class for this called Thermoboard.lvclass and the VI that gets temperature readings is called Write Temp.vi and this vi is within the class.
Nothing too obvious wrong here... A UML diagram would help (both you and us).
It's not rare to spend 25-40% of a project's time on analysis and design of the program. You'll get that time back though the power of OO (after getting experienced of course).
@govindsankar wrote:
Now in the class as usual there is a cluster of private data and in this private data I put in an array indicator called temp. Now I put unbundle this cluster in my write temp vi and store the temp readings into the temp array in the cluster of the class. Then I created a VI for data member access for the temp data and created the read Vi for temp. But when I run that new VI for reading temp nothing happens. I thought all the data will be stored in Temp and by using data member access vi I will be able to access the data.
Did you put the object in a shift register? Even though you're using OO now, everything still works by wire.
Put some probes before and after the VI. Check if the VI works as expected. If it does, use object highlight to see what happens to the object.
Post some code for better guesses of the problem. It's not easy to give advice given just the executive summary.
@govindsankar wrote:
But i am wrong. So my understanding of object oriented programming is wrong. Can anyone guide me or point to any material that can help me understand my mistake. Thanking you in advance.
Again, hard to advice anything except the usual (free) online courses.
I don't know if you're 100% of or just 5%.
Post some code...
Search LabVIEW like a graph! 
Iam sorry i didnt understand that line - the output class of your write temp vi to the input of your read temp. This is what I have done and also the value from the shift register goes into the private data temp which then goes into the thermo board out. In the read temp thermo board in is connected to a unbundle so that i can access temp. But I am not getting anything. The below photo shows the value coming in to the themo board out from the shift register.
You're focusing (and showing us) details. The bigger picture might be the problem. (You're showing use big pictures, but that's not what I mean 
.)
Show us where you call Write Temp2.vi and Read Temp.vi, that's probably where the problem is.
When Write Temp2.vi is done, is the Read Temp.vi connected directly to Write Temp2.vi? Use probes to see if the data is there when it exits Write Temp2.vi, and when it enters Read Temp.vi. My guess is they are not connected, and you might be assuming the data written in Write Temp2.vi automatically ends up in Read Temp.vi, even if the class wires are not connected. As if they are working by reference. They're not by reference, those objects are still working by wire, like any normal data type in LabVIEW.
But that's all assumption...
@govindsankar wrote:
Yes I wired read temp to the end of write temp and it works. Now my doubt is this then what is the use of object oriented programming. If write temp and read temp were normal vis under a project without object oriented programming, wouldn't the same thing happen.
Yes, VIs function\work the same. Class methods are VIs.
You've only been sniffing one of the pillars of OO, encapsulation . Even now, you can benefit from that. If you made normal VIs, that data would probably end up in a cluster. That cluster would be accessible for reading and writing by everyone and everywhere. If you abuse this capability, you're code will become tightly coupled. As that data is private (a restriction), you are forcing yourself to keep your code less coupled, which is a good thing.
The real power of OO comes when you start to use inheritance and polymorphism. Inheritance would be useful for instance when you have more then one temperature inputs. Classical, a parent ITemp, and two children: a physical input, and a simulation. Then you can develop the entire program using the simulation, and if the physical devise works according the contract (class API), your entire application should work.
You can also think about OO\polymorphism like this:
The class wire doesn't only transfer data, it also 'transfers' behavior. That means that a class wire can be the input of a VI, and from the outside of that VI, you can specify how the inside of the VI behaves. For instance, a Measurement.vi will call the Measure method of a Device class. The measurement.vi doesn't care about the specific device. The specific device can be specified from outside measurement.vi, by selecting one of Device's children. Or even more then one when a composite child is made.
It's hard to appreciate OO at first. It might seem mostly as 'more restrictive and difficult', without seeing any benefit. Those benefits are huge, but you have to grow into it.
BTW. There are plug-ins (G#, OpenGDS), that let you create by reference classes. I don't use them, and wouldn't recommend them. Others love them, and don't seem to be able to do without. Suit yourself. At least at fist, I think by reference will complicate things a lot.
