NI 6030e ctr 0 out and ctr1 interference

[ForrestGan]

Hi,

    I am using a NI 6030e connected to SCB-68.

    And use CTR1 out and CTR0 out to generate pulse train to control step motor.

    But I found that if CTR1 or CTR0 is generating pulse train, at the beginning of the pulse, the other channel will have a voltage rise too as shown in the image. 

     any way to solve this issue?

     thank you very much!

[Kevin_Price]

You're probably running a Finite Sampling pulse generatoin task.  In the E-series generation of counters, both counters work together to accomplish a finite pulse train.  One generates pulses only while the other one is in high state, that's the mechanism to control the finite # pulses.

This behavior changed with the introduction of X-series boards (PCIe-63xx).  On those, finite pulse trains only use up 1 counter.

There's a little more complicated way to configure the 2 counters manually to accomplish a finite pulse train while suppressing or redirecting the output of the one that generates a single long pules to control the other.   You can start by reading this.

-Kevin P

[ForrestGan]

Hi, 

    Thanks for the answer, but I still have questions.

    From the solution in that link, looks like it sets one channel to generate continuous pulse, then second channel is to trigger it pause. so these two channels will output pulse train alternatively, is my understanding right? 

     in my case is that, I need to control two step motors. when I want to move one step motor for several times, I will use one channel to generate pulse train several times, and the other channel can't output any pulse. 

     please explain a little more details, thank you very much!

Forrest

[Kevin_Price]

1. Your DAQ board has 2 counters.  Both *MUST* be used to generate a single pulse train with a known # steps.

2. Therefore, you *CANNOT* run 2 finite pulse trains out to 2 different stepper motors at the same time.  Your DAQ board simply isn't capable.

3. However you *CAN* run finite pulse trains out to 2 different stepper motors at *different* times.  You would use the technique I showed in the link, but exchange the roles played by ctr0 and ctr1.  The main purpose of that technique is to suppress the output signal from the "helper counter" so it won't send a single step pulse to the stepper you aren't trying to operate.

4. Reiterating, if you need to operate the motors *simultaneously*, there really isn't a good counter-based solution with your DAQ board.  You *might* be able to do such a thing with an AO task, but it will be much less straightforward to define step pulse timing.

-Kevin P

[ForrestGan]

Hi, 

   I tried the method in the other thread, but looks like even I set the CO.Pulse.Term = " ", I still can get the pulse output from the counter output. is it normal?

[Kevin_Price]

That's a technique that has generally worked under DAQmx.  Your board is pretty old though and probably pre-dates the introduction of the DAQmx driver.  It's possible your board (and other older legacy boards) don't support the ability to suppress the output.  I don't recall seeing that come up on the forums before though.    Can you post your code?  I'm still at LV 2016 so if you're using a newer version I'd need you to use the File-->Save For Previous Version menu option to save in LV 2016 format.

-Kevin P

[ForrestGan]

Hi, 

    Thanks for the quick reply.

    I am using python to control the DAQ, not sure if you can help on that. here is the code.

outputchannel = "Dev1/Ctr0"
gatechannel = "Dev1/Ctr1"
frequency = 1000
samples = 1000

def GenerateFinitePulse(outputchannel, gatechannel, pulsecount, frequency):
    with nidaqmx.Task() as pulse_task:
        pulsechannel = pulse_task.co_channels.add_co_pulse_chan_freq(
            counter=outputchannel,freq=frequency, duty_cycle=0.5)

        pulse_task.timing.cfg_implicit_timing(
            sample_mode=nidaqmx.constants.AcquisitionType.CONTINUOUS,
            samps_per_chan=1000)

        pulse_task.triggers.pause_trigger.trig_type = nidaqmx.constants.TriggerType.DIGITAL_LEVEL
        pulse_task.triggers.pause_trigger.dig_lvl_src=gatechannel + "InternalOutput"
        pulse_task.triggers.pause_trigger.dig_lvl_when = nidaqmx.constants.Level.LOW

        pulse_task.start()

        with nidaqmx.Task() as gate_task:
            gatechannel = gate_task.co_channels.add_co_pulse_chan_time(
                counter=gatechannel, low_time= 1, high_time= pulsecount/frequency)
            gatechannel.co_pulse_term = " "
            gate_task.start()

and somehow it also can't find the "Dev1/Ctr1InternalOutput".

Thanks!

[Kevin_Price]

I see a couple possible subtle syntax errors.  I would expect them to generate errors but I don't see that you're trapping or catching errors, so you might just get silent failure.  I would change the following lines:

pulse_task.triggers.pause_trigger.dig_lvl_src=gatechannel + "InternalOutput" gatechannel.co_pulse_term = " " 

---

The first should (probably) end with             = "/" + gatechannel + "InternalOutput"

The second should be an empty string, not a space character              = ""

The need for the leading "/" character is a curious and subtle distinction that I've seen be a tripping point for text programmers around here before.  (In LabVIEW, we get a drop-down selection that only contains legal values.  The "/" is there when we need it, not there when we don't.)

    I'm kinda puzzled by NI's choice of syntax.  Terminal and signal designations need the leading "/" to be present.  Channel designations need it to be absent.  If it were up to me, I'd use the leading "/" for everything.

    It's possible your space character " " has the same result as a truly empty string "", I haven't tried testing it.  But I *do* know that the empty string is a syntax that *does* work. 

Try those things, catch your DAQmx errors, put a debug trace on any strings you form, via temporary variable if necessary.

-Kevin P

[ForrestGan]

Thanks!

after adding "/", now there is no error from the code.

but through oscilloscope, I still can detect pulse from both channels, after I use empty string "".

and the pulse read from oscilloscope is strange.

from the output channel, it became a long pulse instead of a number of pulses. and from the gate channel, I can see one short pulse which suppose to be a long pulse.

[Kevin_Price]

It's beginning to look like the "" empty string trick might not be supported on your board as a method to block the counter's internal output from getting to an output terminal.  I'm not 100% sure yet, but it seems like your code is doing the right thing to try.

I also don't have any good explanation for why the output counter would produce only a single long pulse.

Can you run 2 distinct python modules simultaneously?  In LabVIEW I'd run the 2 counter tasks independently for troubleshooting.  Do you have debugging ability to trace through line by line?

I noticed that your code counts on a seemingly reasonable assumption that might turn out to be incorrect.  You start the real output task first.  It's configured to pause while the internal output of the gating counter is low.  The assumption is that this internal output will in fact be resting at low state before you configure and start the gating task, thus pulses aren't immediately generated by the real output task.  You should check to make sure this is true.

   I would try running *only* this real output task while monitoring the scope.  Try it with both kinds of pause triggering polarity (pause while low and pause while high).   Does it run continuously with one polarity setting?  Does it fail to pulse at all with the other?

Another thing worth checking.  On power-up, before running any counter tasks, what is the state of the two outputs?  After running your code and clearing the tasks, are either of them different?

-Kevin P