Search the Community

Hi, I tried to create a template based on OOP for QMH. During development I have been confronted with infinite crashes of LabVIEW so I decided to slow down with this project and open it to the community. I finished my working example and stopped for now. So if anyone is interested to play around with the code, see attached ZIP file (LV 2020). Cu, Peter MHT.zip

I often have to create interfaces for power supplies. I often use the QMH for my overall architecture. I have created a QMH that controls multiple power supplies. It was designed in such a way that it takes a minute to add an additional power supply. Of course I am using Dynamic Dispatch to use multiple types of power supplies. It works quite well. I am trying to get better at LVOOP and plug-ins. I was thinking of creating an abstract class that contains a QMH for just one power supply. Of course I would create children for several types of power supplies. My plan with the single QMH for each power supply would be to use it as a plug-in or use a sub panel so that all the QMHs are on one UI. If anyone has any advice on the methodology please feel free to comment. Also I am new to LAVA so I hope I am not asking something that has already been solved.

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!