Over my head. Need help on designing a framework.

[Mojito]

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!

 

 

[ShaunR]

Many of us aren't fans of QMH. I'm somewhat ambivalent about them but a couple of points I will make from your description.

 

1. Future proofing is marketing speak.

Adding complexity for something that is not required and just a guess as to future requirements is unproductive, will bite you and adds nothing except complexity. Design your system for the requirements now and iteratively innovate when necessary to encompass new requirements. Experienced engineers will recognise patterns in solutions and code in a way that they know will be easy to modify in the future but the key point there is easy to modify, not seamlessly integrate.

 

2.If you are going to have multiple consumers of your messages/data then queue based message handling is probably the wrong solution.

You will get tied in knots re-transmitting messages/data since queues are a many to one topology and you are trying to create a one to many or many to many architecture. An event based architecture is much more suited to this but you will find very little in the way of formal examples or templates outside of user interfaces.

 

3. You can have more than one architecture within your program!

I see this all the time with even knowledgeable engineers. They choose a magic bullet framework, shoehorn all their code into it and it becomes a mess that only the developer can ever understand and is riddled with bugs. Modular code can have frameworks or architectures at the module or abstraction level and you can mix and match dependant on module requirements (QMH, State Machines, Producer Consumer etc). You can then choose one or more architectures to sew all the modules together to form a cohesive program with defined areas of responsibility that can be debugged in isolation. When new to designing software systems I would suggest the following axiom when using LabVIEW.

 

Design the system top down (from the UI usually) but create the modules/code bottom up.

A natural partitioning of code reuse arises from bottom up that is different from the partitioning of responsibilities that top down produces. It is reconciliation of these two partitioning views that yields robust and modular code.

 

So. Enough sermonising Here are some insightful write-ups you may find useful

NI QMH Template

QMH's Hidden Secret

Some Context

 

[drjdpowell]

If I were looking at improving an old program I would first look for and refactor any natural ‘objects’, bits of data and actions on that data.  You, for example, might have a ‘Camera’ object for taking images, or a “Sample Positioner’ object.   Only after this would I ask if some of these objects should exist in separate loops so they can do things in parallel.  

 

Re the various QMH designs, I gave a talk recently about some of the issues (main point: don’t use the NI QMH template; use something like the JKI template).