Labview counters in indeterminate states

[Stephen_W]

Does anyone know why a terminal configured for counter output may sometimes enter an indeterminate state? I have observed this when a digital output task is called after the counter is called (even though the channels and terminals are different)

[Mark H]

This is really a Data Aquisition question (not necessarily LabVIEW).

I think you need to specify exactly what NI hardware you are using, which signals/pins, what DAQ functions you are calling and whether traditional or mx.

[Stephen_W]

Thanks for your reply Mark,

I am using an NI 6602 card connected to a SCB-68 pin block in a CA-1000 enclosure.  I am using all 7 counters for different functions but the one that is reverting to an inderterminate state is counter 2 (i'm ouputting a single pulse to the counter on pin 32).  It only does this when I try to send a digital output to DIO 3 (pfi_3) which is pin 12, after calling the counter (if the digital channel is not changed the counter remains at low).  I.e. the counter output goes from low to high to low.  Then after the digital output it reverts to an indeterminate state which is about 1/3 of digital 1. I am using DAQmx and calling the following VIs:

For the digital output i've used

Both the 'DAQ assistant' configured for digital output and a task that I configured in MAX and used in Labview with 'DAQmxwrite'

For the counter output i've used

'Daqmx create channel' configured with 'CO pulse time' (finite samples, 1 sample, implicit).  I then use 'start task', 'wait until done' and 'stop' (i've tried 'clear' too).  Before 'Daqmx create channel' I have a 'create task'  VI.

It seems bizarre to me.  Equally strange is that this problem only seem to occur when the digital ouput is invoked after the counter output.  I can invoke it as many time as I like before.

Hope you able to help although I appreciate this is an unusual one.  Let me know if I can provide any more information.

Regards,

Stephen

[Kevin_Price]

Stephan,

I don't really know the answer, but I'd recommend a couple things for the sake of troubleshooting:

1. Configure the digital task explicitly, starting with DAQmx Create Channel.  Configure it for a single channel using syntax like "Dev1/port0/line3".  Provide a means to toggle your digital output bit and then also to stop & clear the DO task.  Observe whether the behavior is the same in this scenario as when you use the DAQ Assistant.

I can't comment specifically on the Assistant b/c I never use it.  I only know that part of the simplicity it provides comes from making some of your decisions for you.  Sometimes this leads to unexpected and undesired side effects.

2. Check to see if the same behavior occurs when putting the pulse out with Ctr0 or Ctr1, whose default output pins are not shared with the DIO port.

3. Are you checking for DAQ errors?  I'm wondering if the DAQ Assistant tries to map the entire 32 bit port as output bits, creating a resource conflict with the PFI pins shared by Counters 2 through 7.  If so, I would expect a DAQ error to be produced by at least one of the two tasks (probably whichever is committed later).

4. Have your tried testing out this behavior in MAX?

-Kevin P.

[Stephen_W]

Thanks Kevin for your reply.

This was undoubtelby peculiar behaviour.  The explaination could be physics rather than computing.  I managed to find a way around it by transferring the digital task to another card (fortunately our system has both 6602 and 6621 cards mounted in it).  The 6621 card was hardly used except for a few digital output lines whereas the 6602 was using all 6 counters and some digital/triggering lines.  Whatever the cause, easing the load on one card solved the problem a treat.

Thanks anyway for your reply and for your time.  This was my first time using this forum and it was a good experience.  I think this will prove to be an invaluable resource for support as I do quite a lot of Labview and problems like this that aren't in the book often crop up.

Regards,

Stephen