digital pattern generation with PCI 6259

[Specter]

Hello,

I am trying to do synchronous, hardware timed digital I/O using Port 0 of a USB-6259.  I have designated lines 0-7 as outputs and lines 8-15 as the input lines.  I am using counter 0 as my timing source.  There is a piece of example code that ships with LabVIEW, upon which I am basing my vi.  I have changed the number of lines I'm using as inputs and outputs, and I have changed the data type.  I haven't changed anything else.

The example code which ships with LabVIEW specifies lines 0-3 as the inputs and lines 4-7 as the outputs.  The data type is digital waveform.  The example works fine when I run it.

In my code, for various reasons, I would prefer to use a 1D U8 array as my data type (mainly because that's how I've had the data written for several years now and it's going to be a royal pain to change my U8 arrays to a digital waveform).  When I run my code, I receive error -200563, which informs me that the specified digital channel contains more bits than are supported by the U8 data type.  Since I've specified that the channel consists of port 0, lines 8-15 (which would seem to correspond to 8 bits, perfectly reasonable for a U8 data type), I do not understand why I am receiving this error.  Can anyone help?  Why does this operation seem to work with digital waveforms but not with U8 arrays?

Thanks!

Diane

[Jennifer O]

Hi Diane,

As outlined in the Error -200563 From a DAQmx Digital Input Task knowledge base, to use the port format, DAQmx can only read a complete port.  In the case of the USB-6259 the port is 32 lines or bits.  If you need to get the data into a U8 format, you can use the waveform option for the DAQmx read VI and convert the data to U8 using a "digital to binary" function.

Hopefully this helps,

Jennifer O.
Applications Engineer
National Instruments

[Kevin_Price]

Yeah, you'll have to read the full 32-bit port, perform an AND with hex 0xFF00 to mask off input bits 8-15, logical shift-right by 8 bits to move them down to bits 0-7, then convert to U8.

On the output side I *think* (but am not sure) that the driver performs automatic masking based on the bits you originally specified in the virtual channel when setting up the output task.  If I'm right, then it won't matter what is contained in the upper 24 bits of the u32 values you write to the task, only the lower 8 bit values would actually be written.

Side note: In the old traditional NI-DAQ Port Write vi, one would wire in both a u32 bit value AND a u32 bit mask.  Internally, only the value bits corresponding to 1's in the bit mask would be written.  All other bits would be left in their prior state.  This type of specification with both bit value and bit mask isn't needed in all apps, but it is quite handy in some.  The mask bit is like an Enable, controlling whether or not the new write bit gets through.

Under DAQmx, I don't recall a way to perform this same function.  I think you'd need to do it in your own code with bit-wise logic functions.  For apps that need it, this is one of the areas where the DAQmx interface can be more cumbersome than the old traditional NI-DAQ interface.  Here's what I *think* you'd need to do to accomplish masking of some of your output bits.

1. Perform DAQmx Read on your output task.  This should return the bit value of all your output bits and 0's for all other bits.  (I'm not sure if this can be done on buffered output tasks though.)

2.  Use bitwise operators to produce the bit pattern to write.  Maybe there's a more compact way to do this, but here's what I came up with:

Let C = Current bit pattern from read,  N = New bit pattern,  M = Mask bit pattern of mask,  W = bit pattern to Write

Desire: Each 1 bit in Mask selects corresponding bit from N,   Each 0 bit in Mask selects corresponding bit from C.

Expression: W = (NOT(M) AND C) OR (M AND N)

3. Write bit pattern W using DAQmx Write.

-Kevin P..

[Specter]

😛

Thanks for the advice.  The read / write operation has to take place simultaneously because of my peripheral...I don't have the option of doing the read, then the write, which it looks like you're telling me to do.  (If the board is trying to simultaneously read and write all 32 lines from the same port, won't it get kind of confused?)  So it would appear as though my sole option is to convert all of my write data to a digital waveform, which is going to be a first-class nightmare.

Guess my time estimate for this particular task just shot through the roof!  🙂

Just out of curiosity, does NI have any multifunction boards containing more than one clocked digital port?  I was previously using a 6533 for my digital communications, but now we want to add analog generation capability AND move from a desktop to a laptop.  I'd rather not use the PCMCIA version of the 6533 because it makes lousy connections with the computer and it's really messy to have that huge connector hanging off the side -- and laptops don't come standard with PCMCIA slots anymore.  🙂  I was hoping to find a single-board solution and the 6259 is the best I could come up with.  Is there another USB multifunction board I'm not aware of, that has two 8-line hardware-timed digital ports?

Thanks very much for the replies!

diane

[Kevin_Price]

Some bits of clarification:

1. You definitely CAN have buffered DI and buffered DO tasks operating simultaneously, provided they access different bits of port 0 on a 6259.  I've had success with this in an app with 8 DO bits and 24 DI bits that were buffered by a shared sampling clock, outputs on leading edge & inputs on trailing edge.  This ran at 10 kHz in hardware.   I read, processed, and reacted to the incoming DI patterns at 100 Hz.

2. As I said before, in a buffered DO task, I suspect you aren't allowed to perform a DAQmx Read to peek at the instantaneous state of the output bits.  In an unbuffered "on-demand" type of task, you definitely can.

3. Early on, I discovered issues with the "TotalSamplesGenerated" property of the DO task.  It reported the # of samples that had been moved from system RAM to the data acq board, NOT the # of samples that had actually been clocked out to the output pins.  Since my DI task shared the same clock, my workaround was to query the "TotalSamplesAcquired" property from the DI task.  Hopefully, you can do something similar to keep DO and DI in sync.

My app regenerated a fixed pattern, so by knowing the # of sample clock cycles that had passed, I could figure out the DO pattern for that cycle and thereby also figure out the expected DI pattern.  So, lacking the ability to directly read the output bits, I maintained a means to "look up" the DO pattern for any given cycle(s) I needed. 

-Kevin P.

EDIT: simple proofreading

Message Edited by Kevin Price on 12-18-2006 02:35 PM

[Specter]

Hi Kevin,

Thanks for the response!

I'm reading / writing a fixed number of samples, so I actually don't need a real-time look at the instantaneous state of the input lines.  The VI runs, uses Digital Read to collect the specified number of samples and output an array containing the values, and then I process the array.  So if the port will handle the simultaneous DI / DO ok (provided, as you said, that I specify different bits on the port for each operation), then everything should be golden.  If the DI operation and the DO operation are using the same clock, they shouldn't get out of sync, should they?  By no means am I reading / writing large amounts of data -- the largest number of samples I'll ever need to process is something like 100.  I need to run the operation at 100kHz, but that should be well within the board's capability.  I just need to make sure that I read one port value for each one I write, otherwise I'll miss data and my software will become confused and grumpy.

So given that I don't need real-time samples of the state of the digital lines, does it sound like the simultaneous operation should work if I just use the U32 version of the DAQ VIs?  My exisiting array processing routine should work regardless of whether I'm looking at U8 or U32 (or U16, for that matter) so that's not an issue.

Thanks a lot for all of your help!

Diane

[Kevin_Price]

Yep, sounds like you should be just fine once you use the U32 version of the Read function.

-Kevin P.