DIO-6533/DIO32-HS : slow/defective handshaking in Burst mode?

[PA]

I'm trying to use a DIO6533 (PCI-DIO-32HS) in burst mode. The ports are configured as one group (ports 0, 1, 2, 3 form Group 1) for 32-bit transfer. The data clock (PCLK1) is always an INPUT to the DIO6533. The handshaking lines are being monitored with a high-speed logic analyzer. For data clock frequencies below 10MHz the data operations take place without a problem, but above 10MHz the ACK line timing starts to deviate from what's stated in the board manual and at 20MHz ACK1 only has short pulses that never stay high long enough to achieve a data transfer at the rising edge of PCLK1 (the peripheral polls ACK1 at the negative edge of ACK1 and asserts REQ1 when necessary).

Is this typical behavior? Is it a
defective board? Is it a computer/system speed problem (the PC used is a dual processor Pentium II with Windows NT)?

Thank you very much in advance,

Pablo Acosta

[Filipe A.]

Pablo;

The 6533 DAQ device has a small 16 word on board memory that stores teh acquired data points. Then, since the data transfer from the on board memory to the computer memory is DMA based, and every PC has 3 DMA channels available on the PCI bus, all devices that use DMA will share those 3 channels. That, might cause an overhead to the data to be transfer, and since the on board memory is small, the board can't keep storing data untill the on board memory content to be flushed out to the PC memory. That can slow down your communication rate.

The 6534, on the other hand, has a 32M byte on board memory, and operates on the same way the 6533 does. The advantage on that case is the deep memory that can store a fairly big ammount of data, without relying to muc
h on the DMA trasnfers. That might be the solution for your problem.

Regards
Filipe A.
Applications Engineer
National Instruments

[Alex Rast]

x@no.email (PA) wrote in <5065000000080000002F740000-1042324653000
@exchange.ni.com>:

>I'm trying to use a DIO6533 (PCI-DIO-32HS) in burst mode. The ports
>are configured as one group (ports 0, 1, 2, 3 form Group 1) for 32-bit
>transfer. The data clock (PCLK1) is always an INPUT to the DIO6533.
>The handshaking lines are being monitored with a high-speed logic
>analyzer. For data clock frequencies below 10MHz the data operations
>take place without a problem, but above 10MHz the ACK line timing
>starts to deviate from what's stated in the board manual and at 20MHz
>ACK1 only has short pulses that never stay high long enough to achieve
>a data transfer at the rising edge of PCLK1 (the peripheral polls ACK1
>at the negative edge of ACK1 and asserts REQ1 when necessary).
>
>Is this typical behavior? Is it a defective board? Is it a
>computer/system speed problem (the PC used is a dual processor Pentium
>II with Windows NT)?
>

I'm glad to see somebody else has this problem! We've run into the same
problem outselves. Your situation is EXACTLY identical to ours, in terms of
hardware, configuration, etc. What version of the driver are you using? I
downloaded the latest version off the NI site in order to minimize the risk
of any problems, and still had this problem occurring. I've never seen a
similar post in the past, which starts to make me think it could be a bug
in the driver. National Instruments people, *please* check into this ASAP!

It could also be a problem with environment. National Instruments, have you
ever tested the card/driver in a dual-processor PII under WINNT? I've
noticed a lot of programs have strange, flaky problems on dual-processor
machines, especially in NT, and your software could be one of them.

Lastly, there could be a hardware bug in the card. Has anyone else out
there run the DIO32-HS in burst mode at high speed? What were your results?
Did you get your transfers to work? Hopefully those who have run into
problems will respond to this post with their experience, so that NI can be
made aware of the problems with their system. I wouldn't rule out the
possiblity that there may have been a defective run of cards, too. It'd be
interesting to get card serial numbers from people seeing the same bug.

Filipe (or other people at NI) - I don't think the problem is related to
other devices using DMA because we tested under a variety of conditions,
including setting up interrupt-driven transfers, and encountered the same
behaviour. We're pretty experienced around here at troubleshooting setup
and environment-related issues and nothing that we did or tried seemed to
have any impact.

Alex Rast
arast@inficom.com

[PA]

I installed the latest version of the NI-DAQ drivers, version 6.9.3. I also removed the NI-DAQ drivers that
LabVIEW 6 installs to avoid any potential conflict.

The 6533 is the only card active in the PCI bus. Getting a 6534 is not much of an option given the money already spent and the cost of the "new" card (around $1700).