Complex signal routing and Sync on a 6602

[Jed_Davidow]

I have an application for a 6602 where I need to do the following:

1) Route signals as such:

• GPIO (PFI0) --> RTSI0
• CTR1_Out --> RTSI1
• CTR2_Out --> RTSI2
• CTR3_Out --> RTSI3
• CTR4_Out --> RTSI4
  

Note that I don't need to use those specific PFIs and Counters, I can use any of them.

Furthermore, I also need to be able to do the following:

• The GPIO line is controlled independantly through SW.
• The Four counters are outputting synchronized square waves (CO FREQ), but at different phases (custom stepper pattern).
• This will be used in parallel with a SCXI system running an analog acquisition, and I need to be able to do one of the following:
• Pulse the counters a fixed number of pulses, then check the analog input from the SCXI
• Run the counters continuously, but synchronize the analog input to the rising edge of the first counter.  I need to be able to, while running, to know the voltage at a specific coutner step number.

My first stab was to route PFI0 to RTSI1, then the four counters as above.  Apparently this was the wrong order, becasue the PFI0->RTSI0 route interferes with the RTSI4 route.  Unfortunately, the hardware we designed for this requires that the GPIO be on RTSI0.

I also am unsure how to get the counters synchronized; If I place them all in one task, they apparently are in sync, but I can't run a fixed number of steps (only continuously).

Will this work?

• Set up all 4 counters in 4 different tasks, using a fifth counter as a timebase.  Start them.
• Start the fifth counter to run the other 4.

Also, to provide a sync signal for data acquisition for the M-Series card running the SCXI chassis, I would add another counter to the four that is set up exactly like CTR0, and then route that one over the RTSI5 pin to use as a scan clock for the SCXI.

What do you all think?  The big thing is getting that GPIO signal on RTSI0.

Another option is to use a GPIO from the M-Series card on RTSI0, but can this be done if the board is running a SCXI controller?

[Kevin_Price]

I don't have actual hw to experiment, but made a simulated 6602 to look over the device routing table in MAX. 

The table shows direct routes available for PFI0 and for any counter "internal outputs" to any of the RTSI pins.  (I had expected to find that perhaps the PFI0 required an indirect route, but that doesn't appear to be the case.)

So, I agree that it seems this *should* be doable and don't have a solid idea why you get routing conflicts.  Let me ask this though: why do you need to specify which RTSI line receives each counter output?  If the other receiver of those signals is another NI data acq task, you wouldn't need to specify the signals by specific RTSI line #, you could refer to them like, "/OtherDevice/Ctr3InternalOutput".

I used to explicitly set up all my RTSI routings under traditional NI-DAQ and was initially kinda annoyed and distrustful of letting DAQmx handle it all auto-magically.  With time I came to trust it and would now only set up explicit routings as a last resort.   I'm kinda wondering if you have a case where you have some explicit routing that's trying to be set up after its needed resources were reserved by some auto-routing.  In case that's possible, I'd be inclined to go with all auto-routing as a first choice, committing the manual route(s) before the auto-routes as a second choice, and all manual as a fallback.

You can use a 5th counter to act as a timebase to help keep the other 4 in sync.  If you need to generate a finite pulsetrain as a timebase (to have hardware control over # steps), remember that you'll actually be using 2 paired counters such as CTR6 & CTR7.  (The available pairings are 0/1, 2/3, 4/5, 6/7).

-Kevin P

[Jed_Davidow]

---

@Kevin_Price wrote:

So, I agree that it seems this *should* be doable and don't have a solid idea why you get routing conflicts.  Let me ask this though: why do you need to specify which RTSI line receives each counter output?  If the other receiver of those signals is another NI data acq task, you wouldn't need to specify the signals by specific RTSI line #, you could refer to them like, "/OtherDevice/Ctr3InternalOutput". 

---

We have our own hardware mounted in the same PC chasis, and we designed it to use the RTSI bus.  The simulated device feature tripped me up because it did not give me this error.

Question though; I used the Route Signal rather than Export signal.  Can I use the "Internal Output" specifier with the Route Signal function?  Maybe this is causing the trouble, since I am trying to route by spefifying PFIN rather than "InternalOutput".

The reason is that I can set up all of these in one task and they will run continuously together, and this might work OK for me (now that I have the acquisition synchronized to one of the counters).

[Kevin_Price]

"Route Signal" sounds like an old function from traditional NI-DAQ.  Do you mean that you use "DAQmx Connect Terminals" in the signal routing palette?  That function makes device-level connections and I don't know what board resources get used or how DAQmx decides.  To be honest, I haven't personally had a need to make those kinds of semi-permanent routings.  I've always done task-based routings such as the ones you'd get by using "DAQmx Export Signal".

I guess I'd at least try using "DAQmx Export Signal" because it *might* help.  In general, I've found task-based routes to be simpler to deal with compared to the occasional issues I read about people having with device-based routes.

-Kevin P

[Jed_Davidow]

The problem is simplicity,

If I use one taskfor all counters, they work together with zero extra programming, but I need to use the "Connect Terminals" (Yes, I am suing the old terminology, I am old).

I looked for an example on synching multiple CO; I did not find one.  Do I just define counter 7 as the timebase for the others and then set it running to start them together?  I did not follow why I would need to use two of them to do this.

[Kevin_Price]

Well as one old-timer to another, no problem, just making sure. 

I'm a little embarassed to admit that I haven't made use of the one-task-for-multiple-counter-outputs feature.  That didn't used to be available and I don't think I learned about it until sometime after the last time I might have used it.

I was assuming that you could make multiple calls to "DAQmx Export Signal" using the common shared task but designating a different Ctr#InternalOutput and RTSI# each time.  Have you tried that and gotten errors?

Otherwise, yes, you could set up Ctr7 as the timebase for the 4 counters whose outputs you care about as long as Ctr7 is started after the other 4 and the phasing is set up right.  (I know you already know this, I'm just repeating it because someone else may read this and need the reminder.)

The thing about using 2 counters for this timebase is only in case you want Ctr7 to be a *finite* pulsetrain with hardware timing in order to have precise control over the # steps generated.  On the 6602, a finite pulsetrain generated on Ctr7 will internally need to use Ctr6 as a helper.

Are the 4 outputs going to be a quadrature pair and an inverse of that pair?

-Kevin P

[Jed_Davidow]

Export signal uses an ENUM to specify the signal to export, and they are general ("Counter Output Event"), so it's tied to the single CO on the task.

Thanks for the info, and yes; the 4 outputs are Quadrature, but they are slightly modified so we can characterize the rotor.

[Kevin_Price]

D'oh!  My bad, I overlooked the limited ENUM input.  At this point, I'd probably sync the 4 counters by sharing a common timebase generated by Ctr7 or whatever.  Then I'd use the task-based DAQmx Export Signal on each task separately to do the RTSI routing.

-Kevin P

[Jed_Davidow]

I think that's the road to go.

When I set up the master timebase counter, if I want a fixed number of pulses, do I need to do something special, or will DAQmx use the other counter implicitly?

[Kevin_Price]

When you configure a counter output for finite sampling, DAQmx will use the paired counter implicitly,  Nothing special you need to do, I was just forewarning that the paired counter would be needed.

-Kevin P