I don't know the cDAQ family real well, but I think it's mainly your chassis that governs how many counters you have and what you can use them for.
Many devices won't internally generate a sample clock for a counter-based measurement task. They depend on using a clock signal from some other source. Most of the time, this "other source" can be a programmed pulse train generated by one of the device's *other* counters.
So it's "external" with respect to the encoder task but it probably doesn't have to be external with respect to the entire cDAQ chassis.
I'd recommend getting away from the DAQ assistant. For starters, open up a couple of the DAQmx shipping examples - one for reading an encoder, one for generating a continuous pulse train. Get the configurations right so that the input terminal for the encoder sample clock is the same PFI pin as the output terminal for the pulse train. You can run both examples at once and should be able to see things working.
Once you're comfortable with how it works, you can then build a single vi that brings both tasks together, largely by copy and pasting from the examples.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
