Hi Tom, I worked through your Udemy course, it was absolutely awesome. Thanks a lot. If you made another UDEMY course on OOP or Actor Framework, I will be your first customer :) .
Thank you so much Tom! This video is just what I try to learn these days! I really appreciate it. I am currently working on a lab DAQ project to measure and analyze thermoelectric properties which require several instruments to work together. Since I don't have access to the actual devices in the lab, the OOP is the remedy to develop the code. I already watched your previous OOP videos several times. Even I thinking to learn your opinion about my solution approach.
awesome bro...interfaces looks pretty useful when we use ATE systems where sometimes some physical things needs to read or write from all or desired devices on the go. Its really a nice explanation..thanks alot
I'm looking forward to creating a video on interfaces and Actor Framework soon! I haven't made it yet as I found a bug with how LabVIEW 2020 saves override VIs - but a patch should be released soon to fix it. Interfaces are really going to revolutionize Actor Framework - I'm very excited! NO MORE ABSTRACT MESSAGES!
At the time I designed it so "Analog Input" was a type of "Data Acquisition". However, if I were to do it again, I might make it inherit from "Channel"
Hi Tom. I have one more question. What is the point of inheriting the Abstract instrument class from the interface DAQ Types, aside from making a "forced reminder" for the developer to actually implement the methods in the child class? Also, it appears that the typecast of the dual-inherited class works only if such a typecast is performed on the class that immediately inherits from Interface and the parent class. An attempt to do so on the children of the dual-inherited class does not resolve broken wire withe either "To more generic" or "To more specific" typecast.
I think should clarify the question. When you inherit the instrument class from DAQ types Interface, I think (am I wrong) is the same as making the abstract methods "initialize" and "close" members of the Instrument class. Since every single concrete implementation inherits from Instrument type, and "Initialize" and "Close" are dynamic dispatch methods, they all be available in the all generation of children anyway. Also, it is not clear why inheriting of the Analog Input from DAQ types is needed. Thanks.
Thanks for this video Tom. I've just noticed one feature which really excites me. How did you get Diagram Preview in Choose implementation popup? I use LV2018, is this feature available for higher Labview versions?
That's a feature that was implemented in LV19 (I think), it's definitely in 20 and 21, pretty sure 19 as well. You can check out my What's New in LabVIEW videos to check for that, and other new features :)
Hi Tom, Can I create an Actor for the Instruments instead of Normal Class? bcz here I'm not gonna use most of the AF overrides (eg.: Actor core, Pre launch Init etc...), only using the AF messages!!
I'm not sure I totally understand the question, however for an actor to be able to receive messages, it must inherit from actor.lvclass. (Actor.lvclass doesn't have to be the direct parent). You could make your hardware inherit from Actor, then specific hardware could inherit from Hardware. That being said, take time to design your OOP relationships, often composition is preferable to inheritance
Hi Tom, thanks for your interest in sharing your knowledge. I have one request regarding efficient method of data encapsulation implementation while we use lv interface. Could you make little bit details about where to define the parameters and also recommendation for defining private data of child class
Hi Sarithlal, That's quite a broad question so I'm only going to give a high-level answer I'm afraid. Interfaces define what all child classed MUST be able to do. However, interfaces DO NOT define HOW the classes implement the functionality. A class uses its private data to execute functionality (and the interfaces has no input to what the class private data is). So, the private data of a class can be anything the class needs to execute the functionality. For example, if you're connecting to some hardware, the class private data might have a VISA Resource Reference. I hope this helps.
@@TomsLabVIEWAdventure thanks for your time to reply me. Is there any other platform to interact with you to get some recomendation or approaches we can apply in lv?
Yeah you can do, but I wouldn't put in the extra work if you just need a basic system. If you want your application to be dynamic and future-proof then go for it!
Interface icons in the Project Explorer change to "class icon" after saving it on disk. Is it a bug or a supposed to be? I checked the known issues page for both 2020 and 2021 versions and found no report.
Interesting, I've not seen that happen before and I've been using interfaces frequently for about a year now. Is it still behaving like an interface or has it somehow converted to a class? Are you able to replicate the behaviour? If so, let me know the steps you're taking along with version numbers.
@@TomsLabVIEWAdventure No, they are still acting like an interface but with a "class icon" in the project explorer tree only (e.g. in the "item settings" they have an interface icon). I have LabVIEW 21.0.1 (64-bit) on Windows 11 (with the insider program). Whenever I create a new interface and check "Do Not Save" it has an interface icon until I close and reopen the project. Meanwhile, I want to thank you again for the video since I recently started to use interfaces and noticed the all details you put there.
@@MortezaVafadar I wonder if the "do not save" option is causing the issue. That's not something I typically select. I'll try it tomorrow and report it to R&D
