Interrupt driven high speed digital i/o with 256MB onboard memory support

[pranav]

Dear Travis and Kevin,

After reffering various avialable sources, I found and understand that change detection output can be used for both DMA and Interrupt driven data transfer depending upon which card you are preferring. For example both 6509 and 6259 are supporting change detection but as 6509 supports only static DIO, the output of the change detection can be used only in Interrupt mode to trigger the execution of interrupt service routine. However in 6259, output of change detection can be routed to DI Sampel clock etc. in which DMA transfer takes place. Important point in this case is that no user specific(custom) operations can be performed other than data in or out. Where as in case of interrupt transfer, user defined code can be executed in ISR but at slow rate. I may be wrong!!! please comment.

But I would like to ask one more question related to our other application. Is it possible to use 6509 in change detection mode to handle (i.e. without loss)28 bit pattern incoming at the rate of only 5Hz/second, if the host computer is also doing some general purpose work simultaneosly during acquisition ? I am aware that 6509 does transfer the data in static way so it is not deterministic. but any estimate ? I would also want to take windows time-stamping at each change detection event to record time interval between two pattern.

regards

Pranav

[Travis G.]

Hello Pranav and Kevin,

What you've both said is basically correct, and the statement in my earlier post about the change detection event on an M Series device transferring data to system memory using interrupts is incorrect.  To clarify, there are two ways to use the change detection signal on an M Series device.

1. The change detection event signal can be routed in hardware to be used as a sample clock for a digital or analog task. 

On an M Series device, which has the capability of performing correlated DIO, the data clocked into the device with this change detection event signal is buffered and transferred to system memory using DMA transfers.  This is programmed in LabVIEW by using the Change Detection instance of the DAQmx Timing VI, as shown in the block diagram on the previous page. 

2. The change detection event signal can also generate an interrupt, which can be handled as an event or callback in software.

Using this method, the change detection interrupt can be handled by an event structure in LabVIEW and cause a user-defined block of code to be executed.  The rate at which these interrupts can be handled is limited by how fast your system can service the interrupt and execute the code, so this is much more system dependant.  There are example programs that show how to program this, just search for DAQmx Events.

Pranav, regarding your last question about using the second method with an NI-6509 to detect changes occuring at 5Hz, im pretty sure that this is possible.  I've talked to some people who have tried this out and they were able to handle change detection events in software occuring at a rate of up to around 1kHz.  However, based on what you've told us of your application, I would recommend using the first method with a PCI or PCIe M Series device.

I hope this helps,

Travis G.

Message Edited by Travis G. on 03-09-2007 11:39 AM

[pranav]

Dear Travis, hello once again after long time.

Reffering to point-2 of your reply, that is export of change detection signal to PFI line. I would like to know whether export of change detection signal to PFI occurs after a bunch of 26 Data lines are read or before ? This is because we can reset our ADC only after data are read on line D0-D25 otherwise data will be lost before they are read.

Any solution, if it is "before" ?

Regards

Pranav

[pranav]

Dear Travis,

My previous post is reffered to the message no 12, on page -2,  which contains VI dia gram.

Pranav

[Travis G.]

Pranav,

Lets take look at the Appendix B: Timing Diagrams section of the M Series User Manual.  These diagrams illustrate the timing delays as signals propagate from external pins on the DAQ device through the internal circuitry.  Figure B-38: Digital Waveform Acquisition Timing Delays is the diagram your most interested in.  Although this timing diagram is for a sample clock based digital input operation, the change detection circuitry will be generating the DI Sample Clock so the P0 to P0i and DI Sample Clock to PFI (output) delays still apply.  From this diagram, after accounting for all input and output delays it looks like the change detection event will reach the external PFI line several nanoseconds after the digital input circuitry sees the data from the digital lines. 

I hope this helps,

Travis G.

[pranav]

Thanks Travis, for the reply. From timing diagram, the time delay between DI sample clock rising edge (where data are read) and PFI output is t8. I hope this will be sufficient in our application. However, in the worst case if above scheme does not work, I have planned to put a D-type Latch on the data lines to hols the data even if ADC is reset 'early' by 6259.

Regards,

Pranav

[Kevin_Price]

Just stumbled back upon this thread and noticed fairly recent activity.  Just thought I'd suggest a possible workaround if you need a delay that's bigger than the nanosec realm you get from the hardware.  Rather than route the change detect signal to PFI for *direct* use by some other task, route it to a counter that's configured for retriggerable single pulses.  (This assumes you bought an M-series board like the 6259).  Then let the other task use the counter's output, whose delay and duration you can control.

There should be a shipping example for generating a retriggerable pulse.  Be aware that you may need to set "low time" equal to "initial delay" to get consistent behavior for all triggers.  See this KB article.

-Kevin P.

[pranav]

Thanks kevin. This is also a good idea.