NI 6030e ctr 0 out and ctr1 interference

[ForrestGan]

Here is one strange thing, if I use the code below to generate one pulse, the pulse width doesn't change no matter what "t" I change. and if I add the gatechannel.co_pulse_term="" before the gate_task.start(), the signal still can be detected from the output. (for this single pulse output, there is no need to set timing, right?)

def ControlGateChannel(gatechannel):
        t = 0.1
        with nidaqmx.Task() as gate_task:
            gatechannel = gate_task.co_channels.add_co_pulse_chan_time(
                counter=gatechannel,
                idle_state=nidaqmx.constants.Level.LOW,
                low_time= t,
                high_time= t)
            gate_task.start()

  if I use the code below to generate continuous pulse, the signal looks ok. but still the co_pulse_term="" doesn't work.

    with nidaqmx.Task() as pulse_task:
        pulsechannel = pulse_task.co_channels.add_co_pulse_chan_freq(
            counter=outputchannel,
            idle_state=nidaqmx.constants.Level.LOW,
            freq=frequency,
            duty_cycle=0.5)
        
        pulse_task.timing.cfg_implicit_timing(
            sample_mode=nidaqmx.constants.AcquisitionType.CONTINUOUS,
            samps_per_chan=10000)

the DAQ is NI PCI-MIO-16XE-10, and I think it is the PCI 6030e, right?

[Kevin_Price]

First, correct, you make a single pulse output by *NOT* setting up acquisition timing. 

Second, the NI documentation and examples haven't always been in great sync when it comes to the 3 key pulse parameters -- Low Time, High Time, Initial Delay.   (And I'm not sure if the behavior has remained consistent through the history of driver versions.)

The help will tell you that Low Time and High Time are used to define timing for pulses #2 through N.  But the 1st pulse is treated differently and in a single pulse task, the 1st pulse is the *only* pulse. 

   For the first pulse, the counter remains in idle state for "Initial Delay" time.  If the idle state is low, it then pulses for "High Time" and is done.  If the idle state is high, it pulses for "Low Time" and is done.   Only 1 of (Low Time, High Time) get used.

   (Note however that the shipping example for single pulses wires up Low Time and High Time while *not* wiring up Initial Delay.)

   Your gate counter is set for low idle state, so it should ignore your Low Time setting and use the Initial Delay value instead.  Because you didn't define the value, it'll use a default value which is the minimum possible.  However, you should have seen changes in the high pulse width as you changed 't'.  I don't know why you didn't.

   I'd try some more things out where you also explicitly define Initial Delay.  Make each of the 3 pulse parameters distinct enough that it's clear which 2 are being used.

Since neither counter seemed to honor the "trick" of routing the output to "",  I'm becoming more convinced that your board is just too old a design to support that trick.   Is it possible instead to route the gating counter output to a different PFI pin that isn't physically wired to anything?  Let's just suppose that's PFI5.  Then whichever counter was acting as the gate counter would route its output to PFI5 where it would be harmless.

-Kevin P

[ForrestGan]

Hi,

    I tried on NI PCI 6259 M series DAQ, but the trick doesn't work either.

    I use the same code as posted, and from oscilloscope, I can see the certain number of pulse from the output channel, and still can see the pulse from the gate channel. no matter use  the co_pulse_term = "" or co_pulse_term = "/Dev3/PFI0"  (because from the DAQ device routes map, looks like the "InternalOutput" direct route to this destination) 

[Kevin_Price]

Still puzzled, I searched the forums some more.  Maybe this thread will help, based on the discussion of "lazy uncommit".   Try what it says about resetting your board before trying the code that sends the counter output to "".  (You can reset the board from MAX).

-Kevin P

P.S.  The InternalOutput can probably be routed to *any* of the PFI pins.  It may be the case that the "lazy uncommit" behavior mentioned in the thread above means that the original default route remains in place until the board is reset (or other direct action is taken).

[ForrestGan]

Hi,

   Thanks!

   Now if I reset the DAQ, it works partially.

   After reset the DAQ, then when I run  the code, I do see that the gate counter channel's signal was suppressed.B But then when I want to switch the channel, use other channel as the gate channel, it will still output the signal. and I have to reset the DAQ again.

   any way to solve this issue?

[Kevin_Price]

I don't have any further direct knowledge.  The "lazy uncommit" behavior discussed in the linked thread seems to have been relevant, but it isn't something I've had to work through and resolve personally.  The thread also suggests an alternative solution by setting a DO tristate property.  I'd venture you might have more chance of success at this with your newer M-series board.   Note that there's probably not a way to programmatically query DAQmx to figure out which DIO port # and line # (apparently needed for setting the tristate property) correspond to a given PFI pin # (the designation needed for counter tasks).

There were several hits on the site for "lazy uncommit" that you could further explore for more possible suggestions.

-Kevin P