I'm curious about the root cause on this one. In my experience, I never see that error when devices generate their own clocks internally. DAQmx knows various devices' clock rate specs, and will either error out or coerce attempts to configure a task using a clock rate the device can't support.
When a task uses an external clock, DAQmx *can't* know the rate ahead of time and is vulnerable to this error. Also, clock signals physically routed in from the real world will typically be more prone to finicky connections, impedance mismatch ringing, glitches, other noise, etc.
Your observations so far suggest that your hardware-sounding error was fixed by a software change to the simple, well-structured code from GerdW. I would not expect that particular error to be fixable via software unless it was about a change from an external to an internal clock.
The only thing I see in your code that I can even *imagine* might have an effect is that you also have a DO task that might be toggling relays. I don't know what's on the load side of those relays, but perhaps the switching induces some anomaly into your setup that could in turn affect the internal clock signal? I'm out of depth on this level of electronics, but *have* seen odd anomolies from things like arc welders in a nearby shop, motors switching on and off, and other things.
Anyway, you might try a comparison using your code, but with all the DO removed.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
