continous output pattern with DAQmx not finishing output

[Gabi1]

Hello

using a DIO-32HS (NI 6533), i send to output a continuous output pattern usin LV8.2 and DAQmx, while monitoring the buffer space and nb of generated channels.

in general, up to a frequency of 800KHz, the data output nicely up to the last 16 or 17 words (32bit long) which seems not to be executed and shows for example 10000 channels written to memory, and only 9983 channels actually generated. the output isnt updated anymore at this point.

This is a problem as i need to know all my data has passed trough.

Moreover, if one trys to run the system at any frequency above 800KHz, (card support up to 2MHz, which would be very usefull for my application), the output status becomes erratic, as sometimes the memory is suddenly reseting itself (free memory appears to be zero), leading to a completely unfinished business. for example 10000channels are sent to memory, and just 5435 are executed, at which point the free memory suddenly goes to zero.

To note that i do not observe any error, and that i allocate a lot of memory in advance. i also looked at any other configuration i had in mind to see the occurence of this problem. happens always.

Thanks for any suggestion of the problem.

[JoBa]

Hello Gabi1,

I can't really reproduce that behaviour without your code.

Could you please have a look at the example VI "Cont Write Dig Chan-Burst", which you can find in the NI Example finder?

If I understood your post correctly, it should do exactly what you want; maybe you can modify your code to get better results.

Please write again if you have any further quesions.

Regards,
Johannes

[Gabi1]

Hello Johannes,

Thanks for your answer. attached is a test code for my application.

the main difference with the usual examples is the fact that i allocate memory in advance, and i do not use the wait function at end of output generation to buffer (the Vi always return an error of timout), rather i observe myself that the buffer is emptying and that the memory is freed.

Note1: if you run this many times, you might want to add a request for memory deallocation at end of VI in order to avoid usage of too many Windows ressources.

note 2: for this test the data is regenerated, but it is not the case in my application.

For very short applications (typically shorter than few 100ms), i can run the application at 2MHz. but it is not always relyable, at any frequency above 850KHz. the Vi doesnt return an error, rather i observe the actually generated samples is not equal to the nb of samples written to buffer, and the output suddenly stops, while free memory goes to Zero.

Moreover, even at frequency below 800KHz, there are typically the last 16 samples not generated, altough written to memory. (this is actually the reason the Wait VI return a timout error).

I hope  with this info you will be able to pin-point my problem.

Best regards,

Gabriel

[Gabi1]

Hello again Johannes,

following your proposition i looked at the example "Cont Write Dig Chan-Burst". i could not run it as is, and would have needed several changes in order to observe operation, however one main change that striked me was that the timing option is set to "burst (input clock)" instead of "sample clock".

Trying that on my vi seems to allow operation at the requested frequency of 2MHz without problem. i am confused of it tough, as i would have expected "sample clock" to give same results. What is the difference?

is the "burst (input clock)" different in any way, or maybe the frequency one set is not followed exactly by the card?

Best regards

Gabriel

Message Edited by Gabi1 on 04-20-2007 05:03 AM

[JoBa]

Hello Gabriel,

burst mode uses a lot less ressources and therefore can sustain a high output rate over long periods of time.

Please refer to the "Sample Timing Types" section in the LabView Help for a more detailed description of the involved protocols.

Regards,
Johannes

[Gabi1]

Hello Johannes,

Thanks for your answer. however i tought burst mode would be incompatible with continuous operation, and at least with the traditional DAQ this was how it was working (i am new to DAQmx). from the labview help i am still a little confused, and not completely sure that the 2MHz in this mode is consistent with the normal onboard timer.

in other words, can i be sure my data output will be transferred at the exact 2MHz the onboard clock deliver, using this handshake burst mode? (it is critical that the output timing is well defined, i.e. one generated output to the next one). if yes, this solves my problem.

Thanks for your help

Gabriel

[JoBa]

Hello Gabriel,

DAQmx has increased capabilities in some areas compared to Traditional NI-DAQ.

2 MHz is the maximum specified rate for the 6533, so your data should indeed be delivered with exactly that rate.

Regards,
Johannes

[Gabi1]

My system now works like a charm!

thanks a lot.

one more question tough: i want to add a trigger capability. can i configure it in advance using the DAQmx trigger, and then only when i start the task it waits for it? or as soon as i configure the trigger the cards wait for it to begin transfer?

[JoBa]

Hi Gabriel,

if you configure the trigger as part of your data acquisition task, it is only armed when the "Start Task" VI is executed.

Regards,
Johannes

[Gabi1]

thank you so much for all your help.