Search the Community

Hey guys, I have been teaching myself labview for the past 2 to 3 years. I know other programming languages like java and PHP so OOP is not entirely new to me. I am running into an issue with actor framework, specifically writing/reading private data of actor instances. I have created a simple project that encapsulate my issue. Basically, I have a main vi called "test" that starts an actor called "Prime". Prime immediately starts another actor called "Secondary". Secondary has a string in its private data member, with proper read/write accessors. I created a message to be able to write to the string in the private data. Prime has a message dequeuer in its private data so that it can communicate with secondary. My whole goal is to have both prime and secondary running simultaneously and have you, with the click of a button, update that string in secondary and have the new string show on the front panel. I have been struggling with this for a few days now. I have posted the zip file for the project below. Please help. Actor Message Learning.zip

I've started a discussion with the same subject on the Actor Framework NI Community Site. You can view the discussion and download ArT_Actors White Paper (Draft) here. It makes sense keeping the thread in a single location - please reply & post on the Actor Framework site. Please find a copy of my original post attached (purely for your convenience ) Cheers, Dmitry --------------------------------------------------------------------------------------------------------------------------------------------- All, I’ve been recently looking for a cool Messaging Solution for my new OO LabVIEW Framework. Actor Framework seems to be the best thing in town these days – but, out of the box, it does not provide support for some of my [dear] personal programming habits … so I made an effort to create a custom AF extension - but ended up with a somewhat different implementation of the Command Design Pattern. Major deviations from AF3.0 include introducing the notion of Actor API (a new class hierarchy) and splitting Actor class into purely Functional Domain entity (Actor class) and purely Messaging Domain entity (Actor Component class). Please see attached ArT_Actors White Paper Draft for details. It would be quite interesting to know how many of you consider items 1 – 6 (in the Analysis section) important for your projects and to get a crude priority rating for each (Critical| Important | Don’t Care). I would also appreciate getting feedback on the overall design from those, who have time and patience to go through the White Paper Draft (pick 1 or 2 features you like/dislike most). I am arriving in Austin on Sunday, heading back to Bay Area after lunch on Friday. For those going to NI Week - we can get together and discuss the subject in person .

Hi all, My question deals with how best to distribute large collections of lvclasses that implement a 'plugin' architecture. Some background first: I've been reading the lava forum for about two years and dove head first into LVOOP about a year and a half ago. As such I may be calling what I have 'plugin' when a better term already exisits for what I'm doing; please correct me if there is a better term. The application I've got implements essentially a dynamic form that allows the user to structure properties of a tdms file with information needed to complete some kind of test on one of our products. This 'blank' file is distributed to the correct test stand where it can be used to spawn data files that are populated with information from each test run. Pretty common task I think. To implement this I have a four-tiered class hierarchy: Generic Metadata -> Generic Product Series -> Specific Series -> Specific Model The bulk of the code and all the interfaces are implemented in the first two classes with the last two providing overriding methods as needed for whatever specific product is being worked with (which is why I'm calling it a plugin architecture). This means the last two classes represent an ontology of the company's product line, which means there are a LOT of classes there. Last count I had 24 Specific Series and around 1000 Specific Models. In the development environment, I load the first two classes as constants on the block diagram then use a factory to load the specific classes from disk at run time by building a relative path off of the top level class path. This works well because all the classes are part of my project and are therefore easy to manage on disk, but I need to be able to build this application into an executable and distribute it to the entire company. How can I include the classes in my distribution and load them at run time without making maintenance a nightmare? Would packing each class and its methods into an llb, including all the llbs in an installer, and loading each class from the llb at run time work? Would my dynamic VIs work from inside llbs? Would packed project libraries be a better choice? Do I have to put the entire class hierarchy inside the library or can I compile the top two classes into the exe? Lots of questions! Also I tried to upload a diagram of my class hierarchy, but I think my webfilter is preventing me from uploading anything.

This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. Read this post for start of review. I’d like to suggest these three VIs (or similar) as possible LVOOP-object additions to the OpenG Toolkit: “Get Class Name” is a modification of “Get Name of Class of Object” posted by AQ. Here it just returns the basic class name (which I use often in custom probes and the like). "Get Default Object” is inspired by this discussion and uses AQ’s zero-iteration loop method. This is a very simple VI, but using it instead of the raw code is much clearer to the reader. “Same or child class” just uses “Preserve Runtime Class” as a tester. Again, the advantage here is code readability (or it will be, as soon as someone comes up with a good icon for it). Thoughts? — James OpenG Suggestions.zip

Lava is obviously a great place to pick the brains of the Labview community elite. It is also more LVOOP centric than other labview sites and has some awsome LVOOP talent. However. Most of the LVOOP concepts discussed are very advanced for the average LabVIEW programmer and centered around a few personal projects with no real focus on deliverable code, rather frameworks and eosoteric concepts. Quite often we see potential CLDs posting their code, for comment, as a prelude to taking the exams. All of these are written in classical LabVIEW. If the LVOOP community is adamant that LVOOP is the future, then maybe some of the LVOOP gurus could post unofficial, demonstrative LVOOP implementations of the example exams (ATM, traffic lights etc). This would then give a focus on using LVOOP to achieve specific end goals, with well defined specifications and exisiting solutions for comparison - it would allow those using classical LabVIEW techniques to comparitively understand LVOOP in context with the classical solutions. Is anyone up to the challenge? To provide (unofficial, demonstration) LVOOP solutions of CLD example exams for the benefit of potential CLDs? We see many different approaches in classical LabVIEW to solving the examples. Would we see a similar plethora of innovative LVOOP solutions? Perhaps it could even be a collaborative effort to produce them and maybe , once refined they could be proffered to NI as a candidate for an official NI solution along side the classical one!

Hello everybody, I hope Daklu can add some input to this question but it may apply to LVOOP in general so here goes. Background: I am using LapDog messaging to send Objects as messages. I have classes which are children of Message.lvclass. The DeQueue message element is, I believe, an object of Message.lvclass Problem: It is not possible to direclty wire the message output from "DeQueue Message" to the input of a Message child class object's vi. Here is how I wired it with failure: This was a success: Is there a more correct way of doing this? Ultimately, I would like to have dynamic dispatch vi's that DO based on the class of message from the DeQueue vi. Thus avoiding much of the need for the case structure. Actor Framework-ish without the strict overhead.

What is the standard, or is there one, for storing configuration data that will be used to initialize I/O channels and GUI "stuff"? Example Part 1: Executable needs to read from a file some UI initialization Info: [GUI] type = touchscreen size = 800x600 InstrumentName = GS342 Language = Englusskie Example part 2: We need to know what class of I/O to use for each channel: [GS342.CH1] ID = MicroFlex ComPort = Com1 PropotionalBand1 = .35 ProportionalBand2 = .67 [GS342.CH2] ID = USB-TCAI Node = 0 InPort = 0 OutPort1 = 0 OutPort2 = 0 Slope = 3894 Offset = 49920 [And on and on...] The "ID" tells me which class to use for that channel and the rest of the stuff has to go into that classes vi set somewhere. My question is: Is there a better way to do this? Remember, users need to be able to change these values and I want them to be readable for troubleshooting. Also, is it best to have a library of all possible values and read them into a typedef cluster or should I read them as an array of Name/Val pairs and then pull them out in the class vi that needs them? I cannot just white them into each class because they change (Proportional Bands need to be tweaked, etc...) I also would like to keep the property options somewhat standardized (ID, Max, Min, Pb, Com, etc...) so when I create new I/O classes I can just unbundle the options I need. Thanks, Jeremy

I am working on a complete redesign of our instrument control software. I'll be using LVOOP and some form of messaging/queue system. The program must control 10+ different types of instruments, each having variations in I/O (pressure control, temp control, motors, different types of controllers, etc...). Most of our instruments run from a touchscreen attached to an embedded PC. A few run from a desktop and we have some that need the desktop version to control multiple instruments at the same time (using a tab control in my old program). So far I have a top-level vi that decides if this is a touchscreen, desktop, or simple test-viewer and launches the proper set of user interfaces. There are UI's for IDLE state, Test Setup, Config, Calibrate, Run Test, and so on... I have been studying discussions here from the super-megadudes on frameworks, lvoop, messaging, and how NOT to do things. After giving my best shot to AQ's AF I'm now using LapDog messaging from Daklu & it is time to ask some questions! 1. Would you recommend using a single top-level UI and then plugging in different pages (Test Setup, Idle, Run Test, etc...) via sub-panels? In the past I have found that complex sup-panels can really slow things down. However, without them I end up seeing the desktop when switching between UI's. Not a big deal but not very professional looking. 2. On the framework subject, is it better to have my I/O channels messaging a mediator who then messages the current UI or should they message the UI directly? 3. What about updating indicators? It seems that passing UI indicator references to CHx is faster than CHx sending messages to the UI (or to mediator then to UI). I need good response time: Example - I want an LED to light up on the front panel when a heating relay is turned on and off. The relay may only be on for 50ms every second. Can I really send a LED ON msg and then an LED OFF msg and expect it to work smoothly? For 2-8 channels at once? 3. Should I be re-opening the channels every time I switch UI pages or should I initialize them once and leave them running even when they are not doing anything? If the latter, what happens to the queues when the UI closes and another opens? I could pass the callee queue but what about the caller queue? 4. I have a CHx parent class with children for each I/O "type". At runtime, some stored config information would tell CHx what child to use, which channel # this is, what to label the UI controls and indicators, and, according to the type of UI (also using classes), which controls to show/hide for appropriate functionality. There was a thought of giving each I/O class a UI and then plugging them into sub-panels on the bigger UI but I thought that may be too confusing for the poor sucker that inherits my code. It already seems that using LVOOP and a messaging framework distorts what I think of as "dataflow" drastically. Any quick thoughts on this or pointers to similar discussions? Here are some UI screenshots so you can get an idea of what I am doing: I truly attempted using the Actor Framework from the bottom up but I just cannot wrap my head around implementing it on this scale. Everything is so deeply encapsulated that I cannot figure out how to actually DO anything! LapDog allows me the freedom to implement a moderate amount of LVOOP without having to wrap every aspect of the program into classes and messages. I know that's a mess of vague questions for a single post, sorry! I'm new to all this.

When working with code that uses LVOOP property nodes, debugging becomes difficult because there is no easy way to go to the accessor code that runs when the property node executes. So in order to alleviate this I created the Property Popper. Run this floater helper VI (leave running during development) When you want to get to an accessor, select the property node Click 'Get Properties' on Pop Property.vi Double click on the property you want to get accessor access to Enjoy ~,~ The Captain was here See Video Detailing this <!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="892" height="708" type="application/x-shockwave-flash" data="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/jingh264player.swf" > <param name="movie" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/jingh264player.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/FirstFrame.jpg&containerwidth=892&containerheight=708&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/2012-01-10_1033.mp4&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/" /> <iframe type="text/html" frameborder="0" scrolling="no" style="overflow:hidden;" src="http://www.screencast.com/users/NJKirchner/folders/Jing/media/e7471e93-bf0b-4801-b050-8e7c58d7a0fc/embed" height="708" width="892" ></iframe> </object> pop property.vi

Hi, Next week I am teaching a LVOOP course and my students use TestStand a lot and I expect to get questions regarding the use of LVOOP and TestStand. The things I have heard are: - TestStand does not recognize LVOOP Objects, so the developper has to flatten the Object Reference to string and then pass the string to TestStand, and viceversa, if they get the flattened Object they need to unflatten to string in LabVIEW: http://digital.ni.co...62573A9004C5A07 - Dynamic dispatch is lost Are there any other tips/tricks/myths I should be aware of? Thanks, Fab