Hi,
Well, in nearly two weeks I did not receive any real reply to my question, so I summarize what I could find out myself. Maybe someone can use it. (This is just my guess, no one confirmed from the NI side.)
First of all, the functions listed for device "DIO-96" should be used also for DAQPad-6507, too.
I find it funny that this fact is not mentioned either in its Manual, or the device is listed under "Traditional NI-DAQ Functions Listed by Hardware Product"
Yes, DAQPad-6507 *can* use MODE1; actually it is used if you use DAQEvent = 3 through 8.
In this mode the physical interrupt is activated by the strobing signal. This fact is not mentioned at all in the manual. Even the sample program daqevt8vc.c
is misleading with its comment:
"/* DAQ EVENT 8 generates an interrupt when the data from a specified
/* digital port/line is ANDed with DAQTrigVal0 and equals DAQTrigVal1."
and
"/* You must set up your hardware so that:
/* Digital Port 0, Line 0 goes high (generating an interrupt)"
It is not so, the key is in the next line:
"/* The STB or REQ line controls how often you check the digital line"
Actually, connecting a pulse generator is absolutely needed for generating interrupts.
These pulses -and not the status change in Port0, Line 0 - cause an interrupt.
However, the interrupt handling makes a (for me unnecessary) trick:
the read value is ANDed with DAQTrigVal0 and *only* if the result is equal to
DAQTrigVal1, is the callback routine activated.
(If this were displayed either in the docs or in the sample program, I would not ask anything.)
Using the call
/* Sets up so a 1 on digital port 0, line 0 generates a interrupt */
iStatus = Config_DAQ_Event_Message (iDevice, 1, "DI0", 8, 0, 0, 0, 0, 0, 0, 0, (unsigned long)CallBack);
both the AND mask and the requested value is 0, so every STB should generate an interrupt.
Unfortunately, this unnecessarily masking and comparing does not slow down at all the interrupt servicing, because it is surprisingly slow. :-]
My experience shows that after receiving STB, the interrupt servicing *starts* minimum 4 ms (up to max 10 ms) later. (I was tought to service the interrupts ASAP, but never exceeding 50 usec; in this case the service time is about two orders of magnitude higher. Why reading out a register lasts so long...) When using >100 Hz STB, practically always 10 ms is the service time. The strobe requests received during this time, are lost.
So, I am on the way to reach even 100 Hz service speed for my nuclear ADC. Well done (?)!.
Regards
Janos