Using digital trigger via RTSI bus with 6133

[OS-Prof]

I need to understand how to use a start trigger with my 6133 in LabView and DAQmx.

I use a PCIe-6536 Digital I/O board as a pattern generator to output a repeating sequence of 32-bit patterns to control my device under test, and I want to use my PCI-6133 to capture analog signals from the DUT resulting from a subsequence of the patterns.

One bit of the 32-bit pattern is wired back through PFI5 of the 6536, and then across the RTSI bus to the 6133. The clock is also routed across the RTSI bus from one board to the other.

My thought is as follows. Please tell me if I am on the right track and what else I should consider.

An array of patterns is written to the 6536 and its task is started in regeneration mode. The "trigger" bit is is programmed into the pattern array to indicate the start of sampling at that point. I am assuming that if software reads a specific number of analog samples on the 6133, the first sample read is the one corresponding to the pattern that held the start trigger. Correct?

My question is how to cause the sampling to stop again until the next time the trigger bit comes up in the next sequence of patterns?

To say this another way:-- the 6536 is continuously emitting a sequence of N 32-bit patterns. I want to take analog samples on the 6133 corresponding to patterns i thru j, and I want to repeat this on every cycle of N patterns.

Thanks for your help.

Hugh

[Jordan_D]

Hi Hugh,

There are a number of considerations to keep in mind when dealing with this type of application. The biggest one being the fact that the Analog Inputs on the 6133 do not support retriggering; meaning they can only be triggered once for a finite acquisition. The easiest way to work around this limitation is through the use of our retriggerable counters.

For your application we will create a counter task that outputs a finite digital pulse train every time it is triggered. We will then route this pulse train to the sample clock for the analog input. Now each time that your digital trigger line goes high, the counter will be triggered and will generate a finite number of pulses which will clock in a finite number of samples for the analog input.

Here are two example codes from the Example Finder that I would recommend starting with:

Hardware Input and Output » DAQmx » Generating Digital Pulses » Gen Dig Pulse Train-Finite-Retriggerable

Hardware Input and Output » DAQmx » Analog Measurements » Voltage » Cont Acq&Graph Voltage-Ext Clk

Keep me posted on your progress.

[OS-Prof]

Jordan,

Thanks very much. I called NI support on Friday and they pointed me to Gen Dig Pulse Train-Finite-Retriggerable. I coded it up in my system, but I could not get it to work with an external clock. The clock source in the example is "Implicit", and if I try to change it to an external source I get an error saying that the timing had to be Hardware one-shot or something like that. (I don't have the exact error number with me, but I phoned back to NI support and talked with the engineer again. She was quite puzzled by it.)

Over the weekend, I discovered the example Multi-Function-Ctr Retrigg Pulse Train Generation for AI Sample Clock.vi under DAQmx > Synchronization > Multifunction. This is a fully formed example that does essentially what I want, but again I cannot figure out how to import the sample clock from the PCIe-6536.

So I reworked my clocking and tried exporting the sample clock from the PCI-6133 instead. It seems that the PCI-6133 can easily export its 20 MHz master clock to RTSI7, so I tried to import that to the PCIe-6536 and got weird results. I think that I am not yet converting the master clock to the appropriate sample clock for the pattern generation.

I don't care which board generates the clock, but only that they both use the same clock forthe counter-based sampling based on the retrigger. My clock rate needs to be up to 1 MHz. The start trigger would then be a pulse of about one microsecond.

Any further suggestions?

Regards,

Hugh

[OS-Prof]

I went into the lab to reproduce the error in my previous message. The error is 200778, and it says that the Sample Mode is set to other than Hardware Timed Single Point. This is the only value supported for counter generations when Sample Timing is set to Sample Clock.

Hugh

[Jordan_D]

Hi Hugh,

I think there might be some confusion over the "sample clock" here. You have to keep in mind that the "clock" generated by the counters is not a continuous clock. It has a number of pulses, and then dead time, then more pulses, then dead time....etc.

You will need to use different sample clocks for each card since one will be continuous pulses and the other will have breaks between groups of pulses.

Since you are already sharing the trigger, the only line left that you might want to share is the reference clock used to generate the sample clocks on each device.

You will need to modify the Multi-Function-Ctr Retrigg Pulse Train Generation for AI Sample Clock.vi example by adding a DAQmx Channel Property Node in the location shown below. Once it is wired together, configure the node with the following setting Counter Output » General Properties » Counter Timebase » Source and point to the reference clock of the first device (being passed by RTSI) for the reference clock input.

Message Edited by Jordan D on 09-18-2007 12:30 PM

[OS-Prof]

Jordan, et. al.,

It didn't work.

I wired in a DAQmx Channel node as you recommended and connected it to the DO/SampleClock of my 6536 board. I got Error # 200143, which said that it needed a Timebase Rate.

So I added a terminal to the DAQmx Channel Property node for CO.CtrTimebaseRate and wired my clock frequency (1 MHz) to it. I also made sure that the Sample delay was 0.5. When I tried it, I got Error # 200136, complaining that the Frequency and Initial Delay property values are inconsistent with one or more counter timebase properties. I tried a bunch of things and could not get past this point. A copy of my VI (Create Data Acquisition Task (Phase I).vi) is in the attached zip file.

(Should I have been trying to import the DO/SampleClockTimebase instead? The problem seems to be that the timebase of the 6536 is 200 MHz, which would be too fast for the 6133.)

Eventually, I tried a different tack. Instead of trying to import the 6536 clock into the 6133, I tried exporting the 6133 timebase to the 6536. I added a DAQmx Timing Property node to the 6536 task to import 20MHzTimebase from the 6133, and then I divided it down to get my 1 MHz sample clock for the digital output patterns. This seemed to work. I was able to see on an oscilloscope that the start trigger was coming at the right rate, and I was able to collect samples on the DAQ.

However, the next problem is that when I put a probe on the output of DAQmx Read function, I expected it to produce a 2D array -- one dimension being the number of channels and the other the number of samples. Instead, I found that the number of samples in the array was much larger than the number I had tried to read. Is this another problem or related to the same one?

Regards,

Hugh

[Jordan_D]

Hi Hugh,

It sounds to me like this is an unrelated problem. Try taking a look at your "samples per channel" and "samples to read" inputs to your DAQmx vi's. Keep me posted on your progress.

[OS-Prof]

Jordan,

Thanks. It turned out to be a mis-wire of the Samples To Read control to the Timeout terminal. That was hard to spot because we were intent on using the default timeout value; once we found it, things worked well. Thanks very much for your help.

Regards,

Hugh