Two identical test stations - One returns error -200560 (DAQmx wait until done), the other doesn't

[JayWW]

I created a simple VI that verifies a 5VDC signal is functional on two different timer channels at the same time. (Using PXI-6602) I've got two test stations with identical hardware. One runs the VI without error and the other returns error -200560 at the DAQmx Wait Until Done VI. (Please see attached) I've verified with NIMAX that the hardware is capable of producing the 5VDC signals independently.

Another thing I tried with the VI is disabling one channel and only running one channel. This produced the error on the active channel. When I run both channels at the same time, the upper channel (TIMER/ctr0) shows the error.

Could this be a driver issue? Clock issues? Any suggestions would be appreciated.

[Kevin_Price]

The code looks generally ok for each counter to generate 2 minimal-duration pulses separated by a wait period.  The only thing I see to question is whether the reference clock is actually producing timing pulses for you.

What is the 'ARB' device you're trying to use as a timing source for your pulses?  Have you confirmed that its ReferenceClock is present and routable to your TIMER device?   You could check this out quickly with a shipping example for edge counting where you configure to count edges of 'ARB/ReferenceClock'.

On PXI, I expect the routing to be possible -- if it wasn't you should be getting a different error to tell you so. 

What happens if you remove the setting that changes the polarity to low idle state?   While that should be allowed while the task is stopped, it's the only other slightly non-standard thing I see.

-Kevin P

[JayWW]

---

@Kevin_Price wrote:

The code looks generally ok for each counter to generate 2 minimal-duration pulses separated by a wait period.  The only thing I see to question is whether the reference clock is actually producing timing pulses for you.

What is the 'ARB' device you're trying to use as a timing source for your pulses?  Have you confirmed that its ReferenceClock is present and routable to your TIMER device?   You could check this out quickly with a shipping example for edge counting where you configure to count edges of 'ARB/ReferenceClock'.

On PXI, I expect the routing to be possible -- if it wasn't you should be getting a different error to tell you so. 

What happens if you remove the setting that changes the polarity to low idle state?   While that should be allowed while the task is stopped, it's the only other slightly non-standard thing I see.

-Kevin P

---

Hi Kevin,

    Thanks for the response! So on our systems, we have a PXI-5404 designated as the "CLK" and a PXI-5421 designated as "ARB". I believe the CLK provides timing between all the devices. Typically our ARB is used to generate sinusoidal waveforms.

I ran the counter.vi example on each of our systems on both TIMER/ctr0 and TIMER/ctr1 and received the same results. Please see the attached image.

Without that additional code that changes the idle state the pulse just goes high and stays high.

It's really odd that this VI would behave differently on another system with the same hardware.

[Kevin_Price]

Ok, the last diagnostic seems to indicate that there are no presence or routing issues for the '/ARB/ReferenceClock' signal.  The counters on your 6602 can see and respond to it.  

So that leads to the next (and probably last) hypothesis:

On the system that produces timeout errors when you try to do pulse generation, explicitly wire in a generous timeout value.  1 second may be enough, 10 is the typical default.  I'm wondering if, somehow, the default value for timeout in that built-in vi got changed to 0 seconds or something like that on just one of your systems.  (And if that turns out to be the case, I'd suggest reinstalling DAQmx on that system.  If *that* built-in vi got modified, maybe others did too.)

-Kevin P

[JayWW]

---

@Kevin_Price wrote:

Ok, the last diagnostic seems to indicate that there are no presence or routing issues for the '/ARB/ReferenceClock' signal.  The counters on your 6602 can see and respond to it.  

So that leads to the next (and probably last) hypothesis:

On the system that produces timeout errors when you try to do pulse generation, explicitly wire in a generous timeout value.  1 second may be enough, 10 is the typical default.  I'm wondering if, somehow, the default value for timeout in that built-in vi got changed to 0 seconds or something like that on just one of your systems.  (And if that turns out to be the case, I'd suggest reinstalling DAQmx on that system.  If *that* built-in vi got modified, maybe others did too.)

-Kevin P

---

Hi Kevin,

    It's looking like it was a DAQmx driver issue. I went through and repaired some things and that seemed to fix it. Thanks!