I re-read the thread and tried to dig into the code a little more. I still don't think I understand what you *want* out of this. Here's what it looks like to me. In one scenario you take single readings from an external instrument and see a step change in a response. In another scenario you average 10 readings from that instrument across the step change, don't like that the resulting *average* doesn't also show a step change, and are hoping to fix things by writing AO output faster.
It isn't adding up for me. I'm beginning to suspect that you're struggling with a time delay that's part of your system behavior. You update an AO value, it takes time for that to become a stable laser current and then it takes more time for the gas to respond to the laser and then it takes even more time for your power measuring instrument to capture the end result. Then when you average across multiple readings, sometimes a step change occurs in the midst of those readings and your average doesn't match either the "before" or the "after" power level -- it's something in between.
Your DAQmx tasks aren't going to change that. You would instead need to come up with a method of data collection and analysis that can account for and compensate for those delays. That probably means keeping *every* individual instrument reading and then doing post-processing to identify and pay attention to the portions of the response you care about.
A whole other thing you might consider is to set up AO and DO as buffered tasks that "borrow" the AI sample clock for their own sample timing. There'd be some data processing work to do to take the data from your "Get Data" file and make it follow the output timing you want, but it should be possible in principle. If the data segments ("State L1 Data", "State L2 Data", ...) represent discrete stages of operation, you can probably make AO and DO be finite sampling tasks that contain one state worth of data at a time.
But I don't really think this is the main thing to focus on first. It seems like your system response delays, instrument interactions, and instrument data retention probably are. At least that's how it looks from here, albeit hazily.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
