AO signal re-generation trigger problem

[Tim_W.]

Hi cc-ast

I can look in to your issue. Have you e-mailed John recently? Were you able to work anything out with him outside of the forums since June?

Tim W.

Applications Engineering

National Instruments

http://www.ni.com/support 

[cc-ast]

Hi Tim,

I sent John an email just one or two weeks ago but have not heard from him since I emailed him my codes containing the problem since June.

Thanks for your taking this issue as this is an application we will use for a production of medical instrument in near future.

Best regards,

Bill

[John_P1]

Hi Bill,

Sorry for the late response, I did see your email but was busy with other things and it slipped off of my to-do list.

What I think is happening:

The USB driver transfers data in chunks to your device (for efficiency).  If the amount of data transferred to the on-board memory of the device is not an integer multiple of periods of your waveform, then re-writing the data to the buffer would result in a phase shift of the output.

I'm still going to make the suggestion to use non-regeneration--you can write to your AO in a separate thread and it should not prevent you from running other tasks at the same time. 

Best Regards,

[John_P1]

Hi Bill,

Sorry for the late response, I did see your email but was busy with other things and it slipped off of my to-do list.

What I think is happening:

The USB driver transfers data in chunks to your device (for efficiency).  If the amount of data transferred to the on-board memory of the device is not an integer multiple of periods of your waveform, then re-writing the data to the buffer would result in a phase shift of the output.

I'm still going to make the suggestion to use non-regeneration--you can write to your AO in a separate thread and it should not prevent you from running other tasks at the same time. 

Best Regards,

[cc-ast]

Hi John,

I guess your reasoning might be right. What makes it strange is why it always has a 180 degree phase shift (5 samples out of 10 samples in a period). Is there anybody having a chance to look into the codes I sent to you in June? And if your conclusion is right, then apparently there is a bug in your update function for the regeneration mode, which I wonder if NI is going to correct it in the future release for the USB6211, since we still wish to use it in our production?

For the non-regeneration mode, I think the main problem is it will consume a lot of computer resources (when the frequency is higher or the samples per period is high, it will become more serious). And if a computer is running other background applications occationally and becomes temperally non-responsive, the AO output will be interrupted (as it is non-regen. mode).

Thanks.

Best regards,

Bill

[John_P1]

Hi Bill,

You may have mentioned this already, but have you tried with a different size buffer (e.g. 20 samples)?  Is the offset always 5 samples, or is it always 180 degrees?

Anyway, the behavior does seem buggy, but I don't believe a fix would be simple--I will file a corrective action request with the development team, but in the meantime I think using non-regeneration is the best workaround.  I wouldn't anticipate any significant problems with non-regeneration due to underflows as long as you buffer enough samples.

Best Regards,

[cc-ast]

That's a good suggestion! I wrote two periods of data so 20 samples together, and up to now I don't observe any 180 degree flip. It might be the writing is still messed up by half of the data. But since the 2nd half is identical with 1st half, therefore no difference is created in output.

Thanks.

Best regards,

Bill