changing counter output

[KennethW]

I am using NI 6321. I want to create a counter task to output a continuous waveform. ctr0 by default outputs to PFI12 but I need to change it to output to PFI0. I am using C#. I tried using:

DaqSystem.Local.DisconnectTerminals("/Dev2/Ctr0InternalOutput", "/Dev2/PFI12");
DaqSystem.Local.ConnectTerminals("/Dev2/Ctr0InternalOutput", "/Dev2/PFI0");

And in fact it does output the waveform to PFI0 but it is also outputting it to PFI12 which is connected to something else. How can I get it to stop sending the output to the default terminal?

[ybalam]

Welcome to the forums Kenneth!

The DisconnectTerminals method works for terminal connections you've made through the ConnectTerminals method, and not necessarily for default connections. The terminal should be available for route requests, though. Have you tried manually reserving PFI12 for another output or input and seeing if the connection persists?

[KennethW]

I have not tried that. The situation is the hardware engineer did not realize this pin was the counter output and is using it as a general purpose output which is working. I found how to direct the counter output to PFI0 but have not found a way to stop the counter ouput tp PFI12 as well (the default). When you say 'reserve' PFI12 I am not sure exactloy what you mean?

[ybalam]

Gotcha! If PFI12 is used for a different output, try connecting those terminals (PFI12 and where the output is coming from), in the same fashion you used for PFI0 to the counter output. 

The thought here is that instead of disconnecting PFI12 from anything, we'll connect it to something else to ensure the output doesn't persist through. Does that make more sense? 

[KennethW]

Not really.

By default, counter 0 outputs to PFI12. But we need it to route to PFI0. I accomplished this by connecting terminals.

PFI12 is the same as P2.4.

We are using P2.4 as a digital output.

When I write to P2.4 it sets the pin appropriately.

But when I enable the counter task it outputs to BOTH PFI0 and PFI12. What would I be connecting PFI12 to? I tried connecting it to P2.4 but that returns an error in your library.

[ybalam]

Ah, after reading my own reply over again, I think I may have gotten mixed up myself, apologies! Do you mind if I clarify if you're running both tasks at the same time? What I'm interested in is if the PFI line is being overwritten by the counter task, or if the counter task is outputting to both lines after the digital write has been done. 

Either way, I was able to pull up another forum post that speaks a little bit towards this, located here. It's nearly the same thing we're working with here, so hopefully it'll provide some guidance.

[KennethW]

Yes that problem sounds almost identical to the problem I am having.

I think it is the later in your reply, the counter task is writing to both lines. Here's why...

First, both PFI0 and PFI12 change when the counter task is running and when it goes back to idle. If I don't "ConnectTerminal" to connect ctr0 to PFI0 then only PFI12 changes.

I was also looking through the posts and found another similar issue and there they used:

counterTask.ExportSignals.CounterOutputEventOutputTerminal

I added this and now during the counter task execution I no longer get the pulsed signal on PFI12 during the task but once I stop the task and it returns to "idle state" it is still driving BOTH PFI0 and PFI12 to the same state which is turning something else on I don't want on connected to P2.4 (PFI12).

[ybalam]

Ah, I'm glad to hear you were able to use ExportSignals to get the correct signal on PFI12! 

Just to make sure I'm on the same page, in your last line, are you referencing stopping the counter task? If so, what output are you seeing on both lines after the task is done executing? 

I think the quickest workaround to get past both lines being driven will be to actively drive PFI12 low (or high, depending on your connections) while the counter task is idle to ensure that you're not seeing any default output on the PFI12 line, and instead, only the output you'd like to see. 

[KennethW]

Yes there is still a problem when I stop the counter task and it returns the line to the programmed idle state. You said to drive the PFI12 line to the right state after stopping the counter task but I can't do that. At that point I will have no way of knowing what the state of that line should be as it controls something else.

We are needing to ship this system to the customer in a few weeks so we really need this fixed. Unfortunately changing the wiring at this late stage is not really feasible. We need a solution in software.

[ybalam]

 Thanks for this info! Based on what we've talked through so far, I have a few thoughts on where to go from here.

My first priority is to work with your deadline--and for that, I'd recommend making a service request with us so we can troubleshoot more efficiently over the phone. If you take this route, please feel free to tell the AE on the phone you've been working with Claire, and we can sync up on my research on this so far. 

What is the ideal state or driver of PFI12 at the end of the counter task? I want to make sure I have a good understanding of this, as this is how we'll figure out a way to proceed. Is the PFI12 line is being driven to the programmed idle state in favor of a different task that should be accessing it at that point in time, or is there's nothing that's intended to be writing to PFI12?

Past that, my ideas depend on the state of the program at the time when the line is in the programmed idle state. Might I ask what that idle state is? If the program is done running at that point, we could look at resetting the DAQ card to send all the inputs to the normal power-up state.

Thanks so much! Let us know!