vibration software design pattern

[AliasAlreadyOnFile]

Hi all,

I've been fighting with design patterns with my on and off work project to develop vibration software over the past 18 months and I've spent a lot of time on it. I haven't nailed something that I think is really that user friendly. 

Basically the main part of the software collects data from up to four channels using DAQmx, performs a number of functions on it such as channel splitting, filtering, and FFT/FRF, then it outputs the results to various plots. My current working version does the data acquisition and collects together all the settings in a producer loop and sends them via a queue to a consumer loop where all the analysis is done and graphs plotted.

It looks and feels clumsy and one of the bigger problems I've found is organising inputs from many of the numerous controls (40+) on the FP (sampling and FFT settings for example) so that they can be used in all the different parts of the software and even passed through to the save VI where they are entered as properties in TDMS files. Another issue is that my sample time is typically up to 5s so eveything is normally waiting for this. While I can't avoid the sample time, I'd like to be able to update my plots (scales, data inputs, etc) more frequently.

So, I'm here to ask you LabVIEW wizards how you would approach this task - collect data, analyse data, present data, and organise variables? I understand this is a very broad question but all I'm looking for is a little guidance on which controls/VIs etc could go in which loops (without using OOP, just yet) - a broad overview, so that I can regain control of my block diagram - it's too big and cluttered up and my efforts to use variants to declutter slowed the whole things down.

Thanks!

Phil

[Gregory]

I'm not sure how many loops you are using now, from your description it sounded like two: Acquisition and Processing. I think you could use a couple more.

It sounds like your acquisition loop is polling your controls (you said you have 40+) which doesn't need to be the case. You can keep all your controls in an event handling loop, and if one of them changes, send that update to your to your Acquisition loop. The Processing loop might be fine, but I like to decouple it from the UI updates, which helps to clean up the code as well.

[Gregory · Accepted solution]

I've cooked up an example to show you what I mean.

[AliasAlreadyOnFile]

That's right, gregory, I have two loops and the acquisition loop does poll the controls. I understand why this isn't advised but because the acquisition only generates data every few seconds (5s typically) the controls were only polled at that rate too, so not too intensive.

I had thought to use more loops. The settings you suggest should be in an event handling loop need to be read as soon as the VI runs because all the other functionality depends on them so if I wait for a change in value their data won't be available. Not sure how to get around that - I need to fire the event immediately and I don't know how to do that yet.

I like your idea to implement a UI updates loop, as long as I can get the data into it efficiently.

Four loops sounds good to me.

[AliasAlreadyOnFile]

I really like what you've done there, you don't mess around with your cooking! I was concerned about getting the control values into the acquisition and processing SubVIs, but I just remembered THIS.

Think I have everything I need to progress now so I'm going to give it a go and see where I get.

Cheers gregory!

[Gregory]

Yes you can use control references and update via property nodes, but that is usually slower then updating via the terminal. To get your initial control values you can read from a config file and then make an "init" case in the Data Acquisition Module.

If you have used Queues before, then you have already implemented the main feature of that project! All I've done is wrap the Queues up in a functional global to make the code look nicer. It uses String states and Variant Data just like the NI Queued Message Handler so that it can work any application. I've also made the "Send Message" VIs polymorphic, so you can send a single message or an array of messages.

Now, I keep a Messaging Library Template ready to go, and whenever I need a new process or instrument running in my project, I just copy and paste that template and re-name it appropriately.