08-04-2023 11:33 AM
Solved! Go to Solution.
08-04-2023 08:17 PM
You're using a pretty old device that has some limitations. Specifically, finite pulse trains will occupy *both* counters -- one is used to "gate" the other so that it only outputs the requested # of pulses.
A continuous pulse train would only occupy one counter and you could then use the other counter for edge counting. But I don't know your overall app to know whether switching to continuous pulses would be a viable solution.
-Kevin P
08-14-2023 03:14 PM
Thank you Kevin! I realized it must be a problem with the device, but didn't understand why. I ended up using another M-series board with ctr0 output tied to the PFI0 on this board, and the code works perfectly. Your explanation helps to understand why it wasn't working earlier. Do the newer M-series board not have this limitation ? How does one find that out without getting it and testing it the way I did?
08-14-2023 03:37 PM
M-series may be newer but are still fairly old, introduced nearly 20 years ago, and still with this same limitation.
An X-series board would be a *much* better option. Not only is this restriction removed, but you you get 4 counters instead of 2 as well!
Note however that there are sometimes "sneaky" ways to make older hardware accomplish your end goal. Instead of trying to make the clock counter generate a finite pulse train, you can let it generate continuously. Then you can configure only the edge-counting counter as a finite task. You'll still only capture the specified finite # of count values -- the edge-counting task will just stop paying attention to the continuous clock once it fills its buffer.
This is a method that should work with just the 2 counters on your 6733 without needing to occupy another device.
-Kevin P