DAQPad-6507 Interrupt servicing time cca. 4-10 ms??

[Janos 53]

Hi all,
can someone please confirm or deny, that interrrupt service time of my DAQPad-6507 is so long?
Does it mean that I can only measure cca. 100 Hz frequency (I intended to use it for reading out a nuclear ADC)?

I am using the device with Win2K, VC6, with the library calls shown at the end of the message.

As on the screen of the scope can be seen, after receiving a strobe signal, the data lines are not read for some time. In detail, at 20 Hz strobing freq, this time is 4-5 ms, at 200 Hz it is 4-10 ms and at 2 kHz it is cca 10 ms.

Regards

Janos


iStatus = Init_DA_Brds (iDevice, &temp);
/* Any store generates a interrupt */
iStatus = Config_DAQ_Event_Message (iDevice, 1, "DI0", 8, 0, 0, 0, 0, 0,
0, 0, (unsigned long)CallBack);
iStatus = DIG_SCAN_Setup(iDevice, iGroup, 1, portList, 0);
iStatus = DIG_Block_In(iDevice, iGroup, piBuffer, 100);
while (ulRemain > 0 && i < 100000) {
iStatus=DIG_Block_Check (iDevice, iGroup, &ulRemain);
iRetVal=NIDAQYield(iYieldOn);
i++;
}

[ThorstenRo]

Hello Janos,

The time it takes for a machine to process an interrupt is going to vary
from machine to machine. There is no way of specifying even a maximum
amount of time that it could take because something could always be done to
a computer's processor to slow it down further.

The only timing spec that we do specify for the DAQpad-6507 is that it is
capable of achieving up to 60 S/s transfer rates.

Regards

R.T.
NI Germany

[Janos 53]

Hello R. T.,

Thank you for your reply, this is the only time when I see some numbers for the transfer rate specification. I do not know why is this a secret number.

Similarly, I still did not receive a reply whether the 82C55 operates in MODE0 or MODE1. I still need to *guess* that it operates in MODE1 and waste my time with experimenting. Since servicing your device requires signals of different specification, this information, too, should be part of the specification and known *before* buying the device. DAQPad-6507 is advertised having interrupt servicing capabilities, the data sheet of its 82C55 is appended, so one can expect interrupt servicing time *orders of magnitude better*. This mode of advertising is more than misleading. We would not by the device if this would be known in advance. And, it was not only known from its spreadsheets, but we could not figure out from its docs, after buying it.

I do not completely understand your (NI) design point of view, however.

1./ The time I am speaking about, is between arrival of the STB signal and reading the input register. As far as I understood, in this period no action is required from the PC side when I start a DIG_Block_In() operation, until finished; i.e., it is the processing time of the DAQpad-6507, is not it? (BTW: my 2.8 GHz PC would not slow down any processing, I guess)
2./ Most of devices are *not* designed to hold their value for several msecs after sending a STB signal, so with such a long "interrupt servicing" time there is a chance to lose the input information. (BTW: I was always tought to exit the interrupt routine ASAP, but not to exceed 50 us)
3./ Even if the device is designed to measure up to 60 Hz, the input value measured belongs *not* to the time of STB, but some msecs later.
4./ Filtering the input (i.e. masking and comparing, etc) and making blocks of operations could be a very nice facility, but it is very annoying when I do not need it. Does the device have a mode where I can receive infinite number of inputs, signalled with STB (until disabled or stopped), one by one, without any processing?


Thanks again for replying

Janos