Missing byte in GPIB transfer

ta-staff · ‎12-14-2011

Hello,

in my measurement configuration I have a network analyzer connected to a PC using GPIB interface (NI PCI-GPIB, default setting).

The control software is HTBasic from TAMS which always uses the GPIB in the asynchronous way.

The controller should be fast enough (dual core @3 GHz)

Sometimes the transfer of binary data between NWA and PC fails. I learned that one byte will be lost.

I tried to find the cause of this, but in vain up to now.

More details:

A GPIB analyzer protocol displays all bytes, in the parallel NI-Spy log one byte is missing.

Here is the GPIB analyzer protocol, the relevant byte is underlined:

-- -- -- a 00001010 0 0 0 1 0 0 1 1 DAB

-- -- -- 1d 00011101 0 0 0 1 0 0 1 1 DAB

-- -- -- ? 3f 00111111 0 0 0 1 0 0 1 1 DAB

-- -- -- e2 11100010 0 0 0 1 0 0 1 1 DAB

-- -- -- 90 10010000 0 0 0 1 0 0 1 1 DAB

-- -- -- 91 10010001 0 0 0 1 0 0 1 1 DAB

-- -- -- > 3e 00111110 0 0 0 1 0 0 1 1 DAB

-- -- -- a7 10100111 0 0 0 1 0 0 1 1 DAB

-- -- -- e0 11100000 0 0 0 1 0 0 1 1 DAB

-- -- -- 1c 00011100 0 0 0 1 0 0 1 1 DAB

-- -- -- ? 3f 00111111 0 0 0 1 0 0 1 1 DAB

-- -- -- e0 11100000 0 0 0 1 0 0 1 1 DAB

The export of NI-Spy in this section shows the following result (again with underline in the important section):

1227750. Asynchrone I/O neu synchronisiert für ibrda()

Prozess-ID: 0x00000900 Thread-ID: 0x0000090C

Startzeitpunkt: 09:40:40.809 Aufrufdauer 00:00:00.000

ibsta: 0x2164 iberr: 0 ibcntl: 457(0x1c9)

Ausgangspuffer

00000000: 8F 77 7A BF BB 42 53 3E 95 23 79 BF C7 3A 6B 3E .wz..BS>.#y..:k>

.etc

.

000001C0: 59 FE 1C 3F ED FE 91 3E 0A Y..?...>.

1227751. ThreadIbcntl()

1227752. ibrda(GPIB0, 0x01CFC503, 5159 (0x1427))

1227753. ibwait(GPIB0, 0x0000)

1227754. Asynchrone I/O neu synchronisiert für ibrda()

Prozess-ID: 0x00000900 Thread-ID: 0x0000090C

Startzeitpunkt: 09:40:40.809 Aufrufdauer 00:00:00.000

ibsta: 0x2164 iberr: 0 ibcntl: 17(0x11)

Ausgangspuffer

00000000: 0A 1D 3F E2 90 91 3E A7 E0 1C 3F E0 3E 91 3E 8F ..?...>...?.>.>.

00000010: D3 .

1227755. ThreadIbcntl()

What is obvious is that

- the binary stream is split up at bytes 0x0a (although the application reads in the stream with one command: "ENTER @Stream;Array(*)") which doesn't make a problem.

- some bytes before the missing byte there are two consecutive bytes 0x0a (may be by chance)

- after the missing byte the stream is split up again, but here (there is only one occurrence of this) NOT at 0x0a

What I have tried:

- It does not help setting the interface to "No autopolling"

- No other device is on the bus

- The NWA does not send a SRQ

What I want to know:

- can the application have an influence on the content of the NI-Spy? Is it the driver or the application?

- How can I prevent this?

I hope there is someone being able to help as I don't know how to proceed.....

Many thanks in advance.

fendrix · ‎12-23-2011

Hello,

after inspecting the two logs for several times I was not able to determine where I should find a lost byte.

Can you specify where there is something lost?

Best regards and a merry christmas,

Frank

JÞB · ‎12-27-2011

0x0A is the default termination character. so with term char enabled the read stops when it sees a 0x0A

Drop one of these before your read and read the number of bytes you expect

"Should be" isn't "Is" -Jay

ta-staff · ‎01-02-2012

Dear Frank,

thank you for checking my request. Merry Xmas as well. This is the reason why the reply is so late...

You are right, I copied the wrong section and marked the wrong 0x1c byte. The relevant logs are shortly afterwards:

GPIB-Analyzer:
          -- -- --        a7 10100111 0 0 0 1 0 0 1 1 DAB
          -- -- --        e0 11100000 0 0 0 1 0 0 1 1 DAB
          -- -- --        1c 00011100 0 0 0 1 0 0 1 1 DAB
          -- -- --     ? 3f 00111111 0 0 0 1 0 0 1 1 DAB
          -- -- --        e0 11100000 0 0 0 1 0 0 1 1 DAB
          -- -- --     > 3e 00111110 0 0 0 1 0 0 1 1 DAB
          -- -- --        91 10010001 0 0 0 1 0 0 1 1 DAB
          -- -- --     > 3e 00111110 0 0 0 1 0 0 1 1 DAB
          -- -- --        8f 10001111 0 0 0 1 0 0 1 1 DAB
          -- -- --        d3 11010011 0 0 0 1 0 0 1 1 DAB
          -- -- --        1c 00011100 0 0 0 1 0 0 1 1 DAB
          -- -- --     ? 3f 00111111 0 0 0 1 0 0 1 1 DAB
          -- -- --        c7 11000111 0 0 0 1 0 0 1 1 DAB
and the NI-Spy log is here:

1227754. Asynchrone I/O neu synchronisiert für ibrda()
Prozess-ID: 0x00000900         Thread-ID: 0x0000090C
Startzeitpunkt: 09:40:40.809       Aufrufdauer 00:00:00.000
ibsta: 0x2164       iberr: 0             ibcntl: 17(0x11)
Ausgangspuffer
00000000: 0A 1D 3F E2 90 91 3E A7 E0 1C 3F E0 3E 91 3E 8F ..?...>...?.>.>.
00000010: D3                                               .

1227755. ThreadIbcntl()
.
ibsta: 0x2164 iberr: 0 ibcntl: 17(0x11)

1227756. ibrda(GPIB0, 0x01CFC514, 5142 (0x1416))
.

ibsta: 0x0 iberr: 0 ibcntl: 0(0x0)

1227757. ibwait(GPIB0, 0x0000)
.