Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Interrupt handling with DAQpad-6507

Hi,

I would like to use NI DAQpad-6507 device for driving an ADC. The ADC puts 13 bits of information in 8255 registers A and B, furthermore a strobe signal in register C. I would like to receive an interrupt (or event) when the strobe signal arrives.

The first difficulty is that my device is not listed at all in "Traditional NI-DAQ Function Reference Help" under "Traditional NI-DAQ Functions Listed by Hardware Product". Am I looking at the right document?
Is there some other device which (at API level, at least) is functionally equivalent with my device?
Can I find out somehow (other that trial and error) which functions work with my hardware?
( definitely found that group-ing is not supported by my hardware )

Partly, I c
an handle the device: I can use DIG_Prt_Config() and DIG_In_Prt(), so in Mode 0 I can read the contents of the registers of the ADC. Probably the same way I could set Mode 1 and see if the strobe signal arrives.

I guess that a function like Config_DAQ_Event_Message() is what I need. However, it looks like (from the definition "Notifies Traditional NI-DAQ applications when the status of an asynchronous DAQ operation (initiated by a call to DAQ_Start, DIG_Block_Out, WFM_Group_Control, and so on) meets certain criteria you specify.") that it works only with asynchronous DAQ operations only. What I want is just to enable the ADC and receive interrupts until I disable the ADC. Can I do this with the present library?

I also read: "Certain DAQEvent options are best suited for low-speed transfers". What does it really mean? What frequency can I reach in this way?

Thanks for your help in advance.

Janos Vegh
0 Kudos
Message 1 of 5
(4,058 Views)
Hi Janos,

The DAQPad-6507 is a DIO-96 device. In the Traditional DAQ Function Reference Help it is not listed with it's own number, there is only one link for the "DIO-24 and DIO-96" devices.
You should be able to use all the funtions listed there.

I would recommend starting with some digital IO examples. There are many shipping examples that come with any National Instruments application development environment. In case you are using some other compiler, you should focus on the CVI exmaples that can be downloaded from zone.ni.com. With those you can have a look a the C source code and get an idea of the correct funtion calls at least.

From the help file:
"Certain DAQEvent options are best suited for low-speed transfers, because they require the pr
ocessor to examine each data point as it is acquired or transferred. These options include DAQEvents 3 through 9. You cannot use DMA for these options, and the processor has to do more work. The processing burden increases in direct proportion to the speed of the asynchronous operation."

This means the speed you can really reach depends on your application and on the computer you are using. So you can only try it yourself.

Regards
Richard H.
National Instruments
0 Kudos
Message 2 of 5
(4,057 Views)
Hi Richard,

thanks for your reply.
Yes, the DIO-96 was also my bet for a similar device.
However, I did not find the link your mentioned, so I was not sure if they are really identical (from my point of view).

I think it would be useful to mention in the "DAQpad-6507/6508 User Manual" that the device is functionally equivalent with DIO-96. DIO-96 is only mentioned on page 1-1.

Now, I hope I can solve my task with using

DIG_SCAN_Setup and Config_DAQ_Event_Message

BTW: If possible, I prefer to use C++ classes for handling the devices. I planned to develop a class for my ADC.
1./ Do you have C++ API for DIO-96? (at least the callback)
2./ Can the library use somehow a class member function as callback function (I mean Config_DAQ_Event_Mes
sage)?
(I must have at least 2 ADCs)

Thanks again for the help.
Regards

Janos
0 Kudos
Message 3 of 5
(4,057 Views)
Hi Richard,

in the meantime I studied the available options, functions and parameters, and also found sample program 'daqevt8.c' . From the input pins used there I *guess* that MODE1 of the 8255 is set through using parameter 8. However, in the docs at 'event mode 8 (digital pattern matched)' both DAQTrigVal0 and DAQTrigVal are used (at least according to "Usable Parameters for DAQEvent = 5 to 9:" ), which suggests MODE 0. In the sample program both of them are set to 0, which again suggests that these parameters are ignored so that the 8455 is in MODE1.

Then, in the sample program the line

DIG_SCAN_Setup (DEVICE, GROUP, 1, port_list, 0);

suggests again Mode 0.

Could you please confirm if 8455 is in MODE1 when using DAQEvent = 8 and explain
what DAQTrigVal0 and DAQTrigVal mean if they are really used?

BTW: Since the user's manual details the modes of operation of the 8255, I expected that the manual contains this important information. I understand that in order to have a unified API you needed functions having list arguments, etc, but the way as they are documented is a little bit confusing.

Thanks for your help in advance

Janos
0 Kudos
Message 4 of 5
(4,057 Views)
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
0 Kudos
Message 5 of 5
(4,057 Views)