Continuous acquisition and device configuration

[GollumGTH]

So like most when I need to do a continuous acquisition I put it in a while loop and just feed the data to a queue (typical producer/consumer)

It often comes up that I need to occasionally configure the device I'm acquiring from.  In the past I have put this somewhere else in my code and used semaphores to prevent more than one thing from accessing the device at once.

It has occurred to me that by using a queue driven loop for my acquisition I can do both of these tasks in one place.  To be clear I would use a configure command to configure the device and an acquire command to acquire data (inside the acquire data case I would simply enqueue another acquire command to make it a continuous acquisition)

This seems to have the added benefit that I can put an assortment of commands into the setup to handle all my communication with this piece of hardware and since only one command will be executed at a time there is no need for any semaphores to control access to the device.

Here is my question(s):  I have never seen a continuous acquisition program setup this way, is there an obvious reason why not?  Would this require too much overhead?  Is there a better way of doing this?

Thanks.

[JÞB]

I see no obvious reason not to do it the way you describe it should work fine.  However, if you want to prevent multiple accessors to the task consider using an Action Engine  where you place the task on a USR.  A brief example is below.  Since the same vi handles all task operations the Acquisition loop PAUSES when the engine is called with a re-configure method since the vi is not re-enterant, and as soon as the blocking is removed the reads automatically re-start as soon as the task has all the new properties applied.  The callers don't need to worry about synchronization since the AE can only let 1 instance run at any given time.  If you mess up the order of callers (say try to read a task that isn't initialized) the error will be easy to trace down and fix.

[GollumGTH]

Jeff,

I'm actually trying to implement the corporate model that you suggest here:

http://forums.ni.com/t5/LabVIEW/Community-Nugget-Series-Application-Development-Installment-1/td-p/1...

for a continuous acquisition system.  This was the best way I could think of to allow the Test Resources loop to continuously acquire data while still accepting commands (configure, stop, etc.) from the Operations loop. Thanks for the help.

[Brian_P]

GollumGTH,

I believe that you are definitly on the right track.  You will need the Test Resources loop aquistion to be able to stop or pause in order to accept commands from the Operations loop. However you don't want to clear the task because the commands will not be accepted. In terms of a programming structure, a state machine model will be the most advantageous in this application. I hope this helps in your application.

Regards,

Brian P.

[JÞB]

---

@GollumGTH wrote:

Jeff,

I'm actually trying to implement the corporate model that you suggest here:

http://forums.ni.com/t5/LabVIEW/Community-Nugget-Series-Application-Development-Installment-1/td-p/1...

for a continuous acquisition system.  This was the best way I could think of to allow the Test Resources loop to continuously acquire data while still accepting commands (configure, stop, etc.) from the Operations loop. Thanks for the help.

---

Yes, that corporate model COULD be executed as a continuous data acq system some points to consider-

• the GUI data table and data table "Module" can easilly be replaced with a chart or graph
• Update the "status " indicator and module with items like "Running-OK/Warn/Alarm value"
• Breakpts array becomes scalar
• some design changes from my use case are needed in the executive

Hmmmm.....

    I'm a bit behind in the nugget series due to Propriatary IP issuses but intend to continue yet.....

Check your policies. get back to me  via PM I would consider a co-authorship of the nugget series if you wish to persue a Night / Weekend collaboration with the nuggget series in mind.

[GollumGTH]

For the most part I'm writing from scratch, just using the idea basically, i.e. the block diagram you posted with a few minor tweaks.  Unfortunately due to IP concerns I probably won't be able to post the code (not that all that much of it is written yet).