From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Driver Development Kit (DDK)

cancel
Showing results for 
Search instead for 
Did you mean: 

XSeries MHDDK questions

Solved!
Go to solution

I have been reviewing the XSeries MHDDK documentation and examples as I figure out how I can use the PCIe-6363 to replace 

the venerable PCI-6071 (PCI-MIO-16E1) in our in-house data acquisition application.  Naturally, questions arise...

 

1) Questions about the EEPROM calibration data -- http://forums.ni.com/t5/Driver-Development-Kit-DDK/Calibration-data-in-X-Series-EEPROM/td-p/1632108.

 

2) Does the X-Series boards have an undocumented "ghost" channel feature, as is present on the E-Series? With this AI configuration FIFO feature, you

tell the AI subsystem to take a sample but discard it (don't put it in the data FIFO). This was very handy for our particular application, in which we had to

sample all channels as "simultaneously as possible" once per millisecond, while also sampling a single channel every 40 microsecs. This was easy to setup

with the ghost channel feature, and no unwanted data was pushed into the FIFO. Just curious....

 

3) On waiting for timing subsystems and counters to "arm": Throughout the examples, after arming a timing engine or counter, the code "spins" waiting for

that timing engine or counter to enter the "armed" state (by polling the relevant status register). The code waits up to 5 seconds before "timing out". Can the

AI and DI timing engines and the Gi counters really take that long to enter the "armed" state -- particularly if we're arming them via a device register write

(not an external signal)?? I would prefer to use a MUCH shorter timeout, on the order of 100-300 microseconds (our application runs under RTX, so it is

easy to do short "spins" like that)......

 

4) Among the possible SOURCE signals for the Gi counters are the internal timebases, TB1 - TB3. I've figured out from one of the examples that TB3=100MHz.

Is TB1=100KHz and TB2=20MHz?

 

5) Our application needs to timestamp rising-edge transitions on any of 16 digital inputs. I plan to use the DI subsystem and the change detection circuitry in

concert with the G0 counter, which will simply count edges on the 100KHz timebase to maintain the timestamp. I'll use the Change-Detect signal to sample

both DIs and counter value, pushing them into their respective FIFOs. I just need to synchronize the starting of the DI timing engine and G0, when I strobe the

DI_START1 trigger via a register write. My approach is to enable the hardware arm trigger for G0 and use the DI_Start1 trigger as its source:

Gi_HW_Arm_Enable=1 and Gi_HW_Arm_Select=HwArm_DI_Start1 in the G0_Counting_Mode_Register. Is this a valid way to sync the start of the DI and G0

subsystems? I'm asking mainly because the XSeries User Manual doesn't mention that the DI_Start1 trigger can be used to arm the Gi counters...

 

Thanks in advance for any answers you can provide.

 

Scott

 

0 Kudos
Message 1 of 4
(7,157 Views)

Hi Scott,


A ghost feature does still exist for the X-Series boards but the enumeration was not made public. For AI_Config_Channel_Type use 7 for the ghost. Be sure however to specify Bank 0 and channel 0 to take the ghost sample.


As for the timeout on the counter arming. We use the 5 seconds to timeout as just an example, but the counter itself should arm in a few microseconds. If it doesn't then the board probably has lost communication. Therefore the shorter timeout of 100-300 microseconds should work just fine. There is an exception where if you are using an external source for the counter the timeout will depend on the frequency of the source, the hardware requires about 3 ticks of the source to propagate a level change.


For the TB values. TB1 = 20 MHz, TB2 = 100kHz, and TB3 = 100Mhz.


For using the HWArm_DI_Start1 as the G0 Arm, I see no reason why the route could not be used. There is a direct route internally for the DI_Start and G0Arm

 

Regards,

Chris T.
Message 2 of 4
(7,024 Views)

Hi, Chris --

 

Many thanks for your reply. I actually answered most of the questions by just trying things

out and discovering that they worked. Still, thanks for the details about TB1-3, the time it

takes a counter to arm, etc.

 

One more question: For the ghost feature, you state that I should "specify Bank 0 and channel 0

to take the ghost sample". Currently I use bank 0 and channel 15, and I haven't had any problems --

although I haven't done thorough testing yet. Is there a reason I should specify channel 0 for the ghost?

 

Thanks again,

 

Scott Ruffner

0 Kudos
Message 3 of 4
(7,017 Views)
Solution
Accepted by topic author sar
Hi Scott,

Channel 0 is considered best practice. While the other channels may work there is no guarantee with other devices.

Hope this helps!

Regards,
Chris T.
0 Kudos
Message 4 of 4
(7,010 Views)