best design pattern for daq (data logging) from 3 devices?

[arizzi12]

What's the best design pattern for implementing a daq (data logging) system that communicates with 3 serial/usb devices?

other specs:

devices:

proprietary control system (log approx 55 different variables/items)

heise (log 1 value)

NI 9915 8 slot chassis with 6 NI 9211 4-Channel, Thermocouple Input Modules (log max of 24 channels)

- configuration/options related menu - to select/deselect a device and/or to change a comm port

- communicate with devices when the application starts

- log data every second...initiated via button on UI...creates file to log data to...logging can stop automatically or via button press

- UI related: thinking tab control. Tabs can be the following:

- propreitary digital input/digital output status

- general cycle information / home tab

- plot

left y axis:

temperature - proprietary Analog input values

temperature - NI thermocouple channels 

right y axis - pressure (heise)

x axis: time...start at 0...plot every second

New to labview...have taken courses through intermediate 2...only labview developer at my company so I just wanted to get some feedback/conversation going.

Thanks for your time and effort,

Anthony

[Ben]

Search this site for the design pattern "Producer/Consumer".

I would set-up each data collector as a Producer and use a single Consumer to gather display log the data.

The multiple Producers will allow each to run at their own rate.

have fun,

Ben

[arizzi12]

Ben, 

Thx for the suggestion.

So far, so good!

Considering I have 4 loops (3 producers and 1 consumer), would you recommend adding another loop to handle user events (for example, stop button and start logging button)? If not, another suggestion? Handle within the consumer loop?

Thx for your time and effort,

Anthony

[Ben]

Another loop for user activity sounds OK. This will let you handle pop-up dialogs (Path does not exist do you want to create it are you sure are you really sure...) without impacting the other functions.

NOW, can you offer reasons not too?

Hmmmm?

Ben

PS Alot of design is weighing options. Once I come up with an answer I try to figure why it is wrong.

[cschneider]

The number of loops you chose depends on how you like to handle your devices. If you have to record data in parallel, then you need parallel loops. If you only need to record data from your devices sequentially, then you can use only one producer loop.

Don't know if you like to expand your application to more devices. If this is planned, you would have to add a new producer loop for every device...what I have done in a program of mine is the concept found at http://expressionflow.com/2009/11/10/unlimited-parallelism-concurrency-with-recursive-dataflow/

This is a great pattern you can use with a producer/consumer loop to handle user events which allows you:

- unlimited number of devices

- parallel data acquisition

- easy expandability for new devices

- no resources needed if there aren't used all devices (in the upper concept, every loop will run even the device is not needed...)

So if you have the time and need a bit more expandability, try to take a look at this concept..

Good luck

Christian

[moonrocks]

Hi Ben,

If you use multiple p/c loops, how do you stop the application with just one stop button?

Thank you,

Van626

[DFGray]

A classic question with many answers depending on how the loops are implemented, but two basic possibilities:

1. Loops do not block (always running) - a functional global (AKA LabVIEW 2 global, action engine, shift register global) containing your stop flag which is queried at each loop iteration will work.
2. Loops block (contain queues, event structures, etc to wait for ??) - use the blocking mechanism to end the loop.  For example, if you are waiting on data from a queue, have a set of data which signals end of loop.  Better would be a command/data pair.  If you are waiting on an event, create a user event which exits the loop.

There are many variants of these two basic ideas.  For example, if using a queue, you can force kill the queue, which causes any code waiting on the queue to unblock, emit a specific error (which you can trap to exit the loop), and a default set of data.  I consider this inelegant and do not use it, but it is referenced several times in the LabVIEW help.

The LabVIEW help and these forums contain many examples. Let us know if you need more help.

[Ben]

---

@DFGray wrote:

A classic question with many answers depending on how the loops are implemented, but two basic possibilities:

1. Loops do not block (always running) - a functional global (AKA LabVIEW 2 global, action engine, shift register global) containing your stop flag which is queried at each loop iteration will work.
2. Loops block (contain queues, event structures, etc to wait for ??) - use the blocking mechanism to end the loop.  For example, if you are waiting on data from a queue, have a set of data which signals end of loop.  Better would be a command/data pair.  If you are waiting on an event, create a user event which exits the loop.

There are many variants of these two basic ideas.  For example, if using a queue, you can force kill the queue, which causes any code waiting on the queue to unblock, emit a specific error (which you can trap to exit the loop), and a default set of data.  I consider this inelegant and do not use it, but it is referenced several times in the LabVIEW help.

The LabVIEW help and these forums contain many examples. Let us know if you need more help.

---

The same thing from a less technical approach...

When we design an application we are working toward  developing a set of elements that when working together accomplish our task. In standard GUI type apps that only act base on user actions a single element (a loop ?) can do the job. For applications that have the word "while" in the spec (while this is going on this also has to happen) we often can implement multiple elements.

Deciding on how the elements interact becomes a management question where we have to decide "who does what" and when. To develop the more interesting apps I will often resort to "If I had a bunch of faithful assistants, what would each of them be doing?" and "How do they interact?"

Trust me I'm getting to the point.

So if I wanted to let all the assiatnats know that it was time for lunch I could handle it in multiple ways

"Horn blows" - This is a lot like just killing the back-ground threads. Not my first choice.

"Send E-mail" - This can be like sending command via queues.

"We all should meet for lunch" - Rondevous? (sp?)

The trick then becomes a mtter of translating the real-world example into a form we can realize in LV. This is where a good understanding of how LV's functions work so you can use them "as-is" to implement your model.

Ben

[F._Schubert]

I'd most likely use a notifier, 'cause it supports one-to-many communication. The producers will actually poll the notifier with a time-out of 0. One big advantage is, this scales up if you need more than an exit command, e.g. implement pause/resume or send changes of some aquisistion settings.

The fast implementation would be a release queue in the consumer loop. But I havn't thought about the implications on this. My main question in this situation would be, what happens if an error occures in one of the loops, will all shut down properly?

I did discuss this in this community nugget. It will take you some thinking on your own to apply this to your 4-loops design.

Felix

[moonrocks]

Thank you All,

I am going to use a global for now.  I don't think any other

part of the program will use this global.

Thank you.