What is the best achitechture for DAQ?

[foolooo]

Hi all,

I'm using lv 8.5 winXP, and I'm trying to control a custom-made camera by DAQ card. Attached is a state of the top level state machine, which is the core of my program. On the top part there is DAQ funciton, containing synchronized AI and DO tasks. In the middle there is logging function, and the bottom part is displaying function (convert the raw data to visible images). And I used a queue and a notifier totransfer the data. I think that's the typical achitechture for DAQ.But as the program grows, I found it is hard to handle. I wanna develop an achitechture like queued state machine for this program. And I may need to add some data analysis function and return the result to DAQ as feedback (close-loop control).

Is it a good idea to put DAQ in a state machine? Did some one do that or could you give me any example?

At this moment, all I can do is to split the whole program into 'states'. and I want to create subvi for each state (to make code clearer). I found it weird putting queue and while loop in a subvi. Any suggestion?

Best wishes,

Bo

[F._Schubert]

You could put bundle all DAQ tasks in a cluster. Then you could make a subVi of your DAQ initialization.

Another thing regarding your usage of queues and notifiers. It is common usage to destroy the queue when the producer loop is done (you can wait until the queue is empty if you don't want to loose data). Then all you need to do in the consumer loops is to check for the error (code 1122 and 1).

The looping loop can be easily placed inside a subVi as it is. 

Felix 

[foolooo]

Hi Felix,

Thank you for your reply. But I think in that way I only package the program into subVIs, and the achitechture is still sequence. And for the releasing queue issue, I'll try that. Thank you.

Regards,

Bo

[foolooo]

Hi Felix,

And for your 'release queue after producer loop' suggestion, the consumer loop always run 1 more loop than I expect to detect a error cluste, then I'll get a '0' context in my files in the last loop. And I believe 1 more time consumption may cause some unexpected affects. Now I seperated the 'obtain queue' node into two loops,so that I can make either a seperate subVI. And the question is still, can I have a better achitechture for DAQ/Log/analysis-and-feedback program?

Thank you.

Best wishes,

Bo

[ThomasC]

Hi,

I'm struggling here a little to identify the specific problem you are seeing.  It is easy to follow and makes good use of the producer consumer architecture.  I see no problem with running that as a state in a larger piece of code.  Does it function as you expect it too?

Regards,

Thomas Clark

[F._Schubert]

Hi Bo,

In the consumer loops, you need to place a case structure after the dequeue function that checks for the error.

For the question of architecture in general, every thing is pefect. producer/consumer is the right choice and an implementation with two consumers shows some advanced skills. So go on to more difficult tasks...

If you want a review of the code:
I'd put more attention to the error wires. So all VIs/functions with error in/out should be connected. It becomes a bit of a puzzel when you go to handling the parallel wires. If one process is in an error state, it outputs a (default) value that might raise an error in another process. So you should make sure that the primary error is shown, not the secondary.
More important: place a general error handler at the end of the error lines, as if you make an executable from the code, the 'automatic error handling' functionality will be gone.

Felix

[Baji]

A queue based producer consumer was a cool architecture. Find my example programme.

[Ben]

Most of the previous replies are focus on the low level, so here is a top level reply.

MVAS - is the top level app and loads the other components. When acq time comes it loads and starts the acq process (Collect).

Collect - Starts up the logging process (Logger) then the acq code (Collector) then sits back and keep the GUI updated with data coming from the "Collector".

Logger - Start by creating a queue through which it will recieve updates and then watches for updates and commands to start/stop logging.

Collector - Acepts queue refs from "Collect" to tell it who should be updated and respondse to commands.

I prefer to send commnads to explicitly tell loops to shut down (rather use an error to signal this) and I let the reciever of queue data to kiil the queue.

I hope this gives you another way of looking at your code.

have fun!

Ben

[foolooo]

Hi Thomas,

Thank you for your reply. At this moment my achitecture is just sequence, and I'm afraid it is not scalable when I want to add some other functions(loops). I also want to know when people do DAQ task, what achitecture do they prefer.

Regards,

Bo

[foolooo]

Hi Felix,

Thank you for your suggestion. The error handling part is very helpful. And I'll add that, although I'm not sure about 'automatic error handling' function yet. I'll learn about it. Thank you again.

Best wishes,

Bo