6602 6612 difference

[Alexander_Sobolev]

While upgrading from 6602 to 6612 I noticed different results when I use the same functions with the same arguments..

While generating single retriggerable pulse, the initial delay of the first pulse depends on the board I use. With 6602 it is (low time+initial delay), with 6612 it is initial delay only.

LV 2011, WIn 7, Win xp, DAQmx 14.5.1.

I was under impression that if the feature is supported on different devices, it should work the same way. Additional options of the feature are set using properties to not default values. For example Enable initial delay on retrigger modifies pulse generation, but only if it is set to true.

One more difference is that PCI-6602 allowed not to use Implicit daqmx timing for retriggerable single pulse generation, PCIe-6612 demands it - without it it works, but times are not set correctly. 

The question is what are other behaviour changes can I expect in the same functions with the same arguments? 

[Kevin_Price]

Thanks for sharing & clearly illustrating your observation.  I too am very interested to know what other differences there may be.  I'd also like to know whether X-series MIO boards share all these differences with the 6612 considering they are both designed around the NI-STC3 timing chip.

Meanwhile, here's one I stumbled into where an X-series counter behaved differently than all pre-STC3 counters.

When doing buffered period measurement, an X-series counter buffers its 1st value at the *end* of the first period when the 2nd active edge arrives.  Prior generations of counters buffered the 1st value on the 1st  active edge.  That first measurement was often a meaningless fraction of an interval that represented an arbitrary time from task start to 1st edge.  It could only really be meaningful on a task with an arm start trigger.  HOWEVER, even though the measurement value often wasn't *meaningful*, it could still sometimes be *useful* to buffer it on first edge.

I had an app where I was taking analog data using a variable rate external clock.  Because of the variable rate, I also set up a buffered period measurement task to track cumulative time and perhaps characterize the details of the variation.  I developed the app with an M-series board where the 1st clock edge corresponded to the 1st buffered sample for both the analog input and period tasks.  Their data streams were in sync.  When I deployed to a system with an X-series board, the behavior changed so that the 1st period sample corresponded in time to the 2nd analog sample.  The data streams were no longer in sync.  I didn't even notice for quite a while because the discrepancy wasn't particularly obvious.

In fairness to NI, the X-series manual *does* show this difference, I just didn't go looking because I didn't expect a change..

-Kevin P

[Alexander_Sobolev]

One more difference, very weird one... very strange behaviour of Connect Terminals: see 2 options to start pulses on 2 terminals simultaneously

Hardware background: have continuously running signal (~1 kHz ). It needs to run continiously, because it is required for some equipment. I need to start data acquisition simultaneously on 2 other pieces (another NI board over RTSI and external hardware), this signal works as a start trigger.

I can not stop-start this task, so only 1) disconnect terminals; 2) start acquisition tasks 3) they wait for trigger; 4) connect terminals - tasks trigger from one edge. Perfectly works with 6602. On 6612 signals do not appear simultaneously.

Ctr2 is generating data, PFI32 is an output, RTSI6 is for another board.  PFI32-> RTSI6 static connection. When I use Connect terminals.vi Ctr2InternalOutput to PFI32, signal on PFI32 appears 30 ms later than on RTSI6.

When Ctr2InternalOutput to RTSI6 is "reconnectable" route and RTSI6 to PFI32 is static, signals on both terminals appear simultaneously. 

See example on 6612.

All connections are "green" in routing table,

Added RTSI6 -> PFI39 connection to probe on one board (does not matter)

The same with all other RTSIs.

The same on multiple boards.

PS. It is "Connected?" value change event (snippet breaks???). VI attached

And scope photo. Yellow - PFI32, Blue - PFI39 (RTSI6)

[SSPTest]

It looks as though this behavior is due to the behavior of the output buffers on the 6612. Statically connecting the PFI and RTSI lines and then dynamically connecting the RTSI line is, as you found, a way around this. Chapter 4 of the 6612 User Manual discusses exporting signals to the PFI lines and makes no mention of exporting a PFI line to a RTSI line, only the other way around.

User Manual

http://www.ni.com/pdf/manuals/374008b.pdf