Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

How to disable routing of counter output so I can use associated PFI pin

How can I disable the counter inputs and outputs so that I can use the associated I/O pins for other functions?

I am using a NI6353 X-series data acq board. I am using the counters to track encoder positions. By default, each counter is routed to 4 PFI pins, with 4 counters this ties up all 16 PFI bits. I am only using the A and B inputs to each counter, not the Z input nor the counter output. I want to disconnect the counter output from the default PFI pins so I can use those pins for general digital I/O.

I am using the DAQmx C interface.

I found other forum posts such as this http://forums.ni.com/t5/Counter-Timer/How-to-suppress-counter-output-on-default-terminal/m-p/979919 that said I should use DAQmxSetCOPulseTerm() to set the output terminal to the empty string.

When I try to do this, I get error 200452, "Specified property is not supported by the device or is not applicable to the task".

My code looks like this:

DAQmxCreateTask("", &CounterTaskHandle);
char* ChannelString = "Dev1/ctr0";
DAQmxCreateCILinEncoderChan(CounterTaskHandle, ChannelString, "",
    DAQmx_Val_X4, 0, 0.0, DAQmx_Val_AHighBHigh, DAQmx_Val_Ticks,
    1.0, 0.0, NULL);
DAQmxGetCOPulseTerm(CounterTaskHandle,ChannelString,buffer,1000);
DAQmxSetCOPulseTerm(CounterTaskHandle, ChannelString, "");

 Both the Get and the Set return this error.

Any ideas? Thanks

 

0 Kudos
Message 1 of 7
(3,694 Views)

 

I think the error is because you are calling an output-related function (DAQmxGetCOPulseTerm) for task that was defined for input.

 

The bigger point is that by default, counter input tasks already don't connect their internal outputs to a PFI terminal.  You shouldn't need to "disconnect" it -- it should already be available.  So that should at least free up 4 PFI pins for other uses.

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 7
(3,692 Views)

That's not what happens. As soon as I start the counter timer task, the output goes low. This happens even if I have already started a DO task which has set the pin to output and set it high.

 

0 Kudos
Message 3 of 7
(3,690 Views)

Sorry for the misinfo.  I know I've been able to use shared DIO/PFI lines on other boards without seeing similar issues and figured the behavior was universal.  As I think about it, I can't be certain that my DIO used the specific PFI line(s) designated for counter outputs.  I just know I've used a large fraction of the total DIO / PFI's before without any particular problems like you're seeing.  I figured I *must* have had a few shared pins along the way, but maybe I just got lucky, or maybe the behavior of the boards are different.

 

Have you tried things like setting tristate properties for those PFI lines or tried configuring tasks in the opposite order?   I strongly suspect there's a solution, but lacking hardware to try things on, I'm afraid that's about all I have for ideas. 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 7
(3,683 Views)

That seems odd--I don't believe the counter output event should be routed by default for an input task.

 

I don't have the C API installed at the moment, but I tried the following in LabVIEW and found that the counter output line (PFI 12 by default for ctr0, aka port2/line4) stays high even after running the counter task:

 

DO Counter Test.png

 

 

You might try calling DAQmxSetExportedCtrOutEventOutputTerm.  This is how one would go about routing the counter output event when configuring an input task.  I tried reading the value back in my simple example shown above and found that it was a null terminal (meaning the output was not routed to any PFI line by default in my case).  Setting the value explicitly to PFI 12 makes the digital output line go low when the counter task is started (as one might expect).

 

 

Best Regards,

John Passiak
0 Kudos
Message 5 of 7
(3,670 Views)

You should just need to get to the specific type of terminals you need for this task. One of these would work:

disable the Z index - that should free up the terminal

DAQmxSetCIEncoderZIndexEnable()

If not, set the terminal to blank or a RTSI line if you're not using it:

DAQmxSetCIEncoderZInputTerm()

 

I'm not sure that I understand the issue with the default Counter output line - that terminal is not used by default in an angular encoder measurement and I can use that line for DIO when I create and run an angular encoder task.

 

Hope this helps,

Andrew S 

0 Kudos
Message 6 of 7
(3,657 Views)

Thanks everyone for the replies and suggestions. The output line is defintely going low for me when I start the C/T task, but it's good to know that it doesn't happen for other people. I will try the DAQmxSetExportedCtrOutEventOutputTerm function and see if I can figure out what is going on.

0 Kudos
Message 7 of 7
(3,648 Views)