Search the Community

I've created a by-reference framework similar to the Extensible Session Framework (https://decibel.ni.com/content/docs/DOC-12813), with the difference that my object references are self-persistent. This is achieved by creating the object instance in a separate thread, which remains running in the background. This is all working rather smoothly, but I would like to clean up my code a bit. Right now, I have a Persistent Object root class which contains only two properties (Instance Name and Destroy Event) and two methods (Create and Destroy). A child class overrides the Create and Destoy methods, and offers class-specific functionality. Unfortunately, the child class also contains the wizardry code that maintains a list of existing instances and manages the creation / destruction of particular instances. I've included some snippets that demonstrate these methods, as well as a typical top-level vi. Example top-level vi: Require method: Unrequire method: Holder method: Of course, the framework-related functions should preferably be in the root class, not in this child class, to allow me to make changes to the framework without editing all child classes. The problem is that I cannot create the Require/Holder/Unrequire functions in the root class and override them in the child class, as the DVR terminal data types will not match. Does anyone see an elegant solution to this problem? Thank you.

Good morning everybody, I'm new to the forum and I'd like to show you my last creation as a presentation. It is called Hackman, and it is a PacMan clone I've made while trying some OOP in Labview. I have programmed chasing and moving methods as in the original arcade. From the website http://hackyourpack.altervista.org/ you can download the executable... If anybody's interested I can provide source. It is keeping track of the global high score.. so try it and put your name on it, so everybody will know your mastery! Ciao! Ubbi

Name: LVOOP Assistant Submitter: jgcode Submitted: 25 Apr 2010 Category: LabVIEW Tools Network Certified LabVIEW Version: 2012 License Type: BSD (Most common) This tool integrates into the LabVIEW Project Provider API and contains features to assist with LVOOP development Instructions: - Restart LabVIEW after installation - In a LabVIEW Project, right click on a Class or Class Method VI and select 'LVOOP Assistant >> Plugin' - If 'VIPM Options >> Mass Compile VIs after Package Installation' is set to FALSE, tool will mass compile on first load for LabVIEW versions after 2012 - See 'Help >> LAVA >> LVOOP Assistant' for more information - Search 'LVOOP' in NI Example Finder for examples of LVOOP Assistant pluginss Features: - Clone a Method VI to another Class - Create a Child Class - Display and edit all VI icons in a Class - Open Accessor VIs from a block diagram property node for debugging - Script Method VIs using templates from a sandbox - Paste icon text from one Method VI to another - Refresh a Method VI's icon without having to open the Class Properties Dialog and refresh all icons - Rename LVOOP Labels - Add favourite Virtual Folders to a Class with pre-configured scopes Click here to download this file

I have seemingly found an issue with the shipping example code for Nested Malleable VIs. Another user has verified that he saw the same behavior in 2019. I am working through the examples and the presentation from NIWeek 2019. In running the Lesson 2b code (C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Malleable VIs\Nested Malleable VIs) I found the Equals.vi in the class was not being leveraged and the search failed. When I went to my LabVIEW 2018 machine and ran the Lesson 2b.vi the code worked to find the element by correctly leveraging the in-class Equals.vi. One difference I see is that in the 2018 example the Equal.vi is in the example folder with the code, and in 2019 the Equal.vi has been moved to VI.lib - otherwise the code looks to be the same. The Equals.vi code looks identical, and the calling VIM look identical. I posted on the LabVIEW NI.com forum here: https://forums.ni.com/t5/LabVIEW/LabVIEW-2019-Malleable-VIs-Shipping-Examples-Lesson-2b-Nested/m-p/3966044/highlight/false#M1129678 I am trying to determine what may have broken or changed between the implementation in 2018 and 2019, visually the code looks the same.

The QControl Toolkit by Q Software Innovations is an object-oriented and extensible alternative to XControls. Use the QControl Toolkit framework and the QControl Creation Wizard to create QControl Classes and receive the benefits of XControls without the headaches. Take advantage of easy UI logic code reuse. Encapsulate and decouple the UI logic away from the business logic of the main application and from the UI skin. Use wherever the VI Server and LabVIEW object-oriented programming are allowed. Easily extend the capabilities of current LabVIEW controls through access to all properties available at run time. And easily use the toolkit with more complex frameworks like the Actor Framework or other plugin architectures where LabVIEW libraries and packed project libraries are used and where XControls can behave unpredictably. Check it out now on the NI Tools Network here. I also started a thread on the NI Community: UI Interest Group page, here.

Hello all, I am programming with LabVIEW for around 2 years and was recently stumbled upon LVOOP. I am required to write a communication protocol to work with a micro-controller, which later will be also used for ATP and debug purposes. I want to build the program "correctly" from the beginning so it will be maintainable and flexible to additions and changes. My natural way of building a program would have been a queued state machine, with several loops, each loop is in charge of a different module (one for GUI obviously), but as I stated in the beginning, I want to use LVOOP. Does anyone have a LVOOP project I can use as reference? I've searched online and found some nice examples, but they are small and teach you the basic stuff. For me it's important to see the how to use the project tree wisely, where to place the classes, see the managing loop and to learn as much as possible before I create one of my own. Thanks in advance, Voklaif

I have an array of classes, let's call the object TestPass, of size 1 (but it is an array because it can scale out to multiple test passes). In this class, there is one other nested class which is not too complex, then various numeric and string fields to hold some private data. There is also an array of clusters. In this cluster there is a string, two XY pair clusters, and an integer. Not very confusing. This array of clusters gets fairly large, however, upwards of 80-100k elements. What I am finding is when I index the array of pass classes it is crazy slow. On the order of 30 ms. Doesn't seem like much, but we are indexing the array in our method to "Get Current Pass" which is used in various places throughout our code. This is adding potentially hours to our test time over the 80k devices we are testing. So, I started digging. When I flatten the class to a string and get the length, it's 3 mb. But, when I run the function with the profiler is is allocating close to 20 mb of memory! My gut feel was that the string is causing the issues. So I removed the string from the cluster and the index time went to 0 ms. Luckily we can normalize a bit and pull the strings out of the cluster since a lot of them are duplicates. But it makes our data model a bit uglier. Has anyone seen these kind of performance issues before? I saw them in 2013 and 2017.

I am new to LVOOP and have jsut started writing my first LVOOP program which I have attached. I would appreciate greatly help with the question I have Thank you in advance Ted This vi will perform two tasks 1.Generating Report data sheet for metrology 2. updating the scales in a MAX .nce file 1. Metrology will input calibration information into the tables on the tabs Metrology will then click "Update Tables" then "Create Report ( create report section of code is not yet written Update Tables will write all information entered in the tabs to class varaibles and will also delete current Max informatiomn 2. Metrology will click "Load NCE Scale" vi will prompt for nce file to load and then once file is selected, display existing scales for two channels (Current Motor 1 and Current Motor 2) Metrology will then click "Update Scales" the program will replace the existing scales with those entered in Step 5.14 and 5.15 from the tables on the tab Question 1. Steps 5.14 and 5.15 are needed by both classes ( Table Variable and MAX) - what is the best way to share this information CAT0000032 Class Version.zip

I was browing through the actor framework discussions on the NI site yesterday and I came across a statement by AQ. Never inherit a concrete class from another concrete class I had to think about that for a second. The more I think about it, the more I realise that all of the LVOOP software I have been writing more or less adheres to this idea. But I had never seen it stated so succinctly before. Now that may just be down to me being a bit slow and all, but in the muddy and murky world of "correct" in OOP-land, this seems to be a pretty good rult to hold on to. Are there others which can help wannabe plebs like me grasp the correct notions a bit better? How about only ever calling concrete methods from within the owning class, never from without? I'm learning for a long time now, but somehow, my expectations of LVOOP and the reality always seem a little disconnected. AQs statement above helped crystallise out some things which, up to that point, had been a bit nebulous in my mind. Well, I say I'm learning..... I'm certainly using my brain to investigate the subject, whether or not I'm actually LEARNING is a matter for discussion... The older I get, the less sure I am that I've actually properly grasped something. The old grey cells just seem to get more sceptical with time. Maybe that in itself is learning...

i need some imfomation and idea

Hi, I've decided to take the temperature on a known issue, that lvclass files retain knowledge of some of their old content after it's deleted. Proof For some reason I'm not allowed to upload lvclass files, so I'll describe it instead (using LV2014SP1): 1) Create a new class and save it on disk as class1.lvclass. No member data nor methods, file size on disk is 8 kB. 2) Add one piece of significantly sized (to easier see the issue) member data, I added a 1000x100 array of DBL (with random default data in it). Save the class again, and now class1.lvclass is 4604 kB (why so much, should be around 1000 kB?). 3) Delete all member data again and resave the class. File size on disk is now 1171 kB, I'd have expected 8 kB. 4) I can't ever get rid of that extra data in the lvclass file, not even when I "save as" to create a similar class. Questions A) What's the reason behind this issue? B) Is there any way to really delete stuff from a class file, or is the only way to recreate every class from scratch if you want something truly gone? C) Is there a list (perhaps internal to NI) of which problems this issue causes? Here I'm talking about stuff like this and numerous other threads about class data suddenly not being updated or member data or methods not being called correctly with DD. Cheers, Steen

I'm not able to solve DVRs problem. See project file. 1. IO.lvlib exists in two versions: one with single variables + processSimulation.vi that simulates process/machine i.e. takes outputs, calculates process behaviour and writes inputs; the second version of IO.lvlib has variables as IOaliases. Simply swaping these two versions allows to run project on real target with machine or to run project on PC without target/machine. Thats why I use these IO.lvlib variables. 2. Every subsystem is an object/class with method DoSomething that calculates response to inputs and writes outputs. 3. I¨d like to call these objects DoSomething.vi method in one loop. Thats why it's not possible to have inputs/outputs as terminals of DoSomething.vi 4. I've tried to solve the problem with DVRs: every object is created by constructor including inputs/outputs DVRs initializing. However I'm not able to use DVRs inside DOSomething method. What am I doing wrong? One solution is to avoid loop call and spread all (about 50) DoSomething.vi calls including inputs/outputs terminals onto block diagram. But this is definitely not well arranged solution. Do you see anything wrong concerning my solution in general? How to access DVR inside class method? Any other ideas, comments? Thanks. IOrefs.zip

Hello LAVA, I have been working on a configuration interface lately for my framework, and have found a situation in which it seems desirable to be able to decide between a child and parent implementation of a class method at run time. The idea is that each level of a class hierarchy is responsible for some data which is to be configured at the start of operation. To avoid having to rebuild then extend the Config UI for each child, I have been trying to find a way to display each level (Parent, Child, Grandchild) UI in an "Options Dialog" style window. The user should be able to select the hierarchy level to view and configure it's data. I have attached some sample code to illustrate, but it basically entails a listbox for the different hierarchy implementations, and a subpanel to display the selected implementation. The code starts by traversing the class hierarchy to populate the listbox with any ancestors of the selected (Child) class that implement "UI.vi". Then it waits for the user to select one of these implementations before setting the class object vi Control reference, running the VI and inserting it into the subpanel. Note: It seems like it would be much easier to use the CBR/ACBR nodes to do this, but I was unable to figure out a way to call the different implementations, due to the dynamic dispatch terminals. Because this was not particularly straightforward to implement, I have a strong suspicion that it breaks OOP, is generally terrible, which is exactly why I am posting it here. Can someone give me a reason why this is a good or bad idea? LVOOP UI.zip

Hi, I'm writing a LabVIEW application using the Actor Framework. This is the first time that I have used the framework and I need some advice regarding application architecture. My apologies if this is a basic question! How is a settings dialog box best implemented? In the past in non-Actor Framework applications I have loaded the configuration from a functional global variable, displayed the settings dialog, then written the updated settings back to the functional global. I'm not sure this would work correctly (or optimally) within the context of the Actor Framework, though. My application uses the template generated by Create Project -> Actor Framework. The top-level Actor manages the user interface. Two child Actors control separate pieces of hardware. The top-level actor must read a saved configuration from an INI file when the application starts, and save the final configuration back to the INI file on exit. Instinctively I think it would be best for each child actor to maintain its own settings, as a cluster in its class private data. Ideally I don't want to have to keep a separate instance of the two clusters of settings in the top-level Actor's private data in order to populate a settings dialog; this duplication seems unnecessary. The only way I can think of to make this work is as follows. At application start 1. Top-level Actor reads settings from INI file. 2. Send messages to both child actors with the new settings, and tell them to apply those settings to their private data. 3. Each child Actor should respond to acknowledge that the private data has been updated. To update the settings using a dialog box 1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor. 2. Wait for both child Actors to reply. 3. Display the dialog box. 4. If the user clicked 'Ok' and not 'Cancel', send messages to both actors with the new settings, and tell them to apply those settings to their private data. 5. Each child Actor should respond to acknowledge that the private data has been updated. On exit 1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor. 2. Wait for both child Actors to reply. 3. The top-level Actor writes the settings to the INI file. This doesn't seem like a sensible approach, though. Waiting for message replies sounds like the wrong thing to do. I wouldn't know where in the block diagram to implement this scheme, either. Can anyone offer me any advice? There must be a fairly standard way of doing this that I'm missing! Thanks in advance, Chris --- Dr. Chris Empson Robot Screening and Instrumentation Specialist School of Chemistry University of Leeds UK CLD

Hello All, Long time reader, first time poster. I have learned a lot from lavag, and really appreciate what you all do here. I am building an LVOOP architecture that sort of straddles the line between AMC and AF. One of the most frustrating things I have run across (as with most AF type architectures) is debugging shared clones. I've run into some behavior that I did not expect and wanted to see if anyone knew what was going on. First some definitions: Behavior A: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the original, "uncloned" VI, reserved for execution. Behavior B: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the active, running clone VI, which is capable of being debugged. I once thought that behavior A was how LabVIEW worked, however in developing this framework, I have found that some subVIs show behavior B. Behavior A and B seem to correlate to dynamic and static dispatch methods respectively, but I can't make sense of why. If I create a simple example without OOP (see attached), I get behavior A. Has anyone ever seen this behavior, and if so, am I missing something really obvious? Secondly, does anyone have any tricks or best practices for getting into active clones to debug? My only idea at this point is to include some sort of notifier/queue/etc to active a Front Panel Open Method. Thanks in advance! Drew T. CLA, CTA

I'm looking for a Node Map tool to document my applications using my messaging architecture. I want to write some code that can extract relationships between classes (some being processes and some being messages) and then feed that data into a tool to visualize the relationships in my application. The end goal would be something like the http://www.visualthesaurus.com/. Unfortunately, the software behind that tool starts at $5k. I am hoping to find something a bit less expensive. Has anyone found a solution they like? thanks, -John

Hello all! I am new to LAVA, but I have been lurking for many years and have gotten a lot of great advice and insight into LabVIEW programming here. I recently got my CLD, and I'm trying to get a better handle on doing things the Right way. One issue I run into regularly is how to deal with class private data. I typically use device classes, where each class represents a different embedded device that my application communicates with. One main loop is used to send/receive data from each device, and then other loops handle the UI updates, background calculations, etc. I think that is all pretty standard. Due to the by-value nature of wires, I cannot create a device class and pass it to several loops without forking the device private data. When the main update loop updates the class's private data, all other loops do not see this change due to the class having been forked. So what I've ended up doing is putting DVR references in each class's private data, and then the get/set accessor VIs use an IPE structure to access the data via the DVR ref. This all works pretty well, but on many forums (especially NI forums) I see seasoned LV programmers saying that DVRs + IPE should almost never be used. I've considered using FGVs instead of the DVR, but that seems similar in that the data would be stored in the FGV instead of the class's private data DVR, so what is the difference? I feel like I must be missing something here. It seems that class private data should be a DVR by default, otherwise what is the point if the class wire is forked? How do you guys deal with this issue?

So this is meant as a continuation of a discussion of relative merits of inheritance versus composition between myself and Shaun R to be found HERE.

Hi, I would like to play an idea out to you about having a composite class put itself back in its owning object by a DVR. Is that a good or a terrible idea? Background I need a class that represents some different LabVIEW files, and which can offer some operations on those files; LVFile.lvclass. LVFile.lvclass has some children (LV file types) and it owns a composite object LVFileRefs.lvclass: LVFileRefs LVFileRefs contains the following: - An enum stating the file type. - A reference to the LabVIEW file (class reference, library reference, project reference, or VI reference). - The path to the file on disk (if it is saved to disk). - Info if the refnum was created by the object or passed in from the outside (used by the Close method). I need LVFileRefs as a composite object (instead of that data living inside LVFile) since New starts by instantiating an LVFileRefs object before New can decide which child to instantiate: One of the responsibilities of LVFileRefs is to keep disk path and file reference synchronized. This means that you could start out with a VI in memory for instance, and create an LVFile object for that. This does not yet have a File Path. If you then save that VI, then LVFileRefs will update its internal File Path field from <Not-A-Path> to the proper path. If for whichever reason the original file refnum goes stale, LVFileRefs will also be able to open a new refnum from File Path if possible. All transparent to the user. So LVFileRefs maintains a firm grip of the file whether it being in memory only or on disk, and it can tell you which type it is (some types take more programming to tell apart than others, and type can change as well). All stuff that makes writing apps that handle many different file types simpler. No DVR approach Normally I wouldn't expose a naked refnum to the user, but one of the features of LVFile is actually to serve the proper refnum, so in this case I do. That is currently done with accessors on LVFile, and then an LVFileRef method: Since LVFileRefs can update its embedded refnum it is important to write the LVFileRefs object back into the owning LVFile object (or else Close for instance wouldn't close the correct refnum, and several other issues). DVR approach Having to write back the LVFileRefs object is error prone - the user could forget to do it, and having to do it in the first place is irritating. I'd rather you could omit the write back step: The idea is to have LVFile embed a DVR to itself inside its LVFileRefs object, with which LVFileRefs can write itself back into its owning LVFile object with whenever LVFileRefs has updated itself. There shouldn't be any racing possible, as LVFileRefs is actually the representation of the LV file, and DVR access is mutexed. Am I insane considering this? Cheers, Steen

Hi all, I am trying to have an OOP based architecture inside RT ,where FPGA acquired values are used inside RT. So my plan is to have a generic base class upon which different systems(Child classes) are built. My child FPGA VIs will have additional controls in Front panel along with the common ones. So where can I put the FPGA ref? I cannot have it in base class since it will not bind all the controls. But if I have it in Child classes, how can I have the common functions in Base class? Looking forward to your suggestions guys..

Hi, I need advice on how to exchange messages between 2 classes or 2 objects. So far I am using LVOOP mostly because of data encapsulation and inheritance feature. Now I need communication between 2 objects A and B running parallel. Each object can send message to another. I can send message one way by using composition relationship. I put one class inside another class cluster, for example B inside A cluster. Then later from inside class A, I can use class B reference to send message to process of class B. But I don't know how to send message back from B to A. Is there any design pattern about this? Or is there any example? I can do this without using class by using name queue but I would like to learn how to do this with LVOOP. I read about actor framework already but I don't want to use it now seam it's a little bit complicated for my project. Thank you for your time reading and answering my question! Thang Nguyen

I have a fundamental question on HALs and abstract methods that I'd like clarified, please. In my HAL's up to this point I've been using a parent with abstract methods, implementing concrete methods in the concrete product(s) (see here for example), and using dynamic dispatch as appropriate to execute the concrete method. I think this is a standard technique and it works fine for me. Now I have another layer of abstraction I want to implement, but in this case the concrete products share a lot of functionality and often I can get away with just executing the same method for each product. Should I just go ahead and implement this logic in the parent method? If I do, that means I no longer have abstract methods in my parent (right?), so am I breaking some 'good-practice' rules in OOP design? Or am I just getting bogged down in semantics? [by the way, I have loads of little niggling questions like these which I may ask as I'm going along in my OOP learning - hope you don't mind.]