Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

how to route an input PFI that I am using as a clock to an output PFI

Hi,

I have a USB 6218 and USB 6366.

I am externally triggering using PFI0 terminals in both i.e., signal from a function generator is input to PFI0 of 6218 and PFI0 of 6366

I am deriving 4 analog outputs, two from each for every clock trigger pulse. These are waveforms going from -10 to +10 V

However, I also want to output this clock when DAQ starts its operations to activate another external instrument.

Unfortunately, I am not sure how to do that.

adding triggered digital output port0/line2 does not work because on these devices clocked digital output isn't possible.

 

Is there a way that I can send the PFI0 input to PFIx output where x is anyone of 2 to 15?

 

I tried outputting the PFI10 to 'external' but got an error saying only one clock is allowed.

Or is there any other way besides using a third DAQ?

Thanks

0 Kudos
Message 1 of 6
(1,666 Views)

A few things.

 

Assuming LabVIEW, a simple approach would be to use a DAQmx Timing property node to configure PFIx as the "SampleClock.Terminal".  Note: this is distinct from setting up PFI0 as the "SampleClock.Source".   The SampleClock.Terminal only shows clock pulses while the AO task is active and running.  You'll get the same # of clock pulses there as the # of AO samples you generate.

 

In a previous thread, I steered you away from configuring any triggering b/c I didn't know you were coordinating 2 different USB DAQ devices.  Assuming that you want your outputs sync'ed and that the PFI0 clock signal is free-running before you start up your program, you *will* need both tasks to be triggered by some other common signal.  Perhaps something like a DO line that you can control in your program so you don't generate the trigger pulse until both AO tasks are started and ready for it.

 

 

-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.
Message 2 of 6
(1,657 Views)

Hi Kevin

Thank you for the response.

I apologize but just beginning to understand I/O concepts here and so still somewhat confused. Hope you will clarify further

 

You wrote

"Assuming LabVIEW, a simple approach would be to use a DAQmx Timing property node to configure PFIx as the "SampleClock.Terminal". Note: this is distinct from setting up PFI0 as the "SampleClock.Source". The SampleClock.Terminal only shows clock pulses while the AO task is active and running. You'll get the same # of clock pulses there as the # of AO samples you generate."

 

> So I just declare for example PFI12 as SampleClock.Terminal with PFI0 as the input clock? That was simple!

> (I should also declare that I am using Matlab to run NiDAQ and porting LabView connections to  Matlab commands which isn't easy but at this time I am just trying to grasp the basics)

 

"Assuming that you want your outputs sync'ed and that the PFI0 clock signal is free-running before you start up your program, you *will* need both tasks to be triggered by some other common signal. "

> This is a bit confusing because I am using same clock signal but splitting it to go to two PFI's on each device. And I have declared them to be the clocks. So this should naturally synchronize both?

> Once I issue  two individual write statements one for each DAQ, the clocks should start the output on each device for every clock pulse? Why do I need another trigger?

> I did have a trigger channel on both as you correctly pointed out and removed them because I bought your logic of using clocks as triggers. That seemed to run well though I have not looked at the outputs closely enough to see if synchronization was lost in the process. It did not look like that to me.

>Oh, are you suggesting to use Trigger because now I can redirect that trigger to any other PFI terminal?

 

Just for the sake of it I will copy here Matlab statements

 

addoutput(daqObj_1,'Dev2','ao0','Voltage'); %y-direction mirror control
addoutput(daqObj_1,'Dev2','ao1','Voltage'); %x-direction mirror control
%addoutput(daqObj_1,'Dev2','Port1/Line0','Digital'); %cannot do this for clocked operations
 
 
addoutput(daqObj_2,'Dev1','ao0','Voltage'); %y-direction mirror control
addoutput(daqObj_2,'Dev1','ao1','Voltage'); %x-direction mirror control
 
clk1 = addclock(daqObj_1,"ScanClock","External","Dev1/PFI0");
clk2 = addclock(daqObj_2,"ScanClock","External","Dev2/PFI0");
 
%Now I would like PFI0 to be output to PFI12. These statements do not work individually
clk3 = addclock(daqObj_2,"ScanClock","Dev2/PFI0","External");
clk3 = addclock(daqObj_2,"ScanClock","Dev2/PFI0","Dev2/PFI2");
clk3 = addclock(daqObj_2,"ScanClock","Dev2/PFI2",,"Dev2/PFI0");
0 Kudos
Message 3 of 6
(1,593 Views)

Thanks Kevin

i think I understand it now. 
1. so both tasks have to be started

2. without a trigger there will be improper synchronization because write statements are sequential

3. I am curious though- in LabView it seems task run in parallel for the two DAQ’s but in scripting language the two write statements for the two DAQs are sequential?

4. But a common trigger will cause both FIFO to output at the same time.

 

0 Kudos
Message 4 of 6
(1,618 Views)

It sounds to me like you have a *partially* correct understanding now.  Let me summarize key points.

 

1. You have a buffered, hardware-clocked AO task on each of 2 USB devices.  You want them to start together and remain sync'ed together.

 

2. With buffered AO tasks, you should *write* your data to the tasks *before* starting them.   So the order of the writes is inconsequential when the tasks aren't running yet.

 

3. A shared start trigger is needed to sync the start time of the 2 devices' AO generation tasks.  When they're configured to use the same start trigger, the order of the DAQmx Starts is again inconsequential.  Neither task starts generating output when the trigger hasn't arrived yet.

 

4. So you need to configure both tasks, write your data to them, start them, and *then* issue a trigger pulse to make them start signal generation.

 

5. Once running & triggered, their shared Sample Clock signal is what keeps them in sync.  If they both used their own individual internal clocks for timing, the spec sheets say their timing could vary by a few msec per minute of run time.  (Clock accuracy specs for many common NI products are often 50 parts per million, which works out to 3 msec per minute.)

 

6. Repeating for emphasis: it isn't the common *trigger* that causes them to output at the same time, it's the common *sample clock*.

 

 

-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.
Message 5 of 6
(1,587 Views)

Yes I got it after a bit of reflection in your earlier message. Thank you

0 Kudos
Message 6 of 6
(1,583 Views)