Fast Writing using DAQmx on USB 6212 - LabVIEW 2024

[AjperezGb]

Hello, i need to write single values through an AO of my USB 6212 but seems that on-demand writing is taking too long (around 30-50ms), time that i guess it takes to send the order from the computer to the AO using the serial.

I have been thinking if using a buffer (as waveform data is writen) to fasten the process. The thing is that it isnt a modulated waveform (just 1 value) and timmings are not clear (it needs to be syncronized with other parts of the program). Have been looking to the writting examples but couldnt think of a way to implement what i want to do.

So to summarize: i want to use a writing buffer with x values preloaded and i want to write this values x(0), x(1), etc at any given time by an external variable. If this is possible, would it help to reduce the delays?. If not, is there any other configuration that may help?

Not attaching any VIs cause its not going to be helpful.

Thank you for your time.

Greetings,

Alejandro Pérez

[Kevin_Price]

1. Don't assume that attaching vi's won't be helpful.  Sometimes you don't know what you don't know and someone else can see something you don't recognize.

2. Using a buffered task is liable to partly help and partly hurt, if I understand your needs correctly.  It will *help* to allow you to update output values at a significantly higher sample rate.  But it will likely *hurt* by adding more latency between the time you write to the task and the time those values become physical real-world signals.

    It's going to be important for you to have a clear understanding how to prioritize the tradeoff between raw bandwidth needs and latency needs.

Given your description, I *think* that minimal latency is your bigger concern.  USB devices are not ideal for such use cases, though 30-50 msec strikes me as being unusually high.

Code would have helped, but I have to wonder if you're doing more with each on-demand write than merely writing.  Specifically, are you re-creating & re-starting the task each time you want to write a new value on demand?

-Kevin P

P.S.  If posting code, please first back-save to a somewhat older LV version that more of us can open.  My own preference is to go back to LV 2020...

[AjperezGb]

Hello Kevin,

Thanks for the information. Attached should be the current configuration of the software (on demand writting) with a photo of the position of the writting in the software (Inside "State handler" state). Also, configuration of the AO ports can be seen in "Initialization" state (Dev2/ao0, Dev2/ao3).

Also, i attached another vi (ConceptToWriteFaster.vi), where i try to show what i want to do: fill a writing buffer and write values one by one (with a trigger or event structure) at any given dt. I would like to know if this is possible or if there is any other way to do the writting faster than in the current configuration (without using timming configs, as all is asyncronous). 

If any more information is needed please let me know.

Thank you for your time.

Greetings,

Alejandro Pérez

[AjperezGb]

I cant edit last answer, here is a better "ConceptToWriteFaster.vi". Sry for the inconvenience. 

[Kevin_Price · Accepted solution]

My biggest suspicion about the slowness of your "state handler" state is that you start and stop your DO task every iteration.  You shouldn't need to do that.  Don't stop it after "initialization", then don't start or stop it in your "state handler".

But it also looks like after each "state handler" iteration, you jump over to "measure" before returning again to "state handler".  You have a fair amount of stuff going on in the "measure" case, including a number of express vi's, VISA query/response with an instrument, and a DAQ Assistant to generate a sync pulse.

    I suspect *these* things to be the bigger culprits for consuming time and limiting your AO update rate.

I don't think your "ConceptToWriteFaster.vi" is the right avenue to pursue.  I haven't tried writing a buffer of data to an on-demand task in many many years because it was disallowed as an error back then.  While it's *possible* that DAQmx has changed in ways that accommodate the possibility, I wouldn't expect that a tight polling loop on the write position would be needed to make use of it.

I'd highly recommend you write up some quick throw-away code with an on-demand AO task where you write a new value every iteration.  Check the loop timing when that's the *ONLY* thing you're doing because I'm suspecting that servicing the AO task isn't a very big part of your 40 msec.

-Kevin P

[AjperezGb]

Hello Kevin,

Thx for the upgrade!, it has come down to a 25 ms if i remove the start and stop tasks in "state handler". 

Also, i have not been clear about this waiting time: All this post is due to variable "Stabilization time (s)": needs to be smaller (it is not the time it takes to write a value, probably all the program is phase shifted so it is just a relative time). This DELAY is needed so that when reaching "measure" state, the current on the laser has been written and reached (laser response has alredy been measured and is really really high, so the problem is on the software). 

So to summarize: i dont care much about AO writting rate, i just want to reduce the Delay i have to set in between "state handler" and "measure".

If any other thing you happen to notice that could upgrade the software please let me know. Other configurations that might come to your mind as a good solution would be very welcome!

Thank you for your time, i really a appreciate it.

Greetings,

Alejandro Pérez

[Kevin_Price]

I can't re-examine code now so can you describe in words what your system is all about?  How and why do your AI measurements affect the AO voltages you need to generate?  What are you trying to learn from this system?  Are you mostly *observing* or are you mostly *controlling*?

My inclination would be to split the measurements and the AO updates into independent loops, using a QMH-like structure to communicate between them.  I would very likely also loop back the AO signals into AI channels so they can be captured along with your other AI data.

    I don't know the exact needs of your app, but one possible approach is that the AI loop just keeps reading and reporting data, making it available for other parts of the app that need it.  The AO loop doesn't necessarily need to respond to every single chunk of data being reported by AI.  It could do an update, wait for some delay time, before checking on the latest AI data to use for calculating the next AO update.

    Other approaches may be more suitable depending on the nature of your system.  The main point is that the step of decoupling the inputs and outputs from one another opens up flexibility that you might be able to put to good use.

-Kevin P

[AjperezGb]

Well here is the description of the system:

The program is used to controll 2 lasers and read its power at different currents at a power meter (instrument). There a lot of more things going on but mainly this is the objective. The way this program works is: from a .txt gets an array of currents and an array of integration times. Then, it writes the first value of current to the laser (AO signal), wait the delay time, go to measure and read "y" values from the power meter with "y" being proportional to the integration time. This process is the important one: it is needed that the measurement is done with the last current written.

When im done measuring, the program goes back to "state handler" and loads the new value of current, writes it on the AO port, waits the delay time and goes to "measure". This is repeated till the end of the array.

It is interesting how we noticed that measurements of the power meter didnt correspond to the currents written: If you take a look at SubVI "FetchPowerSensor", iterations of the "for" are 1 for an integration time of 20ms. With this configuration, measurement is taken once and if a step of current is introduced (for example from 50 to 90 mA), you see an output (image attached shows power meter output) of 1 element array, which mean its itselft -> "averaged amplitude (mW)" vs time looks like a perfect sqare wave rising edge. On the other hand, if an integration time of 200 ms is used, there will be an output array of 10 elements (as the "for" that reads the power meter is executed 10 times). This time, if the same step of current is introduced (50 to 90mA), you wont see a perfect rising edge at the output (there is a value in between LOW and HIGH). Why?: The Writting is taking effect in between executions of the for, leading to an output array of, for example {LOW, LOW, HIGH, HIGH, HIGH... , HIGH}, which mean its in between the LOW and HIGH value. Image attached shows what i mean.  

Thus, writting is happening in between readings if there are a lot of iterations. And if iterations are = 1, then we are taking a measurement that does not correspond to the current setpoint written by the AO port.

Summarize: Its all about the delay!, if we are fast enough writting, "Stabilization time (s)" variable could be set to 0 and SNR will improve drastically (the objevtive of the software is reading gas concentrations). And with this delay i dont mean "writting rate", i mean the time it takes from when the code is executed until the laser current actually changes.

I hope this text helped in any way, but i dont think there is a solution to this problem the way i want it. We should developed a timed and sycronize reading and writting, which will change the code a lot. 

Anyway, as always, thanks for your time Kevin!

[AjperezGb]

Forgot attached images

[Kevin_Price]

Thanks for the description.  It helps, though I'm sure I still have only a partial fuzzy understanding of your system and app.

Let me urge you to loop back your AO signals to a a couple additional AI channels.  This is to help you determine whether the AO itself is slow to update or whether something about your *system* is slow to react to the AO update and produce a new power reading.  Among other things, I know nothing about your power measurement instrument.  But it sounds like you're suggesting that a change to its integration time setting somehow affects the speed at which the AO update occurs, even though instrument communication happens *after* performing the AO update.

I may be misunderstanding, well, several things.  But the diagnosis I *think* you've made doesn't make a lot of sense to me.

-Kevin P