Fedora 7 NIDAQmx installer

[ninevoltz]

Attached you will find a shell script to install NIDAQmx on Redhat Fedora 7.

My recommendation is to install Fedora 7 using the KDE LiveCD then run the script. It will do all of the work for you.

Post back with any complaints, questions, or suggestions.

John

[ninevoltz]

Here's the modpost patch for kernel 2.6.21-1.3228.fc7

[PatFord]

I was able to using this script with a few minor changes to get the software installed on a Mandriva 2007 system. I'll post the modified script asap.

Thanks Ninevoltz!

Pat

[ninevoltz]

Here is the modified modpost binary for 2.6.22.1-27.fc7. The "short compile" trick I discovered does not work anymore with 2.6.22. You need the entire kernel source package if you want to compile modpost yourself. This binary was built for i686. I also am including a patch for modpost if you need to build your own.

Just drop it in your kernel-devel directory as such:

cp modpost /usr/src/kernels/$(uname -r)-$(uname -m)/scripts/mod

Then run updateNIDrivers

[JohnNavratil]

Ninevoltz,

Would you do me the favor of testing examples/ansi_c/Events/Signal/ChangeDetection/ReadDigChan-ChangeDetectionEvent on your system?  I believe my Fedora 7, 2.6.21 kernel should be similar to yours, although I gather you are running 2.6.22, now.

I've connected pins on port1 to port0 and am using the test panels to generate events on port0 by setting port1 to all output and toggling values on the port.  The behavior of the application, as provided by NI, is to generate output every fourth value change.  That is, toggle bits as desired, but only every fourth toggle generates output from the test program, but then four lines of output are generated displaying the bits as they were changed.

I've monkeyed with the program and can't seem to get it to behave.  It doesn't appear that any samples are available for reading until after the fourth event.  Not being familiar with the internal architecture of nikal.c and the patches, I'm trying to isolate the kernel patches as a source of the problem.

If this is an imposition, please feel free to decline my splendid offer 🙂

Thanks!

-- John Navratil

[Tom_W_[DE]]

Hey John-

You don't mention which hardware you're using, but I'll assume it is an M Series 62x1 or 62x0.  The reason for that assumption is that those devices feature 8-bit digital ports for change detection.  The likely reason you're seeing this behavior is that the device waits to buffer 32-bits of data for DMA transfer, so it takes 4 events to buffer enough data from the port. 

One suggestion to get data back on each event would be to use interrupt-driven transfers rather than DMA.  This will most likely decrease your performance slightly, but it will provide on-demand transfers.  This can be accomplished via a call to DAQmxSetDIDataXferMech() to set the transfer mechanism to DAQmx_Val_Interrupts (10204).

EDIT: BTW- if this is indeed the issue, it is not specific to Linux.  This behavior is dictated by the device and would also occur on Windows or any other platform.

Message Edited by Tom W [DE] on 07-25-2007 10:22 AM

[JohnNavratil]

Tom,

You assume correctly, I am using the 6221.  Thanks for the 'DAQmxSetDIDataXferMech()' tip.  Would you mind posting the documentation to this call and the C Reference Help html which I got from the NIDAQ800_Redhat.iso doesn't list this function.  I can link to it, but I don't know what the third ('data') argument should be.

Alternatively, you could point me to an updated C Reference Help file.

Thanks,

-- John Navratil

[Tom_W_[DE]]

Hi John-

Here's the documentation for that function:

----------------------------------------

Digital Input >> General Properties >> Advanced >> Data Transfer and Memory >> Data Transfer Mechanism

Data Type:	int32
Description:	Specifies the data transfer mode for the device.

Valid values

DAQmx_Val_DMA	10054	Direct Memory Access. Data transfers take place independently from the application.
DAQmx_Val_Interrupts	10204	Data transfers take place independently from the application. Using interrupts increases CPU usage because the CPU must service interrupt requests. Typically, you should use interrupts if the device is out of DMA channels.
DAQmx_Val_ProgrammedIO	10264	Data transfers take place when you call an NI-DAQmx Read function or an NI-DAQmx Write function.
DAQmx_Val_USBbulk	12590	Data transfers take place independently from the application using a USB bulk pipe.

You can get/set/reset this property using:

  DAQmxGetDIDataXferMech

  DAQmxSetDIDataXferMech

  DAQmxResetDIDataXferMech

-----------------------------

A call to set this property would look like:

DAQmxSetDIDataXferMech(taskHandle, channelName, DAQmx_Val_Interrupts);

where taskHandle is the task handle associated with the task of interest and channelName is the channel name you assigned (or "") in DAQmxCreateDIChan()

[JohnNavratil]

Thanks, Tom!

Works like a champ!  I appreciate the help.  Just a thought...  Should this go into the example program?

-- John Navratil

[Tom_W_[DE]]

Hi John-

Thanks for the feedback- I would prefer to leave the example as-is because it shows the best method performance-wise.  I do agree that we should document this behavior; I'll request that an online KnowledgeBase entry be created.

Thanks again-