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

Discussion:

(too old to reply)

dshima

2006-01-17 00:10:54 UTC

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 ShimaVanderbilt Vision Research Center

Travis G.

2006-01-18 00:41:21 UTC

Permalink

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 <a href="http://www.ni.com/support/daq/versions_portable.htm#du" target="_blank">here</a>. 

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 <a href="http://www.ni.com/contact" target="_blank">www.ni.com/contact</a> 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

2006-01-19 01:41:16 UTC

Permalink

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 ShimaVanderbilt Vision Research Center

RVS_forNIboard.c:
http://forums.ni.com/attachments/ni/70/4296/1/RVS_forNIboard.c

RVS_forNIboard_M.txt:
http://forums.ni.com/attachments/ni/70/4296/2/RVS_forNIboard_M.txt

GDE

2006-01-19 22:42:53 UTC

Permalink

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

2006-01-20 01:41:24 UTC

Permalink

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 ShimaVanderbilt Vision Research Center

GDE

2006-01-20 15:41:03 UTC

Permalink

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

2006-01-21 01:11:02 UTC

Permalink

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 bitsOutput 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 ShimaVanderbilt Vision Research Center

dshima

2006-01-26 05:42:52 UTC

Permalink

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 ShimaVanderbilt Vision Research Center

Travis G.

2006-01-31 22:41:23 UTC

Permalink

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 <a href="http://digital.ni.com/manuals.nsf/websearch/DD23E630A565CD65862570B20074AAAC" target="_blank">DAQmx Base 2.x C Function
Reference Help</a> for more information on the individual functions used.

Regards,

Travis G.

dshima

2006-02-22 01:40:56 UTC

Permalink

I received my NI USB-6501 recently and so far, so good.  I am able to make and run the NI-DAQmx Base dio example, readDigPort.  Just two simple questions:
 
1.  Is it normal for the green LED on the NI USB-6501 to be blinking steadily at about 2 Hz all the time regardless of whether or not a program is communicating with it?  I noticed this when plugged into an older PowerBook G4 and a brand new Power Mac G5.
 
2.  When running the readDigPort example, is it normal for the DAQmxBaseCreatTask command to take a long time?  About 11 or 12 seconds on the PowerBook G4 (667 MHz, 512 MB SDRAM) and about 5 or 6 seconds on the Power Mac G5 (Dual 2.3 GHz, 1 GB SDRAM).  All other commands that follow in that example seem to execute very rapidly.
 
Daniel ShimaVanderbilt Vision Research Center

Sileas

2006-08-04 11:40:10 UTC

Permalink

I've looked at the C manual, but it is not really helping.  This is what I want to do, and it doesn't seem to work:
With the 6501, I need to put single bit signals out on the ports (about 12 lines), and read one bit in.  The bit I am reading in is actually just a continuity check and should just be a readback of one of the output bits.  I need to do bitwise addressing, so I wrote functions to read the ports in, do a logical and / or, then write the ports back out.
This is my setup:
 char chan0[] = "Dev1/port0"; char chan1[] = "Dev1/port1"; char chan2[] = "Dev1/port2";
 DAQmxBaseCreateTask("",&taskHandle); DAQmxBaseCreateDOChan(taskHandle,chan0,"",DAQmx_Val_ChanForAllLines); DAQmxBaseCreateDOChan(taskHandle,chan1,"",DAQmx_Val_ChanForAllLines); DAQmxBaseCreateDIChan(taskHandle,chan2,"",DAQmx_Val_ChanForAllLines);
These are my read / write functions (they are bit funny since I use them at a higher level to do bitwise reads / writes):
int write_dio(unsigned char port0_data, unsigned char port1_data, unsigned char port2_data){  int32 written; int32 return_val; unsigned char port_data[3];
 port_data[0] = port0_data; port_data[1] = port1_data; port_data[2] = port2_data;
 return_val = DAQmxBaseWriteDigitalU8(taskHandle,1,1,10.0,DAQmx_Val_GroupByChannel,port_data,&written,NULL); return return_val;}
int read_dio(unsigned char *port0_data,unsigned char *port1_data,unsigned char *port2_data){  int32 read; int32 return_val; unsigned char port_data[3];
 return_val = DAQmxBaseReadDigitalU8(taskHandle,1,10.0,DAQmx_Val_GroupByChannel,port_data,3,&read,NULL);
 *port0_data = port_data[0]; *port1_data = port_data[1]; *port2_data = port_data[2];
 return return_val;}
I really don't understand how channels are written / read when there is no channel parameter in the read / write functions.  If possible, I'd like to set each line to be a channel, and then just write each one individually, but it looks like I have to write at least 8 bits at a time since the function writes to 8 bit ports.
I have not used any LabView stuff before, and am doing this only in C (on Linux), so maybe my unfamiliarity with LabView is an issue.  Also, is there a better primer for the C interface than just the API reference?  It really doesn't help much with concepts, like tasks.  Can't I just address the pins directly for reading and writing without setting up tasks?
Thanks,
David
 
 

Jesse O

2006-08-07 17:40:12 UTC

Permalink

Hello Sileas,

I have taken a look at your code below, and I have a couple
comments.  First, you are creating tasks
for port0, 1 and 2 on your USB-6501. 
This means that each task will have 8 lines you are writing to. When you
create a task you are given a handle to that task.  When you want to perform a read or write to a
specific port you need to send the DAQmxBaseWriteDigitalU8 or the
DAQmxBaseReadDigitalU8 the taskhandle you created before.  The task handle is how you reference the
channels, since you added the channels to that task.In your case it seems that you are read and write tasks are separate,
so you might want to create two or three tasks (one for reading and one/two for
writing data).

You also mentioned that you wish to read and write to a
single bit.  In DAQmx and DAQmx base
these bits are called lines.  You can
specify a single line when you create your DO or DI channel by adding some
extra information to your channel string. 
For example below you specify char chan0[] =
"Dev1/port0";  instead you
could use char chan0[] = "Dev1/port0/line0";  or chan0[] = "Dev1/port0/line0:1"
for lines 0 and 1.

This information is given in the manual.  If you look under the DAQmxCreateDOChan help
under the lines parameter you will see the following description:  "The names of the digital lines used to
create a virtual channel. You can specify a list or range of lines such as the
following: Dev1/port0:1 or Dev1/port0,Dev1/port2 or Dev1/port0/line0:4 "

The help file, along with the examples that ship with
daqmxbase are the best resource for information.  The examples are typically located under
/usr/local/natinst/nidaqmxbase/examples/

Regards,

Jesse O.Applications EngineeringNational Instruments

Message Edited by Jesse O on 08-07-2006 12:30 PM

Sileas

2006-08-13 07:10:07 UTC

Permalink

Thanks for the comments, but I am still quite confused as to how a 8 bit read / write function is supposed to address individual bits (or lines).  I would have expected the read / write functions to use some sort of channel handle, but instead they have task handles. 
 
Tell me what happens in this case:
 
I set up a task and three output channels.  The 3 channels are Dev1/port0, Dev1/port1/line0:3, and Dev1/port2/line1
 
Say I want to write a "1" Dev1/port2/line1 (i.e. channel 3) - what do I do?  What about writing to just the 4 lines of port 1 (i.e. channel 2)?
 
Looking at the writeU8 function, it has "samples per channel", which appears to be how many different samples in time to write, which doesn't help.  The "writeArray" (which is an array of unsigned chars) is how I put my data in to the function, but how is that arranged?  Is is packed, or per port?
 
Example:  Write 0xAA to Channel 1, 1111b to Channel 2, and 1 to Channel 3. 
Is writeArray = 0xAA 0x0F 0x01, one byte with the appropriate bits filled in?
Is writeArray = 0xAA 0x1F, meaning packed (i.e. there a a total of 13 bits across 3 channels, so put their values in an array large enough to hold 13 bits)?
 
Same thing for reads.  What if I have defined two input channels, say one on Dev1/port0/line0 and Dev1/port0/line1? When I read, do I get both back in a single byte, line 0 in bit 0 and line 1 in bit 1, or do I get two bytes, with line 0 in bit 0 of byte 0 and line 1 in bit 0 (or 1?) of byte 1?
 
Also, I am very concerned that if I want to just write an individual line on a port that the other lines do not get affected.  I am controlling lines for relays to test equipment and momentary glitches on lines I am not intending to write could be very bad for the setup.
 
The documentation, which is just an API description (which does not constitute a real help file, with concepts, explanations, examples, etc.) does not go into this.  Neither does the example code, which is very simple reading a writing of entire ports, and not lines.  I would expect many people to be interested in reading and writing lines.  Is there not a "programming manual" somewhere that explains all this?  If I can't address my individual channels in reads and writes, then what is the point of having them?  Shouldn't I just work with tasks only, and just make a single channel per task?
 
Again, forgive me if I seem to not understand how all this works, as I have never used LabView.  I assumed that the USB-6501 module would allow me to do bit (line) level access from C in a very straightforward manner (like just reading / writing bits directly, or at least ports directly like a microcontroller), but apparently it is intended more for someone familiar with LabView.
 
 

Jesse O

2006-08-14 20:10:13 UTC

Permalink

Hello Sileas,

I'm sorry you have been having problems setting up your application. 
Unfortunately I need to clarify something from my last post.  Although you
can create a channel for Dev1/port1/line0:3 for the 6008/9 and 6501 you need to
use port operations in DAQmx Base.  Therefore when you create a channel
for dev1/port1 you send an 8bit (or 32) value to the device.  Each of the
least significant 8 bits corresponds to one line.  Therefore to send a
value to port1/line0 you would send a 0 or 1.  To send a value to
port1/line3 you would send 0 or 4.  To set port1/line0, port1/line1, and
port1/line2 all to high you would send 7 to the channel. 

So the easiest way to control two output ports and one input port is to create
three tasks. 

For example if you had the following code:

uInt32      w_data [1];
int32       written;

w_data[0] = 0x07;

DAQmxErrChk (DAQmxBaseCreateTask ("", &taskHandle));
DAQmxErrChk
(DAQmxBaseCreateDOChan(taskHandle,"Dev1/port1","",DAQmx_Val_ChanForAllLines));
DAQmxErrChk (DAQmxBaseWriteDigitalU32(taskHandle,1,1,10.0,DAQmx_Val_GroupByChannel,w_data,&written,NULL));

You would write to update all 8 lines of port1.  Lines 0, 1 and 2 would be
high and the rest would be low.  Unfortunately, since you are limited
to port operations when you update port0/line0 you could change
port0/line1.  To get around this you will want to keep the last value you
wrote in memory and only change the bit you need to update on the device. 

However if you create two tasks for your digital output, when you update task 1 it
will not change the digital lines associated with task 2.

With regards to your sample pre channel question, the samples per channel you
will specify a value of 1.  The value you write will stay on the port until
you update the port. 

The same logic applies for
digital input, where each line corresponds to a single bit in the returned
number.

I again apologize for any confusion you have.  The documentation available
is the function reference you have already seen, shipping examples, discussion
forums, and possibly more online examples (found <a href="http://www.ni.com/devzone/dev_exchange/ex_search.htm" target="_blank">here</a>).  If
I did not answer your questions completely please let me know.  I will try
to answer you the best I can.

Regards,

Jesse O.
Applications Engineering
National Instruments

Sileas

2006-08-15 03:10:10 UTC

Permalink

Thanks for the additional help.  I finally gave up this weekend and just created a task per line, 16 Out and 8 In.  That seems to work, except I am having issues through NIDAQmxBase 1.5 C API configuring pins to Push-Pull (but that is on a different thread right now <a href="http://forums.ni.com/ni/board/message?board.id=70&message.id=5339" target="_blank">http://forums.ni.com/ni/board/message?board.id=70&message.id=5339</a>)
Thanks.
 