Random errors in ibrd result

[vicius]

I am using an AT-GPIB/TNT (plug and play) card to communicate with my instruments, and I experience the following problem:

Suppose you sent a request to an instrument, and suppose that the answer is made of 10 bytes. If the answer is read with the command "ibrd(address, 10)" everything works fine. But if the answer is read with the command "ibrd(address, 12)" (or any other number greater than 10), then you would get 10 bytes read (as it should be) but the last two bytes of the answer are substitued with the corresponding two bytes of the request string (if the string is long enough)!!! And this happens randomly.

Note that:
1) not any error is reported in the GP-IB status byte;
2) this problem occurs with all the instruments I have;

3) the same program on a different PC, with a PCMCIA GP-IB card, runs without any problem.
4) the card passes all the test made by the NI software.

Some tecnical details:
card version: 1.0.00
driver version: 1.70.1034
o.s.: Windows 95 (4.00.950 B)
motherboard: PCI with one ISA slot (hosting the GP-IB card)

Does anyone know what's going on? Should I modify driver and/or settings, or should I buy a new card?
Thank you

[GPIB_Guru]

GPIB transfers are not NULL-terminated, and the driver does not automatically append a NULL character to the end of the string. If you wish to use standard string manipulations (like strlen, printf, ... ), the string must be NULL-terminated. Use the global count variable, ibcntl, to determine how many bytes were received by NI-488.2. Then, NULL-terminate the buffer (if there is room) manually my placing a '\0' character at data[ibcntl].

[vicius]

Unfortunately this is not the case. The strings provided by ibrd are correctly NULL terminated, and they contain exactly ibcntl bytes. The problem is that the last two of those bytes sometimes are wrong!

[GPIB_Guru]

Why don't you post a few NI-Spy captures showing an ibrd 10, and ibrd 12 on both the AT and PCMCIA interfaces.

[vicius]

Here are the captures. The first file (capture-pcmcia.spy) refers to the PCMCIA and it shows two requests, followed by two ibrd commands. The first one reads 12 bytes (the right ammount), the second one 15 bytes. It both cases the anwers are right.
The second file (capture-at.spy) refers to the AT card, and it shows five requests equal to the previous one. The ibrd calls asking for 12 bytes always work right, whereas those asking for 15 bytes sometimes provide a wrong answer.
The same thing would happen with any other number of bytes greater than 13 (yes, 13 not 12).
I'm getting more and more convinced that there is some sort of hardware problem. Incidentally, I have also changed the cable, but the result is the same.
Thanks.


P.S.: The examples reported here refer to an HP 8110A pulse generator, but the same kind of problems appears with any other instrument. The request ":voltage1:high?" asks for the maximum voltage of the channnel 1. The ibwrt command following each request writes the character 10 (in ASCII code) required by the instrument as command termination.

[GPIB_Guru]

One quick test. Disable DMA on the AT-GPIB/TNT board. You can do this simply in your application by calling the function ibdma with a value of zero. This is a board-level call. If this works, re-enable DMA (comment out the line of code that disables it) and change the DMA channel that your board is currently using. With the non-pnp card, you must removed it and play with the jumper settings. Don't forget to update the config program with the new settings.

[vicius]

Great, it works! Almost...
If I call the function ibdma with a value of zero the AT card works perfectly, and I don't see any more those strange errors. However, if I re-enable the DMA, even changing the DMA channel among the free ones the strange errors come back again (the only free channels Windows allows me to use are 05 and 07).
I have also tried to disable the DMA via the board configuration panel, but this doesn't solve the problem.
Anyway, I think I'm going to use the first solution you suggested, based on the ibdma call. It works, and it should be enough for me.
Thanks a lot!

Luca