01-14-2019 10:26 AM
I have tried example vi with real 6602, it is different from simulated board - gives error -200875
"DAQmx Write is supported for counter output channels only while the task is running".
If modify as below (start, then write), 6602 generates only 1 point from the buffer. I guess needs start-stop task to cycle through the buffer - make timing software.
Second task reads pulse width to check. Works with both (6602 and 6612) boards.
01-14-2019 12:03 PM
Thanks for posting the example, and for the thorough comments up at the top of the block diagram! It's pretty clear now that a 6602 won't be sufficient for the OP's stated requirements. I posted a thread on the LabVIEW board about this possible DAQmx bug for the lack of error from a simulated 6602.
To the OP: can you give a more detailed description about the timing requirements for these "bursts" or "cycles" of pulses? Here's what I think to be true so far:
1. You need to retrigger based on some external signal you don't control. Is this correct? Where is it coming from? What does it mean in your overall system?
2. You expect trigger signals at 7 msec intervals. Is this interval extremely repeatable or can it vary? What's the shortest it can be?
3. Within each 7 msec interval, you want to create a finite "burst" or "cycle" of pulses. What are your timing specs for these pulses, as in # of pulses and frequency? What is the maximum total time spent pulsing before being done and waiting for the next 7 msec trigger?
4. You only want to react to a specific # of these trigger pulses, anywhere from 1 to 99 according to user input. Will the system keep generating trigger pulses after this that your app needs to ignore? Or is that # of pulses communicated to another device in the system to limit the # of trigger pulses that will be generated?
-Kevin P
01-03-2022 09:37 PM
Thanks