DIO Write/Start VIs - bizarre mismatch between # updates and data

[Alex Rast]

I'm running LabView 6i and have encountered a bizarre discrepancy between what
*I* think should be the "number of updates" parameter of the DIO Start VI and
the number of elements I seem to have to have in the "digital data" parameter
of the DIO Write VI. Here's what the help has to say on both:

"Digital Data is a 1D array containing digital output data. Each element in
this array is an 8-bit unsigned integer that represents a single port�s data.
The total number of elements in this array equals the number of ports in the
group multiplied by the number of updates to write. For example, if your group
contains two ports, then elements 0 and 1 contain the data for the first
update."

"Number of Scans/Updates tells LabVIEW how much memory to allocate for the
buffer. If the group direction is input, a single read from each port in the
group is a scan. If the direction is output, a single write to all ports in
the group is an update. The size of a scan or update in bytes is equal to the
number of ports in the group.
Macintosh If you are using NB-DMA-8-G or NB-DMA2800, the buffer size
cannot be greater than 2^24- 1, which is 16,777,215 bytes.

The default input for # of scans/updates is -1, which means LabVIEW leaves the
current setting for # of scans/updates unchanged. The default setting for # of
scans/updates is 1000."

I have a 6533 DIO board (PCI-DIO32HS) which allows for 8, 16, or 32-bit
transfers (1, 2, or 4 ports). So, if I did a single 32-bit transfer, I would
think the "Number of Updates" should be 1, and the "Digital Data" array should
have 4 elements. However, I have discovered this not to be the case.

If I use 1 for the Number of Updates, the program errors out with a -10010
error. I found that you have to specify the Number of Updates as the number of
*byte* updates, irrespective of the width of the transfer. So in the case of a
32-bit transfer, the number of updates must be 4. Well, that I can accept.
Documentation can be poor and inaccurate. But here's where it gets really
wierd.

If I simply use 4 for the number of updates, and a 4-element data array, the
program *still* errors out. To give you the background, I build my data array
within a double nested FOR loop, the outer loop going over the number of
updates, the inner over the byte-width of the transfer. For a single 32-bit
word transfer, I would then expect to iterate over 1 outer cycle and 4 inner
cycles, to build a 4-element array. But no, Labview doesn't like that. What
I've discovered actually works is iterating over the "Number of Updates"
parameter the DIO Start routine expects, *and* over the number of bytes in the
transfer. Thus, for a single 32-bit transfer, the program must generate a
16-element array in order for the routine to work! Furthermore, the array
repeats every 4 places, so that in each block of 4 elements, you have the data
duplicated! And yet the program then does output the correct data on the
lines. It's as if the internal Labview routines actually do the following on
the Digital Data array: For transfer width W, port N, update X read array
element (W*X)+(N-1). Very strange.

Is this a bug in Labview? Or can someone explain this behavior in any other
way?

Thanks,

Alex Rast
arast@inficom.com
arast@qwest.net

[bman]

Alex

I understand what you are saying. I'm not sure why the DIO Write vi will not accept a 4 element array to output one update to a 32 bit port. I am able to supply an eight element array for two updates and so on. I'm assuming when they wrote the DIO Write vi, they didn't except users to only use it with one update. (Instead use the port vi's for immediate updates.)

Brian

[KBersch]

I have the same DI/O card and have run into the same problem but I see it differently. The Digital Write VI (or maybe it was the Digital Start VI) won't let you do less than 4 writes, no mater many ports you use. I was writing to 2 ports (16 bits to ports 0 & 1) and found I had do a minimum of 4 writes which requires 8 data bytes (4 for port 0 and 4 for port 1). I also tried wrting to just one port (port 3) and found that I had to again do a minimum of 4 writes which required 4 data bytes (4 for port 3). I was able to do a work around by writing the same data 4 times to the same address. This may not work for you. I haven't had time to lok at the VIs in question to see if I could solve this problem. The bug seems to be in the VI and not in LabVIEW proper.

Ke
lly

[Alex Rast]

In article <50650000000500000080450000-1002247793000@exchange.ni.com>, KBersch wrote:
>I have the same DI/O card and have run into the same problem but I see
>it differently. The Digital Write VI (or maybe it was the Digital
>Start VI) won't let you do less than 4 writes, no mater many ports you
>use. .... The bug seems to be in the VI and not in LabVIEW
>proper.
>


So are you saying that if I modify the VI to work right for the
single-transfer case, it will then be wrong for the many-transfer case? And
therefore I must have a CASE structure to detect the single-transfer
condition?

Meanwhile, the bug, assuming it is one, would appear to be in lvdaq.dll,
specifically the Digital_Buffer_ControlInterface function. The VI's above this
ar
e merely "wrappers" for this function. Where does National Instruments
document lvdaq.dll? And where is the lvdaq.dll source code? (Actually, though,
I suspect even this module is itself in turn merely a collection of wrappers
for the low-level device driver, NIDAQ32K.SYS (and its support files,
nibffrk.dll, nimdsk.dll, nistck.dll, and nipalk.sys). To fix the problem
probably requires a change to NIDAQ32K.SYS. I could do this, but I don't think
National Instuments would want to supply any support at that point. It might
require some big company to whine at them about at it, because you gotta know,
no matter how many smaller companies complain, there's no way in hell they'll
actually do something about it until some company big enough to rate on their
radar screen puts up a fuss)


Alex Rast
arast@inficom.com
arast@qwest.net