Digital I/O
How to use PCI 6534 to perform pulsed pattern generation
Solved!
I would recommend as you have defining the sample mode to be finite. Define the trigger parameters. Commit the settings into hardware by using the DAQmxTaskControl DAQmx_Val_Task_commit. This allows for very efficient restarts. Then have the write, start, and stop commands within a loop. Each write within a case structure that defines which values to write to the buffer.
You can also reference the following KnowledgeBase article 2MOESVN5 for examples using the double buffer but would require some modification to apply the third set of data.
You can also reference the following KnowledgeBase article 2MOESVN5 for examples using the double buffer but would require some modification to apply the third set of data.
Your DAQ process looks good,
Keep in mind, the data transfer process for output tasks. The data is created in the application buffer and transferred into the PC buffer then transferred into the onboard memory either by DMA or interrupt. PC buffer to on board memory is pretty consistent and you can reference KnowledgeBase 3F4BMNY7 on appropriate rates. What is difficult to gauge is the transfer time between the application buffer to the pc buffer. Unfortunately, the current method of running this application heavily relies on software operations. These software operations (starting & stopping task) are inherently non-deterministic due to the Windows OS. Your question (1) can be addressed by the above KB but the time that the data is written in the application is not deterministic. Question (2), should be neglible in this application since it’s within the nS range and most of the delay will be found in starting and stopping the task, which could reach mS.
There are ways around this, if you have the following hardware.
1) An additional device with counters. Upload all samples into the buffer. Import any counter, and use that as the sample clock to trigger the sample sets. Reference the Retriggerable Pulse Train Generation example for your sample clock.
2) X Series Devices support retriggerable DO. Similarly to the above suggestion you can upload all the samples into memory and trigger each sample set. The device uses the DO Sample Clock signal to update the output with the next sample from the buffer. X Series also support retransmit mode, which implies that once all the samples have been sent it restarts.
3) HSDIO devices have scripting ability making this task much simpler. A script is a series of instructions that indicates how waveforms saved in the onboard memory should be sent. The script can specify the order in which the waveforms are generated, the number of times they are generated, and the triggers and markers associated with the generation.
Keep in mind, the data transfer process for output tasks. The data is created in the application buffer and transferred into the PC buffer then transferred into the onboard memory either by DMA or interrupt. PC buffer to on board memory is pretty consistent and you can reference KnowledgeBase 3F4BMNY7 on appropriate rates. What is difficult to gauge is the transfer time between the application buffer to the pc buffer. Unfortunately, the current method of running this application heavily relies on software operations. These software operations (starting & stopping task) are inherently non-deterministic due to the Windows OS. Your question (1) can be addressed by the above KB but the time that the data is written in the application is not deterministic. Question (2), should be neglible in this application since it’s within the nS range and most of the delay will be found in starting and stopping the task, which could reach mS.
There are ways around this, if you have the following hardware.
1) An additional device with counters. Upload all samples into the buffer. Import any counter, and use that as the sample clock to trigger the sample sets. Reference the Retriggerable Pulse Train Generation example for your sample clock.
2) X Series Devices support retriggerable DO. Similarly to the above suggestion you can upload all the samples into memory and trigger each sample set. The device uses the DO Sample Clock signal to update the output with the next sample from the buffer. X Series also support retransmit mode, which implies that once all the samples have been sent it restarts.
3) HSDIO devices have scripting ability making this task much simpler. A script is a series of instructions that indicates how waveforms saved in the onboard memory should be sent. The script can specify the order in which the waveforms are generated, the number of times they are generated, and the triggers and markers associated with the generation.
Yes, this emulates my first suggestion that suggested using an external counter as a retiggerable sample clock. If you can control the sample block you can import all the data into the buffer.
