C code control of NI USB-6501 compared to NI PCI-DIO-96

[dshima]

I am attempting to port a hardware handshaking and digital I/O communication protocol (called TEMPO VideoSync) written in C from Mac OS9 (using an NI PCI-DIO-96 and NI-DAQ Version 6.1 for Mac) to Mac OSX (possibly using an NI USB-6501 and NI-DAQmx Base Version 2.0)

1.  Am I correct that the drivers and C command library for the NI USB-6501 are contained in NI-DAQmx Base Version 2.0?

2.  Does NI-DAQmx Base Version 2.0 have C commands equivalent to the following from NI-DAQ Version 6.1 for Mac used in the Mac OS9 version?
 Board_ID(slot, boardtype)
 DIG_Prt_Config(devicenumber, port, direction, mode)
 DIG_In_Port(devicenumber, port, pattern)
 DIG_Out_Port(devicenumber, port, pattern)

3.  Related to the question above, will the NI USB-6501 be controlled by the C code in much the same way the PCI-DIO-96 was?  (i.e., First the device is identified on the system, then cast the data direction of various ports and pins as either output or input, with or without handshaking, then different code sections of reading and writing on the pins per the communication protocol being used.)

4.  As a USB device, should I be concerned about the speed at which the C code can control the NI USB-6501 as compared to the NI PCI-DIO-96?

5.  I actually have an extra NI PCI-DIO-96 card, but am I correct that there is neither the driver software nor a way to use a PCI card in a OSX Mac G5 with only PCI Express slots?

Thank you very much for any advice on these matters.

Daniel Shima
Vanderbilt Vision Research Center

[Travis G.]

Hello Daniel,

There are some fundamental differences you should be aware of between the NI USB-6501 using the DAQmx Base driver with Mac OS X, and the NI PCI-DIO-96 using the Traditional NI-DAQ driver in Mac OS 9.

The NI USB-6501 uses the NI-DAQmx Base Version 2.0 for Mac OS X driver.  This driver can be downloaded here. 

The NI-DAQmx Base driver comes with its own set of C commands that use a different syntax than the old Traditional NI-DAQ commands.  These commands are more intuitively named, and contain the words DAQmxBase, i.e. DAQmxBaseCreateTask.  The NI-DAQmx Base driver installs documentation, including the NI DAQmx Base C Reference Help, along with a set of text-based example programs showing how to configure a task and channels for analog input, analog output, digital I/O, and counter operations.  Ultimately, these differences mean you will need to rewrite your C program using these new functions, but your program will still follow the basic paradigm of Create Task -> Configure Channels -> Start Task -> Read/Write -> Stop and Clear Task.

A key issue with the NI USB-6501 is that there is no buffer or clock for any type of hardware timed digital I/O or handshaking.  All digital I/O is static, or software timed.  This means that writing to digital lines or reading from digital lines is controlled completely by software commands, and each write or read operation is performed with an individual command.  The result is that the NI USB-6501 does not support any of the handshaking or strobed (hardware timed) digital I/O functionality of your PCI-DIO-96.

Because of the software timed nature of the NI USB-6501, the actual execution time of your digital I/O operations is completely dependant on the ability of your system to read and write commands over the USB port.  Because of the differences in performance between customer systems, there are no concrete specifications for speed of digital I/O operations.  Depending on your application, you should probably be alright, but its important to note that limits exist and that they are dependant on the specs of your computer.

Finally, there is no way to use a PCI card in a PCI Express slot.  We have recently added Mac OS X support under NI-DAQmx Base 2.0 for our PCI Express M-series cards (NI PCIe-625x).  You should submit a product suggestion at www.ni.com/contact for further requests.

I hope this helps and feel free to reply with any further questions.

Regards,
Travis Gorkin
Applications Engineering
National Instruments
www.ni.com/support

P.S. Go Dores!!!

[dshima]

Dear Travis,

Thank you very much for answering all the questions in my first post.  At this point, based on your feedback about the NI USB-6501 lacking a buffer or clock, I am trying to figure out if the TEMPO VideoSync routine I am porting from Mac OS9 to Mac OSX is really hardware timed or actually software timed.

I described it in my first post as a "hardware handshaking and digital I/O communication protocol" ignorant of what that implied and merely to describe the nature of the C-code as a general back-and-forth communication between two computers.

As I attempt to get in touch with the person who wrote the TEMPO VideoSync routine to ask, I thought I would also post two files here on the NI forum in case it was easy for you to tell from the code whether it is hardware or software timed.  Here is a quick description of the two attached files:

1.  RVS_forNIboard.c - the C-code for the Matlab MEX-file that contains the TEMPO VideoSync routine, uses previous NI commands like DIG_In_Port() and DIG_Out_Port() to read bits on certain input ports for handshaking status such as S_RESET or S_RTS and on other input ports for incoming information bytes, and to set handshaking bits on output ports to R_RESET, R_CTS, or R_ACK status.

2.  RVS_forNIboard_M.txt (should be called RVS_forNIboard.m) - a higher-level M-code Matlab file that does the same TEMPO VideoSync routine, calls other M-files that eventually use smaller MEX-files that contain the same NI commands, included just because it is easier to view and understand the whole routine within the one main while-loop.

I have a feeling that it is a software timed routine because it matches your description of "writing to digital lines or reading from digital lines is controlled completely by software commands, and each write or read operation is performed with an individual command."

I also have a recollection that the routine only works as a Matlab MEX-file compiled from the C-code above because, when run as Matlab M-code, it would fail due to, I suppose, certain timeouts programmed on the other side.  But that does not mean it is hardware timed, right?  Would the code look much different if it did, as you said, use "the handshaking or strobed (hardware timed) digital I/O functionality of the PCI-DIO-96?"

Thank you again for any feedback on this matter.  Looking forward to your reply.

Daniel Shima
Vanderbilt Vision Research Center

Message edited by moderator to remove 2 proprietary files:
RVS_forNIboard.c (12 kb)
RVS_forNIboard_M.txt (3 kb)

Message Edited by Nick C on 08-23-2006 03:51 PM

[GDE]

Daniel,

Just thought I would throw in my 2 cents. The PCI-DIO-96 doesn't support hardware timed DIO, its a purely software timed board. So if indeed all you are doing is read a port and then write to a port, you should be just fine. I do believe the DIO-96 has some extra handshaking capabilities that the USB device wouldn't, but you would probably know if you using that feature. I would still recommend checking with the indivdual that wrote the progam, as you are, to make sure you aren't using any of those extra handshaking capabilities. But as for the hardware vs software, don't worry, you couldn't have been doing hardware timed stuff. Hope that helps.

-GDE

[dshima]

GDE,

Your 2 cents are much appreciated.  Thank you for indicating that PCI-DIO-96 does not support hardware-timed DIO.  That supports my conclusions from Travis' feedback and examining the old code that the existing TEMPO VideoSync routine is software timed.

As for whether or not the TEMPO VideoSync protocol uses the handshaking capabilities of the PCI-DIO-96 (capabilities not possessed by the USB-6501), I believe I have found a definitive clue in the initialization section of the old code:

error = DIG_Prt_Config(deviceNumber, port, direction, mode)

There are four calls to the above NI command in the old code and, in all cases, the value of "mode" is 0, meaning no handshaking on any of the ports as far as the PCI-DIO-96 is concerned, even for the two ports described in the code comments as "handshaking" lines where status messages like CTS, RTS, ACK, and RESET are posted on both sides.

So would you agree that it appears that the handshaking capabilities of the PCI-DIO-96 were not being used and that the USB-6501 would not be lacking in that sense?

I am not forgetting Travis' other comment that there might still be issues concerning the speed at which my system can read and write commands over the USB port.  If read and write commands are again issued to the ports within compiled C-code, I suppose the comparison is between a PCI-card installed on an old Mac G3 and a USB 2.0 device on a brand new Mac G5.  Not sure if one needs to calculate a value of MHz, Mb/s, or both?  And guessing that the particular C-compiler and interface make a difference too.

I have a feeling that the USB-6501 will be just fine, but admittedly I do not know at the moment how to make that comparison calculation or what the TEMPO VideoSync routine actually requires.  So I will also ask that to the TEMPO VideoSync protocol designer as well.

If you have another moment, please let me know if you agree with my most recent observations and if you have additional feedback.  Thanks again for the help.

Daniel Shima
Vanderbilt Vision Research Center

[GDE]

Daniel,

I agree with your assesment, it doesn't look like you are doing any special handshaking specialized to the DIO-96 board. So I would agree that the USB-6501 will most likely be more then sufficient to handle your needs. The only other thing that the DIO-96 has is just more DIO ports (96 vs 24), but I am sure you know this already and is not an issue. Definitely check everything out with the orginal developer, but sounds like you will be just fine. Good luck with the project.

-GDE

[dshima]

GDE,

Yes, the physical connection for this TEMPO VideoSync protocol definitely involves exactly 24 digital bits (and 1 ground wire), but I am glad you asked because I realized something just now that I had not before.

error = DIG_Prt_Config(deviceNumber, port, direction, mode)

I had mentioned before that the above NI command (from NI-DAQ Version 6.1 for the PCI-DIO-96) is called 4 times during initialization, and, more specifically, it is called to configure 3 ports as input ports and 1 port as an output port, with physical wiring as follows:

 Input 1 port: use all 8 bits
 Input 2 port: use all 8 bits
 Input 3 port: use lowest 4 bits
Output 1 port: use lowest 4 bits

But I read the following in the USB-6501 data sheet that may once again put me in the clear (though it may mean that porting the code will involve a little bit more than just updating the key National Instrument C-language commands to NI-DAQmx Base Version 2.0):

It reads: "The 24 digital lines, P0.<0..7>, P1.<0..7>, and P2.<0..7> comprise the three DIO ports...  Each of the USB-6501 DIO lines can be individually programmed as a DI or DO line."

Do you agree that I can breathe a sigh of relief and simply plan to use P0.<0..7>, P1.<0..7>, P2.<0..3> as inputs, and P2.<4..7> as outputs?

Thanks once again for your feedback.

Daniel Shima
Vanderbilt Vision Research Center

[GDE]

Daniel,

You are correct, you can have the port split up any way you wish so that some channels are inputs and some are outputs. So your configuration will be just fine.

-GDE

[dshima]

I received my response from the designer of the TEMPO VideoSync protocol and was advised to ask whether or not the USB-6501 is able to read and write to multiple bits simultaneously?  By that I mean read any of the following simultaneously: all 8 bits of port A, or all 8 bits of port B, or the 4 bits of port C configured as input bits.  And write simultaneously to the other 4 bits of port C configured as output bits.  I suspect the answer is yes.

In the previous programming of the PCI-DIO-96, the following commands obviously read and wrote digital words in the parameter "pattern" and did not operate on individual bits:

DIG_In_Port(devicenumber, port, pattern)
DIG_Out_Port(devicenumber, port, pattern)

While looking at examples readDigPort.c and writeDigPort.c gives me confidence that equivalent commands exist for the USB-6501 in NI-DAQmx Base Version 2.0, I am wondering how things are coded differently when the bits of a single port are split between input and output as I describe for port C?

Possibly a modification to the lines with the DAQmxBaseCreatDIChan() or DAQmxBaseCreatDOChan() command, specifically to the "DAQmx_Val_ChanForAllLines" flag which seem to make the sample programs read or write to all lines on the channel for "Dev1/port0"?

Daniel Shima
Vanderbilt Vision Research Center

[Travis G.]

Hello Daniel,

You should have no problem reading/writing to individual lines or grouping lines together on the same port using the NI USB-6501.  When you configure your channel using the DAQmxBaseCreateDIChannel (or DOChannel) function, you will pass the range of lines for the task as Dev1/port0/line0:3 to read or write from lines 0 through 3.  You will still use the DAQmxBaseReadDigitalU8 (or WriteDigitalU8) function and write 8 lines of data, but the task will just mask the lines that are not configured in the task.  See the DAQmx Base 2.x C Function Reference Help for more information on the individual functions used.

Regards,
Travis G.