Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

TTL trigger signal (CO) using USB-6001 DAQ card

The exact buffer size isn't normally an crucial piece of information for an input measurement task.  It just needs to be "big enough" that you don't overflow it between times when you read data out of it.

 

I'm wanting to help, but I'm also losing confidence that we're focused on solving the right problem.

 

You want to generate a variable frequency CO pulse train, right?  Should AO sampling be correlated to these pulses such that each counter pulse causes the AO task to generate its next sample?

 

And you say the CI task is independent, but wouldn't you want it correlated to the timing of the AO and CO tasks too?   It seems strange to me that you don't seem concerned with correlating the CI response measurement to the AO/CO stimuli.  I suspect the CI task should NOT be independent of the others, but should have its sample timing be closely sync'ed to them.

 

I know a lot of ways to share clock and trigger signals to sync up tasks, but I don't know how to solve your problem because I don't know what kind of timing relationships you're trying to establish among them.

 

You have constant rate AO, variable rate CO, and undefined CI sampling.  There aren't many systems or apps where that's gonna be the right approach.  Maybe yours happens to be one, but I haven't heard enough description to evaluate.  And without clarity on what each of the signals control or measure, and what their timing relationship needs to be, I just don't know what advice to give next.

 

I still *suspect* it to be similar to what I guessed up in msg #19, just with a variable rate CO pulse train.  But it'd help if you could give a longer, more detailed description of what each output signal *controls*, what your CI input *measures*, and whether it's important (or even useful) to correlate the measurements with the state of the output signals.  It usually is.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 21 of 25
(866 Views)

Thank you for your reply!

Be confident for difficulty!The encloser below is my program.I think you will acquire some ideals for the question which i consult.

You can ignore CO_signal which is a subprogram in Test4/5/6 as asignal source for writting function.

when i run the program ,the program will generate a error that overflow in a random time.

 

Error in the image below says :“The onboard device memory has underflowed. Due to system/bus bandwidth limitations, the speed at which the driver writes data to the device cannot keep up with the data output speed of the device.
Reduce the sampling rate. If the data transfer method is interrupted, please try to use DMA or USB block. It can also reduce the number of programs currently running simultaneously in the computer.”

Yuzn_0-1599707369106.png

Thank you!

Looking forward to your answer!

Yuzn

0 Kudos
Message 22 of 25
(862 Views)

The code you posted doesn't help me to know anything about your system or what you *intend* for the code to do.

 

I can only guess that you get that "underflow" error from the CO task and that you are probably trying to generate very high frequency pulses.  Apparently, the DAQmx driver can't deliver your task data across the USB bus to your device as fast as the device can generate its entire FIFO full of pulse parameters.  I don't think that's a problem you can fix in your application code.  

 

My suspicion is that you'd need a PCIe desktop board to make this work.  DMA data transfer over the PCIe bus has much better performance than USB data transfers.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 23 of 25
(851 Views)
Thank you for your reply! Based on your suggestion,I can not understand what i can do.Should I change my code?or use new a device ? My device is Usb-6363(with BNC). i do not know how to use PCI to deliver data(should i change my hardware?) can you give me some tutorians about the theme? or how to modify my code? could you give me some specific advices?or you can modify my code straightly then send to me. Thank you very much! Yuzn
0 Kudos
Message 24 of 25
(847 Views)

Again, I can only guess because you haven't fully described your system or the intentions of your code.

 

This sounds to me like a problem where the driver is unable to deliver data across USB as frequently as your tasks need.  If that's correct, I don't think you can fix things with changes to application code alone.  I believe you'd need to move to a system based on a desktop PC with an X-series PCIe board and an appropriate cable and terminal block.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 25 of 25
(840 Views)