Using the frequency scaler on the PCI-6733 from C NIDAQmx

[Frisket]

Hi
I want to be able to access the 4 bit frequency on the 6733 card from the NIDAQmx C API.

Ideally I would like to divide down the 20MHz timebase clock to say 10MHz and use that as an input into the counter timers. I need a high resololution timebase, but not 20MHz as the counter timers are only 24 bits and one of the pulse trains I want to generate using them requires a high time of > 2^24 timebase ticks. I could use one counter timer to divide down but I need this for another pulse train.

The boards documentation talks about this 4 bit frequency scaler which seems ideal for the job. Alternatively I could use the digital outs to effectively clock divide using an appropriate sample waveform. Although this works, the DIOs have huge over and under run on the digital signals at high clock rates. Now this could be an output cable issue (I use the NI screened break out box). I suppose if I could internally route the DIO output and use this as a clock that would also do but I am not sure if this is possible.

Thanks.

[gus]

Your best bet is to use the 4-bit counter on the 6733. In DAQmx, you can create a continuous pulse train generation task with channel "DevX/freqout" of 10MHz. You will have to manually connect this to the source of your counters because there are no internal connections between the FREQOUT and the counter source pins.

I hope this helps!
gus....

[Frisket]

Thanks. I finally figured out that the frequency scaler is setup using the counter output API functions. I had assumed as this was a rather specialised scaler it was covered by its own API.

When you save connect it up manually I take it you mean a piece of wire? I have this setup now, though I was hoping for an internal route. Sadly throwing 10MHz down the SCB cable to the SCB 68 and then back again does not do much for analogue signal integrity.

Is this the only way to do this without resorting to a different card with a larger precision counter time?

David.

[Jeremy_C]

The freqout line does not support any kind of internal routing. So, the answer is "yes" to your question about having to use an external wire. However, the counters used on 6601, 6602, and any M Series boards are 32 bits. This would eliminate the need to divide down the 20MHz clock in order to prevent the overrun of the 24 bit counters on the 6733.

[gus]

Hello David-

It is possible to use the general purpose counters on the 6733 to generate a 10MHz pulse train, but it's a little more difficult than using the 4-bit frequency scaler. Generate a 5 MHz pulse train and then configure a counter output event to use pulse (instead of toggle). This should give you a 10MHz pulse train with a 50% duty cycle.

Let me know if you need help getting this configured.
gus....

[Frisket]

---

@gus wrote:
Hello David-

It is possible to use the general purpose counters on the 6733 to generate a 10MHz pulse train, but it's a little more difficult than using the 4-bit frequency scaler. Generate a 5 MHz pulse train and then configure a counter output event to use pulse (instead of toggle). This should give you a 10MHz pulse train with a 50% duty cycle.

Let me know if you need help getting this configured.
gus....

---

Would you mind explaining this one a bit more. If it involves using one of the two 24 bit counter/timers then it won't solve the problem, as I really need both counter timers to generate my other two pulse trains.

Thanks.

David

[gus]

The method I was describing would be using one of the 24-bit counters. Can you explain a little more about what your overall application is? How many pulse trains, what rates, etc?

[Frisket]

---

@gus wrote:
The method I was describing would be using one of the 24-bit counters. Can you explain a little more about what your overall application is? How many pulse trains, what rates, etc?

---

The NI card is generating one analogue waveform to drive a scanning mirror and two digital pulse trains to drive a line and frame sync. The line sync will be active high for approximately 1 second, then low for maybe 10-20 clock periods (say 1MHz clock), i.e. the duty cycle is very much biased to the high time, hence the 24 bit counter issue when driven from the 20MHz timebase clock.
The line sync is approx 95% duty cycle, and there are 11000 line sync pulses per frame sync. For each line sync we want one of the analogue samples to be driven.

Basically I have a working system as follows, but it is not perfect due to looping round the freq_out signal.

I have used the freq-out to generate a 1MHz clock. This feeds into the line and frame syncs, via an externally routed feedback. The line and frame syncs are clocked from the same timebase to ensure exact alignment without drift. The frame sync is setup to have the required profile, i.e. 11000 * the line sync pulse width. The line sync is setup with its profile, and triggered to start from the rising frame sync pulse edge, with a few clock cycle delay to ensure frame sync rises before line sync. The analogue signal is sampled from the rising edge of the line sync pulse. Thats it.

@I could have done everything I wanted if the frame time had been less than the 2^24 @ 20MHz time.

David

[gus]

Yeah David, it looks like the setup you have is as good as you're going to get unless you have another device in your system that could be used to generate the clock signal and then routed over RTSI. From looking at your specifications, I suspect that the 100kHz timebase won't work for you because it doesn't provide enough resolution, correct?

gus....

[Frisket]

---

@gus wrote:
Yeah David, it looks like the setup you have is as good as you're going to get unless you have another device in your system that could be used to generate the clock signal and then routed over RTSI. From looking at your specifications, I suspect that the 100kHz timebase won't work for you because it doesn't provide enough resolution, correct?

gus....

---

Spot on. I had already considered and rejected the 100kHz timebase after doing a few calculations.

Thanks

David