Search the Community

Hi All, This may be my naivete, but I wanted to know if there is a way to dynamically load the motors (DLLs). Or do I have to load each motor type DLL separately for the front panel (.Net container) of the child class of a motor class? Cheers, M

Hi all, I'd appreciate some advise or pointing in the right direction regarding building an EXE with class dependencies. I have a project built with actor framework and when I build it to exe, I get lots of dependencies which I think should be included in the EXE as seen below: On my Source files build properties page I currently have nothing under Always Included. I did try including all of the lvlibs and including them in the EXE but it didn't make a difference. In summary, I think the way my EXEs are building is not right. It is easy to see what VIs I'm using (although you can't open them) and it doesn't look very professional. What are the best practices for building dependencies into EXE? Thanks

Goal: Find the best methods (or at least some good options) for message decoupling that are simple to implement and efficient to execute. Background: Messaging architectures in LabVIEW that use a class for each unique message type are strongly coupled to the recipient process (aka ‘Actor’). This is due to the need within the message execution code (a method of the message class) to access the private data of the recipient process or to call methods in the recipient process in order to do the work that the message intends. (See Actor Framework for an example of this). The problem arises when you wish to send these messages across a network between two separate applications. In most cases, these applications are not duplicates of each other, but rather serve completely separate purposes. An example would be a client and a server. The client needs to message requests to the server and the server needs to push data to the client. For a process to send a message, it needs to package the inputs in the private data of the message class and then transmit it via the network transport (which can be implemented in multiple different ways and is not material to this discussion). In order to construct the message, the sender will need a copy of the message class included in their application. This will mean they will need to also load the class of the message recipient since it is statically linked to the message class within the method that executes the message. And since that will trigger many other class dependencies to load, the end results is the majority of the classes in the recipient application will need to be included in the sending application. This is not an optimal solution. So, we need to find a way to decouple messages from their recipients but still be able to execute them. My solution: The way I have been handling this is for each message that needs to cross the network I create a message class whose execute method calls an abstract method in a separate class (call this my network message execution class). Both the sender and the recipient will have a copy of these message classes and the network message execution class. Inside the message class’s execution method, I access a variable that stores an instance of the network message execution class and then calls the specific abstract method in the network message execution class for this particular message. In each recipient application, I create a child of the network message execution class and override the abstract methods for the messages I intend to receive, placing the actual execution code (and static links to the recipient process) within the child class methods. Finally, when each application initializes, I store its child network message execution class in the aforementioned variable so it can be used to dynamically dispatch to the actual method for message execution. The advantages of this are: Messages are decoupled between my applications. The disadvantages are: For each message I wish to transmit, I must create a new message class, a method in the network message execution class and a method override with the real implementation in the recipient’s network message execution class child and then edit the message class to call the method in the network message execution class. This also means that each application must have a copy of all the message classes passed between applications and the network message execution class. The problem arises when you add a 3rd or fourth application or even a plugin library to the mix and wish to decouple those from the other applications. You must either extend the current set of messages and the abstract methods in the network message execution class, having each entity maintain a copy of all of the messages and the network message execution class even though they never send or receive most of those messages, or you must add additional variables to your application to store different implementations of the network message execution class for each link between entities. So, now that you have read my long explanation, does anyone have ideas for a better way to solve this? I would love to simplify my code and make it easier to maintain, while retaining the functionality that class based message architectures offer. But decoupling must be addressed somehow.

If you have your class and you want to create a pull right menu on a property node for it, you can use the colon ( to separate property items for it. Just right click on the class » Properties » Item Settings » Localized name. Also, on a separate note and since I'm in the neighborhood, you could also take advantage of the "Documentation" tab in the Class properties to change the "Localized name" from the default (in my case, "NI_VSA.lvclass") to something shorter or more meaningful. .This makes it easier on the eye. Regards

I am trying to export a class in LabVIEW 2013 to a .NET Assembly. According to this I can just select the members of the class that I want to export and it will generate a .NET class for them. http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/building_a_net_assembly/ I am able to export the individual members of the class, but when I run the code in .NET it starts searching for mydllname.dll/myclassname.lvclass (the file of the class that the exported members belong to) and can't find it. My next step was to add the class to the the Always Included list, but it seems that when I do that some of the members that I have in the Exported VI's list don't show up in the .NET assembly. The class I'm trying to export is inhereted from another class, so I tried adding both classes to the Always Included list and all of the base class members to the Exported VI's list, but I still have members missing in the .NET classes. Thinking it could be something releated to exporting LVOOP classes, I tried ditching the LVOOP class altogether and rewrote the labview code to use generic VI's and a cluser typedef to store the member data. However, it seems like the labview builder doesn't recognize that the control and indicator clusers that I use to pass the member data belong to the same typedef, so it exports a different .NET class for each control and indicator cluster. This creates a problem because I have no way of passing the output of one funtion to the next in .NET since I cannot convert between the two .NET types. Has anyone had problems like this/know how to fix it??? I couldn't find much online about building a .NET interop assembly beyond the basic configuration steps, so any help would be much appreciated! Thanks

Hi, Here comes a rather basic question but which I'm always struggling with since you can often argue both ways. Hopefully some of you have a few nuggets to share here... 1) A parent class should have no knowledge of any child class' concrete type, i.e. only data and methods that is inherently common to all decendents of that parent should be defined by it. 2) For dynamic dispatching to work the parent class must define virtual methods for dynamic dispatchees to work from. Those two rules often contradict each other. Methods vetted against 1) will often eliminate the possibility of 2). A specific example: Currently at GPower we're working on a set of classes that enables us to do a lot of stuff on all the different LabVIEW files. So, we have a parent file.lvclass and then a collection of specific children that inherits from "file", for instance vi.lvclass, lvproj.lvclass, ctl.lvclass, facadevi.lvclass etc. A) Generic stuff that has to do with any file obviously goes into file.lvclass data (together with data member access methods for each). For instance IsWriteprotected?, FileSize, FilePath and such. A FileRefnum should probably go into each child class to enable us to have it most specific. B) Then there are data elements that definetely has to do with each concrete file type and thus should be in each child class' private data, such as AllowsDebugging?, IsFPStyleOK?, Icon etc. - as those are only valid for a subset of file types. C) Now it gets a bit more murky; If we define data elements in file that each child can use to flag if it has this or that feature (like HasIcon? or SupportsProtection?), then you can ask each and every file type if it support that, before calling a method to work on that. For the subset of file types that supports a given feature (those that has an icon for instance) it'd be great to have dynamic dispatching though. But for that to work file.lvclass would have to implement virtual methods like GetIcon() and SetIcon() (where the latter maybe recalculates the IsIconStyleOK? data field for instance). But implementing these (numerous it turns out) virtual methods in the parent class, suddenly riddles the parent class with specific knowledge or nomenclature that is very specific to different subsets of descendent file types. I always vet the parent against each piece of information I'd like to put in there by asking myself something like this: Does my generic file know anything about disk write protection? Yes, all files deal with that, so it can safely go into file.lvclass. Does my generic file know anything about block diagrams? No, only a handful LabVIEW file types knows about block diagrams, so I can't put it into file.lvclass. But the latter forces me to case out the different file types in my code, so I can call the different specific methods to work on block diagrams for those file type objects that supports this. Hence, if I want to be able to just wire any file type object into a "block diagram worker" method I need dynamic dispatching, and that only works if my parent has a virtual method for me to override with meaningful code in a few child classes... How do you go about selecting this balance, on one hand abstracting the parent from the concrete types, and on the other hand implementing the necessary dynamic dispatch virtual methods in the parent? Regards, Steen I must add that I'm currently leaning towards the more pure approach of not mixing abstract and concrete. Thus I tend to omit dynamic dispatching except for the very generic cases. I only allow the "do I support this feature" flags into the parent data, and then I implement static dispatch methods for each concrete type - even though these static dispatch methods then will often be quite similar, but that is solved with traditional LabVIEW modularization and code reuse (like subVIs, typedefs and such). It works well, but I feel I don't get the full benefit of dynamic dispatching. But that is what I'd do in C++... /Steen

I've been bashing my head against the proverbial wall for a couple of days now trying to understand what was corrupt in my LV project hierarchy. On the face of it, all appeared to be fine, but I was getting some very unusual errors when executing my VIs. Errors that hadn't occurred before I rearranged stuff. In my project I have a number of classes, with various inheritances and other defined relationships, and I recently moved some things around to make it, well, better organised. I ensured I didn't destroy the relationships required to maintain access to class methods etc. Indeed, after the rearrangement, there were no broken VIs, and a mass compile (for good measure) came back clean. Now, although the majority of my classes were working fine, I had a very bizarre "Out of Memory" error occurring when accessing the private data of one particular class's DVR via an in-place structure. The private data of the class is nothing more than an array of a cluster of elements. Typically the array is empty, and in the in-place structure I am combining the contents of one class's array of elements into another's. And indeed, in the above error case I had two empty classes, so the build array function had no real work to do, yet I saw some very odd behaviour. Firstly, when highlight execution was on, the array datawire from the unbundle terminal of the in-place element structure should show "#0" to indicate no elements in the array, but in fact would regularly show #84 for one, and I would never get to see the other due to the "Out of memory" error. This was very repeatable, even after rebooting my computer. Where was it getting 84 elements from!? In a generic probe place on the class itself I would see that although the class wires showed normal content (zero elements in their private data), their Value field showed an incorrect namespace entry. This class is owned by a single library, so the namespaced title is mylibrary.lvlib:myclass.lvclass. However, the probe's namespaced title was mylibrary.lvlib:sublibrary.lvlib:myclass.lvclass, where sublibrary.lvlib is a library definition that I emptied and removed a few days ago. Yes, the class used to belong inside this library, but no more. In the library project view, the class can be confirmed to live directly within mylibrary.lvlib only. sublibrary.lvlib isn't even on the file structure anymore, it's literally gone - yet LabVIEW didn't seem to recognise this conflict. After seeing this I realised there was a corruption, but I couldn't see how to properly inspect the defined class ownership properties, or influence it? There's nothing under the Properties panel accessible from the right-click menu? I wondered if dragging the class out of mylibrary.lvlib and back in again would help, but it is changing these ownerships that caused this mess in the first place, so I decided to close down LabVIEW and overwrite the myclass.lvclass file on disk with a backup from earlier that pre-dated the original move into sublibrary.lvlib. Voila, this solved my issue immediately. So I'm quite perturbed to see that a bad ownership property in a class can cause LabVIEW to keel over with very odd execution behaviour, yet otherwise believe everything is fine in the hierarchy itself. Is there a way to inspect class ownership properties throughout a project to look for inconsistencies? To validate the information already there? I already tried a mass compile and that didn't resolve it. Now, I actually want it, and some other classes, in sublibrary.lvlib, contained within mylibrary.lvlib, but I've been trying for two days to recover my project after trying this once. I wonder now if I even dare try to rearrange my classes again!

I have a hierarchy of classes. Call them Grandparent, Parent and Child. I have a dynamic dispatch VI in grandparent that child overrides. In the child implementation, I want to access data in the parent class control. The template in the grandparent has two inputs of type grandparent. The dynamic one and a static one. The dynamic one is used to dispatch to the correct child. (this is because grandparent has more than one parent sub class and these have more than one child subclasses) The static one is used to pass in a parent object so the child has access to its data between calls. (the child is actually a message not spawned from the original parent object and therefore does not contain this persistent parent data) What I need to do is cast the grandparent wire to the type of parent so I can access the parent's data. I could use the child to do this but how do I extract the parent class type from the child and use it to cast the grandparent to type parent? I need to do this statically as design time, not at runtime. thanks for any ideas. -John An alternative solution would involve having the child (message) object inherit the data in the parent object so I could access it via property nodes. Not sure if that is possible.

Hello LAVA, First time poster here, so I'll do my best with background. This situation also happens to be my first exploration of scripting LabVIEW Classes. I am starting with my simplest use case, and scaling as I see some success. I am simply trying to add an existing VI to a newly created class, and facing a strange message when opening the class that I have created. I have attached a snapshot of my code, BD.png The code runs without error, and creates a class in the specified directory with the correct name. What's strange is that when I open the newly created class to view its contents I see the following message: I have tried this same set of events using the LAVA host LVClass API, and face the same error message when opening the class. When I use property nodes to investigate the class members, the VI I have added is listed as a member. I went so far as compare the raw "XML" of a LabVIEW class I created manually in the project explorer to my scripted class, and the property configuration for the class appears identical. For this initial test, I am ensuring that the file I am adding is in the same directory as the class I am creating. The error dialog above occurs after a file search window appears, or I elect to ignore 'missing' items. I am posting here to see if anyone has experienced this behavior, or perhaps my inexperience in this area has lead me to overlook a fundamental part of adding items to a class. I appreciate your time, am happy to provide any additional information, and look forward to your responses. System Specs: LabVIEW 2012 32-bit, Windows 7 64-bit

I have just been reading up on topics of OOP in general and although I've used things similar to Interfaces and Abstract classes in LabVIEW, I didn't realize I was doing it. Due to differences between different text based OOP languages and LVOOP I was just wondering if I could get some of you to speak to these two concepts, whether they both really pertain to LVOOP, and possibly provide some actual examples (not just vehicle, shape, cookie cutter examples, but something I'd actually use) of when you'd define an interface vs an abstract class? I'm basically just looking for general information to help strengthen my understanding of these concepts, and most, if not all, examples out there are text based. While I can figure them out, it's much more time consuming, still leaves me with some grey area, and my brain tends to understand LabVIEW much better in the first place.