Search the Community

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.

I am posting this in the Application Design and Architecture forum instead of the OOP forum because I think it fits here better, but admins feel free to move the thread to the appropriate spot. Also, I am posting this to LAVA instead of the AF forum because my questions relate to all Actor Orientated Programming architectures and not just AF. Some background, I looked at AF and a few other messages based architectures before building my own. I stole liberally from AF and others to build what I am using now. But I am having a bit of a crisis of confidence (and several users I am sure will want to say 'I told you so') in the command pattern method of messaging. Specifically in how it binds all actors in your project together via dependencies. For example: If Actor A has a message (that in turns calls a method in Actor A) to create an instance of Actor B, then adding Actor A to a project create a static dependency on Actor B. This makes it impossible to test Actor A in isolation with a test harness. The recent VI Shots episode about AOP discussed the need to isolate Actors so they could be built and tested as independent 'actors'. If Actor B also has the ability to launch Actor C, then Actor C also becomes a dependency of Actor A. And if Actor B sends a message to Actor A, then the static link to that message (required to construct it) will create a dependency on Actor A for Actor B. So, the end result is adding any actor in your project to another project loads the entire hierarchy of actors into memory as a dependency and makes testing anything in isolation impossible. This is the effect I am seeing. If there is a way to mitigate or remove this issue without abandoning command pattern messaging, I would be very interested. In the meantime, I am considering altering my architecture to remove the command pattern portion of the design. One option I am considering is to have the generic message handler in the top level actor no longer dispatch to a 'do' or 'execute' method in the incoming message class but instead dispatch to an override method in each actor's class. This 'execute messages' method would then have a deep case structure (like the old QMH design) that would select the case based on message type and then in each case call the specific method(s) in the actor to execute the message. I would lose the automatic type handling of objects for the message data (and have to revert back to passing variant data and casting it before I use it) and I would lose the advantages that dynamic dispatch offers for selecting the right message execution code. I would have to maintain either an enum or a specific set of strings for message names in both the actor and all others that message it. But I will have decoupled the actor from others that message it. I think I can remove the launch dependency by loading the child actor from disk by name and then sending it an init message to set it up instead of configuring it directly in the launching actor. I guess am wondering if there other options to consider? Is it worth the effort to decouple the actors or should I just live with the co-dependency issues. And how does this affect performance? I suspect that by eliminating all the message classes from my project, the IDE will run a lot smoother, but will I get a run-time performance boost as well? Has anyone build systems with both types of architectures and compared them? I also suspect I will get a benefit in readability as it will be easier to navigate the case structure than the array of message classes but is there anything else I will lose other than the type safety and dispatch benefits? And does anyone who uses AF or a similar command pattern based message system for AOP want to try to defend it as a viable option? I am reluctant to give up on it as is seems to be the most elegant design for AOP, but I am already at 326 classes (185 are message classes) and still growing. The IDE is getting slower and slower and I am spending more and more time trying to keep the overall application design clear in my head as I navigate the myriad of message classes. I appreciate your thoughts on this. I think we need to understand the benefits and pitfalls these architectures present us so we can find a better solution for large LabVIEW application designs. -John

Hi all, I'm trying to programmatically create and modify LVClasses. So far, I've managed to do the following via LabVIEW scripting: Create a new LVClass Save the new LVClass to disk Make one LVClass a subclass of another Create property definition folders My next step is to create class methods (static dispatch for now), but I'm stuck. I can't figure out how to add an LVClass control/indicator to a VI. I tried the following, but LabVIEW complained, "Type mismatch: Object cannot be cast to the specific type". I can't find any other LVClass-related items in the list. I tried to figure out what I should pass to New VI Object.vi, by querying an existing static dispatch VI as follows: Apparently, the FP elements I want are called "LabVIEWClassControl", and they have a ClassID of 102. However, "LabVIEWClassControl". isn't available in the list. When I wired 102 into New VI Object.vi, I was told "The specified object was not found." How do I programmatically drop an LVClass control/indicator into a VI? More fundamentally, how do I script a new static dispatch VI? Thanks in advance!

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've recently built a medium-sized application that controls a bunch of devices in a university laboratory. From the start, I've been focussed on writing a modular, extensible program, as people tend to add or remove equipment and write new measurement routines accordingly. In my architecture, each device is represented by an Action Engine (i.e. Keithley Controller.vi). The UI is comprised of subpanels that contain a simple UI for a single device (i.e. Keithley Panel.vi). Due to the nature of AE's, any vi can send commands to any device; data changes are communicated to the panel through User Events. This all works really well. Creating new measurements is extremely simple, which is vital as most of my colleagues and students are LabVIEW novices. Adding a device is relatively simple too, as Action Engines are easily understood. And now, the downsides. Mainly, there is a lot of code duplication in this architecture. Many AE's look very similar, with actions like Set VISA Address popping up in every single device. Moreover, imagine having two identical Keithleys (a very real prospect)... one would have to duplicate each vi to create Keithley A and Keithley B, which seems silly indeed. Also, I don't particularly like the extensive use of Variants to limit the number of inputs on the AE. All this tells me it's time for LVOOP, but so far I haven't found a satisfactory design pattern for my use case. The problem is that classes in LabVIEW are by-data instead of by-reference. Somehow, I need to get class instances of my devices across to different parts of my application (including measurement plug-ins), without having them operate on different copies of the instance. Solutions to this problem seem to come in two flavours: communicate to each instance via a command queue (Actor Framework) or operate on references (DVR, Single Element Queue). I find both approaches unsatisfactory: the former buries the elegance of a class (properties and methods) under a pile of asynchronous mumbo-jumbo I don't need, while the latter can introduce deadlocks and forces my users (students and co-workers who will create measurement routines) to place all calls inside de-referencing blocks (be it an In-Place Element structure or a Checkin-Checkout procedure). Finally, I should mention that I'm aware of the existence of GOOP, which seems to enable by-reference OOP in LabVIEW, but I would like to stick to native solutions if at all possible. Is there a way of harnessing the power of OOP (inheritance, instancing) in LabVIEW, without moving to asynchronous designs or potential deadlocks? Where do I go from here? PS: my apologies if this turned into something of a rant, but shifting to the OOP paradigm in LabVIEW seems overly complicated compared to other languages.

Hello, everybody.I'm new to the LVOOP and I meet a problem in my wafer auto-test system about the class responsibility. the wafer auto-test system uses many instruments to measure the wafer parameters such as Vbr, Vf... Firstly, I want build class for every instrument. For example, I have create a app class named WaferTester, and many instrument classes such as Keithy 2600B class, EXFO PM1600 class, etc. The WaferTester class contains these instrument classes. However, I also want to create parameter class such as Vbr class, Vf class. These parameter class have many properties such as test delay time, upper limit, lower limit etc. Most importantly, the parameter class have a method to get parameter measurement result. For example, when calling the measure method of Vbr class, it use instrument to measure the Vbr parameter of the wafer and return it to the caller. My question is about the relationship the instrument class and the parameter class. The method of parameter class will use different instrument classes, so the instrument classes is a part of the parameter class. For example, the Vbr class will contain Keithy 2600B class. However, different parameter class may use the same instrument and I think the instrument is a static part of the test system. I have no idea to achieve a reasonable relationship about the parameter class and the instrument class.

I wrote a Labview program that uses LVOOP that worked correctly. I then modified a class to allow access to one of the object control elements via a property node outside of a member method VI. As a result, a member method VI that writes to that element using named-bundle ceased to function correctly. No broken arrow nor broken wire, but the object output of the VI did not include the new value in that cluster element. I cured the problem by writing to the element using a property node instead of named-bundle. But I shouldn't have had to do that because I should be able to update elements using cluster functions if on the diagram of a member method VI, right? Do you think this a Labview bug, or is LVOOP supposed to work this way? LV 2012 SP1 f5 on Windows 7 32-bit. Thanks. -Joe

I am new to Actor framework and would like to know how to continuously display values read from hardware. The project contains cDAQ class and in Unit test folder is the demo vi called " TestcDAQ9203_ContinuousReading.vi". This VI is actually a QDSM but to simplify I have placed a while loop and set to continuously acquire.How do I 1. Display the readings using queues instead of globals?2. Even when I stop the top level VI the methods in cDAQ class keeps running, how to stop these?Thanks and please advice. Project attached. UnitTest2.zip

Hi everybody, this is my first post here. I am a LabVIEW engineer (CLD) and only recently started to learn LVOOP, specifically the Actor Framework shipped with LV. I have read the whitepapers, presentations and the Evaporator Cooler example, but I'm still struggling with real life programming problems. I'm having a lot of difficulties switching from task-based thinking (JKI State Machine) to LVOOP thinking in Actor Framework and I'm hoping for some good advice here. Basically, my biggest problem is defining what should be an Actor and what not? For this purpose, let me describe my software requirements for a machine vision application in a task-based approach: Init Load settings from file Init Camera Init DAQ device Start GUI [*]MAIN LOOP: Poll for external trigger on Camera IF TRIGGER == 1 Acquire image from Camera Analyse image to get result OK (1) or FAULT (0) Send result to digital output IF RESULT == 0 [*]Update GUI [*]SHUTDOWN: Save settings to file Release Camera Release DAQ device Exit app Camera can be selected at runtime (USB camera, ethernet camera, simulated camera (ie. load images from folder), etc.) - HAL for Cameras Settings (for image analysis parameters) can be changed during operation and applied to image analysis without restart of application Each step can be timed (acquisition, analysis, etc.) - not a high priority, but is a nice feature for client Error handling Timing is crucial. Only a couple hundred milliseconds are available for the whole process. The application must NOT MISS an external trigger and MUST send the result to digital output as fast as possible. This is my current attempt of Actor organization, based on the Evaporative Cooler example: ActorTimed Loop Controller Get External Trigger (needs Camera handle from Camera class, which contains child classes for each camera) [*]Image Acquisition (needs Camera handle) [*]Image Analysis (needs analysis parameters) [*]DAQ (needs Device handle) Send Result OK Send Result FAULT UI abstract layerGUI GUI for changing/updating settings [*]Settings (needs Camera handle, Device handle, analysis parameters, etc) I think this design is flawed, because I am having problems that should not happen with this design pattern: sharing data between Actors (for example camera device parameters between actors get trigger, image acquisition and settings). How should the Actors in the Actor Framework be organized for such an application? What do you recommend? Also, should I have a Main (Controller) Actor? Save Image to folder

I have an application where I am loading plugins from disk and executing them. Each plugin is a child class of my plugin class. I am using the factory pattern. During development, I started out by having a static plugin class object for testing purposes and then later switched to loading the plugin class default value from disk. My architecture works by dynamically launching a generic plugin handler that then loads the required plugin class and dynamically launches a method in that class. So, the handler and the plugin are disconnected from the main application. They communicate using messages. I am launching many of these plugins at the same time. A common use case would be in the 100's (this is a test system) When I switched from the static object to loading the classes, I noticed a significant slowdown, especially with higher #s of plugins (100+) loading at once. I did an experiment to make all the plugins being loaded be the same so it should only incur the disk load of the class a single time. When I compare this to the static plugin version, there is a 4x reduction in execution speed. So, it seems that the function that gets the default value of a class is much slower and more resource intensive than using a static object, even if the class is already loaded into memory. I also suspect that this function runs in the root loop, causing blocking issues. Does anyone know of a way to speed this up or mitigate the slowdown? In the past I used to cache refs of dynamically loaded plugins (before LVOOP) so I would not incur the load penalty. There does not seem to be a way to do this here that I am seeing. thanks for any ideas. -John

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

Hello LAVA! Long time lurker, first time poster. I had posted this question on the NI LabVIEW forum, but I would like to hear from you all as well. I have an array of lvclasses inside an lvlib, as shown in the attachments below. I'm looking to get the reference (path) to the individual lvclass I need dynamically, at run time. This lvlib is not inside the EXE. The goal is to be able to modifiy or add classes to this lvlib without having to change the rest of my code, or rebuild the EXE. Particularly, the code snippet that loads the lvclass will be from a built EXE. How do I dynamically call these lvclasses inside that lvlib?

[cross posted to forums.ni.com] Greetings LVOOP masters. I realise this is not a simple question but I would really appreciate your opinion please. I'm trying to make some data handling improvements to a test sequencer application that I've written. User defined tables determine how much data is acquired. Long tests can easily generate 100's of MB's of data. Collecting, analyzing, reporting and saving that data tends to create copies and we can easily run out of memory. It's currently written without any LVOOP methodology but that is about to change. I'm new to OOP but have been reading alot. I have 2 objectives in refactoring the data handling VIs: 1) Enable different measurement types to be collected, analyzed and saved according to their unique properties. Presently any measurement type that isn't a dbl waveform is shoehorned into one and treated exactly the same. XY style data is resampled losing resolution and digital data is converted to dbl. This results in a lot of extra data being generated for no good reason other than to fit in a waveform. 2) Reduce data copies. Because the measurements are shuffled around from one module to another the copies become a problem. I'm hoping to use DVRs to the objects and pass around the references instead, reducing copies. I'm quite comfortable with objective 1, it's number 2 I'm not sure about. After reading this excellent whitepaper here I feel I need to get some expert advice on whether my approach is correct. In particular these two statements have raised questions in my mind: "Be aware: Reference types should be used extremely rarely in your VIs. Based on lots of looking at customer VIs, we in R&D estimate that of all the LabVIEW classes you ever create, less than 5% should require reference mechanisms." "LabVIEW does not have "spatial lifetime". LabVIEW has "temporal lifetime". A piece of data exists as long as it is needed and is gone when it is not needed any more." Q1. With that in mind, will all my effort to use DVRs actually reduce data copies significantly in my case? I plan to have a single FGV VI where the objects are created and stored in an array. Then when other modules need access to the data, a DVR is created and handed out. Once these modules are finished with the captured data, they flag it as deletable and the measurement FGV deletes the DVR and removes the object from the array. Q2. Is that the right way to go about it or am I missing the point of LVOOP and DVRs? Below is a simplified mockup of the way measurement data is currently used in the application. LVOOP Experts: Your feedback/suggestions are much appreciated. LVOOP DVR Measurement Optimization.zip

Hi all, first post and I hope nobody minds that it's quite long. I've finally started to move into LVOOP and I'd really appreciate some help on the first example program I've designed. It's based on the Command/Factory pattern posted by Elijay_K on NI (I've even unashamedly adopted his color schemes for the loops!). I'm a bit wary that my questions will be too basic for this forum, but anyway, here goes... First, a quick description of the application I work with (see 'application.gif'): it's a digital voltage regulator which can be accessed by two interfaces, an I2C PMBus interface and a SVID interface (both are just digital power communication interfaces). In my program I just picked a few simple tasks to do (see 'front_panel.gif'): Read back basic info from the device (part name, FW version, etc). Carry out basic control of the regulator, such as setting the output voltage, over-voltage limit and switching it on. Read and write some internal registers. Continuously monitor a small sub-set of registers, and update a Vo plot. For the code, I currently have four loops: (1) Event handler to send commands to other loops, (2) PMBus communications loop, (3) SVID communications loop (4) UI Display loop to update front panel indicators (device info, monitored register values, 'power-good'/OVP fault). Note that the SVID loop has no real functionality yet; I just access the device using the PMBus interface. I currently have three parent classses, one for each consumer loop: pmbus_generic.lvclass, svid_general.lvclass, display_generic.lvclass. Then for each child class I just have an Execute method to carry out specific tasks e.g. read/write a register using the PMBus loop, update the plot using the UI Display loop. This brings me to my first question: (Q1) All my low-level functionality is carried out using legacy VI's (non-OOP) that I use as normal in my standard QSM architectures. So I found that I didn't need to define any data in the .ctl clusters for any class at all, yet everything works with no issues. Basically I think I have a dynamic dispatch OOP program which just contains methods but no private data at all. Is this okay? It works and all, but I feel like I'm missing something... (Q2) I just leave my 'UI Update' loop free-running, but this doesn't feel very elegant. In fact I have to 'Stop' that loop directly, and then use that event to stop all the other loops. Is there a more standard (OOP?) way to continuously update front-panel indicators in this sort of program? (Q3) I'd like to add some sort of logging functionality which takes information from both device interface loops- what's a good way of doing that? I'm thinking of using another loop and a related log class which receives data from the other loops. Is this the right approach or is there a better way? I'm assuming I need to be careful about one loop receiving data from two sources? (Q4) For the waveform plot functionality, rather than having it fixed I want a pop-up type window which will display a whole range of waveforms from the application. Do I need to go down the plug-in route here? (i.e. add a plug-in loop and class?). (Q5) I also want an Options dialog which I can pop up at run-time and change settings. Do I need another loop and class? Perhaps have it as part of any plug-in functionality? Or are there any other elegant config options I can use in OOP? (Q6) Just thinking, is the pattern I use here even the best choice? Is there a more standard pattern that I can use for what is really just a basic device-control GUI? Ultimately I want to code a much larger app which has lots more of the same functionality as this basic example, so I'd like to get the pattern right from the start. I've attached a ZIP file of the project, but there's probably a lot of low-level drivers missing; I don't think that matters (hopefully just the basic architecture is all anyone needs). Also, if I'm doing anything in general in the program that's completely idiotic, please point it out! And again, apologies for the length of the post. If it helps I don't really need detailed answers, just pointers in the right direction... Very Basic UI.zip

Hi, following some suggestions for improvement of LVOOP which i'd like to see in LVOOP in a future version. Please note that all those questions refer to an architect level! 1. Constructor: LV enables the programmer to name a VI equally to the class the VI contains. So it is possible to generate a "constructor", even though we don't necessarily encourage the user to do so. See attached example for this. The idea is to create a "constructor" VI which creates an object and calls required initialization routines internally. An example would be configuring an instrument for a specific HAL class. An often used feature for such constructors is "overloading", so having different sets of parameters while keeping the same function name. Currently this is not supported in LV. What do you think about this feature when talking about constructor VIs as explained above? 2. Destructor: This is tricky since most OOP guys would expect this to destroy the object, which in case of LV is obviously most often not the case. Still, it could be used for de-initialization for the user of the class. See attached example for this. 3. Polymorphism/Inheritance: In some cases of OOP, it would be beneficial to have polymorphism for class functions, sometimes directly connected to inheritance. Small example: Class "DataAcquisition" defines general IO functions. Class "AI" inherits from DataAcquisition, overriding all AI functions. Polymorphism should be used for DataOut since Data could be a waveform, a 2D array, .... Additionally, polymorphism could be used for inheritance directly if parameter types depend on the specific class. E.g. aggregation collects different class objects. 4. Singleton: One can create a singleton as seen in attached example or on https://decibel.ni.com/content/docs/DOC-13462. The problem i got with this singleton pattern is that the object within the DVR (the singleton) cannot be used for dispatching, hence no inheritance override possible. In order to get this to work would require the following change: The connector pane terminal of type "LV Object" and "DVR to LV Object" shall be configurable to "Dynamic Dispatch Input (Required)". Currently, this option is only working for "LV Object". 5. Overloading: As already stated in point 1., overloading would be a nice feature for constructor VIs. Adding to that, overloading could be a nice feature for inheritance as well. So the override function can add (not remove!) additional parameters without the need to define a generic data container (e.g. variant) in the ancestor class. 　 I know that all features, except 4. Singleton, can be solved differently, best done by appropriate wrappers. But i think that some developers could profit from LV opening up to more a common OOP approach used by other OOP languages. @NI R&D: If some of these are already on schedule, please let me know @All: Please discuss! thanks, Norbert Singleton.zip ClassConstructor_Destructor.zip

I have a class that defines a message. I inherit from this class for all my messages. The class contains a must override method called 'Execute'. Every time I create a child of this class and create the override method for Execute then go to save it, it wants to save the parent as well. This only occurs after I create the override method for Execute. If I just create the class, save it, change its inheritance and save it again the parent class is not affected. I have no idea why it is doing this but it is really annoying. Especially since everything is in version control, I end up having to check the parent out just to save the project. The reason given for the need to save the parent is 'Item moved within library'. The parent class is in a lvlib. I am running LV 12.0f3. Any ideas? Is there a CAR for this or am I just doing something wrong? thanks, -John

Name: Data Broadcasting Library for Actor Framework Submitter: Stobber Submitted: 01 Apr 2013 Category: *Uncertified* LabVIEW Version: Not Applicable License Type: BSD (Most common) Use v1.0.0 for LabVIEW 2011-2012. Use v1.1.0 for LabVIEW 2013+. The attached library provides extensions to the Actor Framework to facilitate the broadcast of messages from one actor to several others. Listeners subscribe to a message when they want to receive it from the Broadcaster, and they unsubscribe when they want to stop receiving it. The library provides a set of common interfaces that decouple Broadcasters from Listeners so any two actors in a messaging hierarchy can communicate via broadcast without having the same caller. This library extends the Actor Framework; it does not modify the core framework in any way, so it may be used in existing projects as well as new ones. Documentation for the library and the included example program is attached. Click here to download this file

I have been seeing some weird behavior and was wondering if this is a known issue or if I have discovered something new. I have two projects that share several libraries and classes. One is a client application and one is a server. In order to test my code, I need to open both projects at the same time and run the main VIs. When I open the projects, the common libraries and classes are locked and I cannot edit them. So far, this appears to be normal. Where it gets strange is when I close one of the projects. If I have run the VIs to test something and then stopped them, closing the owning project of one of the main VIs DOES NOT cause the VI to also close. The correct project name is still indicated in the VIs window (lower left) and the project is clearly closed but the VI is still hanging around. The second thing that is weird is the common libraries and classes remain locked. Even closing the other project and returning the to the start-up screen does not correct this. The only way to edit those files again is to close LV completely and then reopen it. This is getting a bit tiring and I am just starting to develop this project. I am working with LV2012f3 but have not yet tested this in the 2013 beta. (I really do not want to port the whole project over at this time). Any thoughts? Anyone else seen this? I checked the known issues link and did not see anything related. http://www.ni.com/white-paper/13993/en thanks, -John

I am trying to solve a bit of a chicken-egg issue with my message system. Since I think this would apply to any message system, I would like to hear how others have addressed this issue. In my message system, each parallel process has a message handler loop that receives and executes messages. A process can also have code that runs in parallel with the message handler to implement additional functionality, such as a UI loop that handles events. If an error occurs in this UI loop, it sends the error to its message handler. The message handler then executes the message with the error information, outputting the error as if it happened within the message loop. This then propagates to an error handler that executes specific error handling code for that process and then sends the error info to an error logger process. I also have implemented a broadcast message to shutdown the application. This sends the shutdown message to all processes at the same time. The problem I am running into occurs if an error is generated in the UI loop when it tries to send the shutdown message. That error is not getting handled. This is because the message handler gets the shutdown message before the UI loop has a chance to send the error data. So, there is nothing listening to the error message. And even if it was still listening, the error logger process has also already shutdown so the error would not be logged either. So, any ideas on how to solve this? How do you deal with this in your messaging systems? thanks for the feedback, -John

Hi all, In order to teach myself to use LVOOP -it's about time to start- I've decided to start with a little project that I've had in mind for a long time, I've called it LVOOP VIServer, I hope it doesn't sound too pretentious. The idea is to make a hierarchy of LVOOP classes that matches the LabVIEW Controls class hierachy in order to take advantage of dynamic dispatch. In a way it is related to this LIE Idea : Improve the "cluster to array" primitive For now I've implemented the parent class "Control" and two child classes "Path Control" and "String Control" and a bunch of VIs to read/write position, size, caption text, caption font and font. If anyone is interested in reviewing the code, providing advice or whatever... I've kept it small enough so that if the core concept is not good it can still be changed. The code is hosted on GitHub here, it should be accessible to anyone, let me know if there is any issue of if you would like a zip in this thread. Cheers

This is my first post on LAVA although I have been using LabVIEW for five years. I thought LVOOP in LAVA is the best place to ask this question so I am doing. I have been considering the Models of Computations (MoC) in LabVIEW, it is based on actor oriented design that is utilizing data-flow programming MoC and bla bla... But I couldn't answer myself why Object Oriented programming paradigm was required in an Actor oriented based design. Either we have a relation with OOP based languages that's why pushing OOP into LabVIEW or LabVIEW is not actually based on actor oriented programming paradigm or actually I don't understand it If LabVIEW is based on actor oriented design then shouldn't we exploit actor oriented design principles? OBS! Remember this post is not related to Actor Oriented Design Pattern available in LV 2012. regards, Imran Certified LabVIEW Developer