DAQmxWriteAnalog*

[Jason Newton]

I'm away from any real hw atm and writing some sw. Currently using NI's 7.4 driver with the virtual device to simulate.

Now regarding the daqmxwritefunctions... I've noticed they seem to return immediately... at least in the virtual device. So does this mean they do not block? The DAQmxReadAnalog functions seem to block... I check the written parameter immediately after the routines return and they always say the number of samples I've given. Earlier I was using some real hw (6229pci m series) and it was returning immedately as well when given 25000 samples with 4 outpus each configured for a 1000hz sample rate. Here's my code:
...
long status;
DAQmxCreateTask(taskName.c_str(), &task);
for(size_t i(0);i sstr<<"/ao"< std::string devuri(sstr.str());
status=DAQmxCreateAOVoltageChan(task,devuri.c_str(),
"",min_volt,max_volt,DAQmx_Val_Volts,NULL);
...
}
status=DAQmxCfgSampClkTiming(task,"OnboardClock",sampleRate,
DAQmx_Val_Rising,DAQmx_Val_ContSamps,samples);

long written;
long status(DAQmxWriteAnalogF64(task,samples,true,DAQmx_Val_WaitInfinitely,DAQmx_Val_GroupByChannel,currBuffer->ptr(),&written,NULL));

[e-Cash-Money]

Hello Jason,

I think the answer to your question can be found in this KnowledgeBase Article:
http://digital.ni.com/public.nsf/websearch/BD2A68EE9110FDEC86256F0A00579023?OpenDocument

Take care,
E.Lee

[Jason Newton]

how can I configure the timing to be on demand in daqmx?

[Jason Newton]

okay I need some help on this as I'm going nuts. Here's the situation: I'm doing continuous sampling at 50000hz. I have a pool of buffers(each is one seconds worth of data) in a queue that are given to another thread to be analyzed and scaled and sent to another thread to be writing out to another device. My implementation depends on the blocking of the read functions till the buffer I have given is filled so it can be properly analyzed and scaled. I can't figure out how to do this without recreating and clearing tasks to use the DAQmxWaitUntilTaskDone. However I've heard that creating the tasks is very slow and I can't afford for it to kill my timing.

I've got a similiar situation with data that needs to be written out to a card as I depend on the blocking of the write functions whilst under the same timing constraints

so uh... any advice?

[e-Cash-Money]

Hello Jason,

On demand timing simply means that it is a non-hardware timed call (no sample clock). In order to achieve this, just omit the DAQmx Timing VI. It sounds like you are acquiring data with DAQmx Read, anyalzing the data, then you want to output this data using DAQmx Write but you are worried that the the DAQmx Write will start writing before all the data has been analyzed? I'm not sure in this situation why you would have to recreate any tasks (I might be misunderstanding your application). You can always have the tasks created before hand and use data dependency to control when the tasks start.

Take care,
E.Lee

[Jason Newton]

Well I have two seperate applications. One reads a card at a samplerate of 50khz and the other writes at the same (different cards and computers). Both need to be done continously. To store the data for analyzation I just grab a buffer from a buffer pool, call the read function and pass it the buffer, then analyze & scale then record it if the analyzation flags it. For writing I have a dual buffer approach in which one is written while another is filled with new data then I flip the buffers (like in a graphics situation) to keep up constant writes. Both of these depend on blocking... I shall try on demand timing but I don't think it will be what I'm looking for... I'll reply back shortly if it doesn't work out.

[e-Cash-Money]

Hello Jason,

In terms of blocking, if you are doing a continuous non-regeneration output, you don't really have to use the DAQmxWaitUntilTaskDone function. You will just need to place the DAQmxWriteAnalog function inside of the while loop.

If you are worried about the buffers, the DAQmx driver automatically handles all the buffer allocation behind the scenes. You can create your own buffers in software, but the driver will always move those into the circular buffer that it creates for both writing and reading.

I might be misunderstanding what you mean by "blocking". If the above information doesn't help out, feel free to clarify.

Thanks,
E.Lee

[Jason Newton]

it turns out that all my trouble was caused by a desctructor I had calling clear task... 😕

Anyway, if I was to use the readBinaryI16 or so functions how would I go about scaling them?

I'm currently using

short scaleToShort(const float data){
return static_cast< short>(data/0.00030517578125);
}

float scaleFromUShort(const short data){
return static_cast(data*0.00030517578125);
}

on some 6229 cards and I get some interesting results as in its not +-10, its like 9.49 and -9.73 for the extremes

[e-Cash-Money]

Hello Jason,

Take a look at the following KB to find out more about unscaled data and how to get the proper scaling information for the device:
http://digital.ni.com/public.nsf/websearch/6BA35B863A52D77586256F94006C8EAC?OpenDocument

You can find more information on the function call you need to use by checking out the NI-DAQmx C Reference Guide. I did a search on "scaling coefficients" and was able to find the function needed to get the scaling property information.

Take care,
E.Lee