Event Structure for Data Acquisition?

[jonvanjam]

Hello all, I'm currently programming an involved data acquisition VI and I'm trying to minimize the software delay time to maximize data acquisition speeds.  I'm using a standard state machine programming architecture with an event structure in one of the cases.  In the event structure case I am monitoring for a button click which could take the user to another screen (or close this VI) all the while continuously acquiring data.  I've set the event structure timeout to 0 and I set the timeout condition case to proceed to the case structure "Data Log."  After Every Data Log completes I direct the loop back to the event structure. 

My question is whether this is the best way to do this.  Should I be worried about the event structure not responding to a button click while it's in the Data Log case?  Should I get rid of the event structure and just do a button check after every data log (seems like this would hog more processor time)? 

Any input would be appreciated, thanks. 

[Alain_S]

It all depends on how fast you want your acquisition to run and at what time interval you want to retrieve data from the acquisition buffer.

If you're satisfied with reading the acquisition buffer every two seconds, your PC has 2 seconds to handle all other stuff, user interface, process previous buffer, write stuff to file and so on.

I wouldn't wire a "0" to the time out connector of the case structure, because that will cause the Time out case to be run continuously. Any value between 10 & 100 will do 🙂

In my opinion user interface shouldn't be locked by the data acquisition since the user will click buttons but nothing will happen.

Use the hardware buffer on the DAQ card in such way that both, user interface & acquisition, can run nicely parallel to each other.

You can of course use two loops, one for the user interface and one for the acquisition!

[jonvanjam]

Hey Alain, thanks for the quick response.

The reason I want to lock the user interface with the data acquision is because I do not want a button click to be processed in the middle of a data acquision cycle.  I need the whole cycle to finish before reacting to the button click. The setup I have right now only takes about 90-100 ms to run through the full cycle and back to the event structure.  I could add a few ms delay to the event structure, but I don't see the point if its working as is. 

Anyway, I ran some tests using a 10 million iteration for loop that adds 1 to an indicator (each iteration) to simulate the data acquision delay.  Even if I clicked a button in the middle of that for loop process, once it ended the event structure interpreted the button click. 

Tell me what you think. 

[rpursley8]

Take a look at this example and see if it is pertinent.

[jonvanjam]

Hey Randall. 

I'm not using a National Instruments Data Acquisition Device (Agilent 34980A) so unfortunately that example isn't pertinent

[F._Schubert]

You could go over to a more advanced architecture:

Expressionflow blog

Felix 

[Alain_S]

---

jonvanjam wrote:

I'm not using a National Instruments Data Acquisition Device (Agilent 34980A) so unfortunately that example isn't pertinent

---

You should have told us that in the first place

How do you communicate with the Agilent, serial or GPIB? Just curious 🙂

On the Agilent there is a buffer of what... ... 50.000 datapoints.

How many channels do you read?

How fast do you scan your channels?

Based on this data you can calculate the maximum time between two reads from the Agilent.

I bet you will come in the seconds range, isn't it?

I think you could find a status bit in the Agilent telling you the fill status of the buffer (25%, 50%, 75%, full)

You could read that bit every 50ms and when you reach 75% read the buffer.

The polling of the status bit could happen in the Time out case of the event structure.

Then wire 50 to the time out connector.

In that time you can handle user interface....... as told before.

You should not read one measurement, or scan, at a time!

The Agilent can & will do the buffering for you.

Message Edited by Alain S on 07-16-2009 07:24 AM

[jonvanjam]

Hey Alain, 

The communication is done through GPIB.

The buffer size is actually 500,000, but unfortunately there's no way for me to take advantage of this in the current implementation of the program.  What we're doing is we're using the 34980A for live data monitoring, meaning it needs to update whatever control displays are available in real time.  There are instances where we leave the software running alone for the purpose of data logging (in this case I see how other architectures would be much more advisable) but unfortunately it needs to work with live monitoring. 

I'm taking a single sample through 22 analog channels (multiplexed) + a 14-bit digital input word. 

Yeah, I've already figured out that it takes in the vicinity of 60 ms per simple sample reading of the above (not including software delay + GPIB communication delay).  So the actual figure is more in the range of 70-85 ms (updating a lot of controls and globals).  Of course I'm taking readings at the min settings to accomplish this (4 1/2 volts, auto-zero off, manual range).   

We do have a 400 ms min delay between readings, so I could add some ms to the timeout.  But the thing is I don't have an external hardware trigger for the measurements.  What i'm doing is I'm constantly polling the digital input for least significant bit change, and every change I'm doing a single scan of the analog inputs.  I want the analog reading to be as synchronous with this change as possible.  So any time I add to the timeout would add to the asynchrony. 

Anyway, I've tried running the new program with a 0 timeout and the user interface seems to function fine.  Even if I press a button while it's scanning the channels, once my state machine returns to the event case, it does actually interpret this button press (instead of timing out).  Since there is only about an 80 ms delay MAX (only if analog scanned) in the data acquisition case, it's unlikely for the user to perform more than 1 button click in this time.  At least I feel this is allocating memory much more efficiently than if I were to poll all the buttons every loop with T/F case structures. 

[jonvanjam]

That's true Felix, but I only have a couple of weeks left to finish the entire VI 

Message Edited by jonvanjam on 07-16-2009 10:50 AM