Search the Community

Manufacturing a satellite or a simple pen require to test the quality of the product before delivery to the customer. LabVIEW is widely used for that purpose. Since 20 years of LabVIEW development I saw numerous test framework. I was wondering if people where interested to work in a collective and open source test framework. Per example the following feature can be included: HAL (hardware abstraction layer) Database to record test results with the data viewer (PostgreSQL) single/asynchronous/batch/debug mode multi-language support Image analysis (open CV) + bar code reader User access level Remote monitoring Jig identification to prevent user error (testing the wrong product with the wrong jig/test sequence) HTML/xml/txt report and so on.... Benoit

Hi LAVA friends, We are pleased to announce that the Delacor Queued Message Handler (DQMH) is now available via the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286 You can read about the thought process behind DQMH at our blog post: Ours is not better than yours (or YAF=Yet Another Framework) at WalkingTheWires.com The DQMH is based on the NI QMH Project Template. The DQMH expands on the NI QMH by providing safe, event-based message handling and scripting tools to encourage same style between different developers in the same project and improve efficiency. The DQMH is ideal for applications where multiple modules must run in parallel, possibly at different rates, while communicating with each other. The DQMH can also be used for applications that have a single module, where the developer would benefit from having a Tester with the capability of eavesdropping on the different DQMH events and messages. The DQMH integrates with TestStand since all development and troubleshooting can take place under LabVIEW, while calling the public API VIs as individual steps in the TestStand sequence. The tester can eavesdrop during the execution of the TestStand sequence. This is specially useful when the LabVIEW code is written during the research and development or prototyping phase, because the same code can be called by TestStand in production or manufacturing sequences without any changes. The DQMH uses LVOOP for some internal functions, but developers need not be familiar with LVOOP to use or understand this architecture. Try it out and let's us know what you think. Fab and the Delacor team.

Hi all, I've been maintaining and improving a LabVIEW project which controls and automates a prototype microscope array for 2 years. I'm an engineering apprentice so I don't have that much experience with LabVIEW. The current framework of the project is a simple "Producer/Consumer" which has served well but is no longer future proof and scalable. I want to revamp the program which is quite big and complex. And I need help since this will be the first time of actually starting a real project from the ground up. The most modular and scalable framework I found was the QMH (Queued Message Handler). It's similar to the basic P/C loop and has the possibility to have multiple parallel consumer loops. But I have no experience on starting from 0. If any you have docs or give advice on starting the project would be appreciated. Especially something on codding with a QMH structure would be helpful. Cheers from France!

Hi all, My concern is about object based framework. I'd like to talk about a "sensitive" subject, which divides people around me. I'm sure there are a plenty of objects aficionados here. A few years ago, LabVIEW give us the first object based template : the Actor Framework, which is certainly powerfull ...but just UNREADABLE !!!! When I conduct Core3 training, I'm tempted to show what could be an object based framework in LabVIEW, then I remember how the actor framework looks, then I decide to make my trainies continue to use LabVIEW, and finally I don't show the actor framework. When will NI provide a SIMPLE object based framework in the TEMPLATES ? Something like the command patern exposed here by Elijal Kerry : https://ekerry.wordpress.com/2012/01/16/oriented-design-patterns-for-labview-that-can-make-your-life-easier/ or in a the test executive example of the PTP sequencer : http://www.ptpartners.co.uk/ptp-sequencer/ I still use the "old" QSM (please Daklu, don't bite me), for sure it is not an ideal solution... I love objects, I used them a lot in my code, but not currently for my high level code. Any links or suggestions ? Thanks, Sebastien CLA

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

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.