configure handshake

[-Joe-]

I am rehosting a older piece of equipment (a monochromator by Bentham) onto a newer platform. 

The device is round about 20 years old and is currently controlled by the original DOS software (written in BASICA/GW-BASIC) on the original PC (equipped with an IEEE488 interface card by CEC/Keithley).

The new platform (WindowsXP/2000) is equipped with an GPIB interface card by NI (PCI-GPIB).

Sending a command from the DOS-PC to the device causes to device to react as expected (a stepping motor starts to move), but sending the exact some command from the WindowsPC doesn't work, the device does not respond 😞
(btw: the device is a basic listener)

I have a gpib+ card and have verified the data is ok, but the handshaking of the two interfaces is different.

Looking at capture files you will see, that the EOI lines are asserted at different times.
(i attached the complete capture files)
Win/NI:
       0  0   0   0 100     a   00001010  1 0 0 1 0  1 0 0       EOI^   DAVv
       0  0   0   0 100     a   00001010  1 0 0 1 0  1 1 0       NDAC^
       0  0   0   3   0     a   00001010  1 0 0 1 0  0 1 0       NRFDv
       0  0   0   0 150     a   00001010  1 0 0 1 0  0 1 1  DAB  DAV^
       0  0   0   0 100     a   00001010  1 0 0 1 0  1 1 1       NRFD^
       0  0   0   3   0     a   00001010  1 0 0 1 0  1 0 1       NDACv
       0  0   0   0 100     0   00000000  0 0 0 1 0  1 0 0       EOIv   DAVv
       0  0   0   0 100     0   00000000  0 0 0 1 0  1 1 0       NDAC^
       0  0   0   2 950     0   00000000  0 0 0 1 0  0 1 0       NRFDv

DOS/CEC:
       0  0   0   0 150  T  54  01010100  0 0 0 1 0  1 0 0       DAVv
       0  0   0   0 100  T  54  01010100  0 0 0 1 0  1 1 0       NDAC^
       0  0   0   2 950  T  54  01010100  0 0 0 1 0  0 1 0       NRFDv
       0  0   0 226 600     a   00001010  1 0 0 1 0  0 1 1  DAB  EOI^   DAV^
       0  0   0   0 100     a   00001010  1 0 0 1 0  1 1 1       NRFD^
       0  0   0   2 900     a   00001010  1 0 0 1 0  1 0 1       NDACv
       0  0   0   0 150     a   00001010  1 0 0 1 0  1 0 0       DAVv
       0  0   0   0 100     a   00001010  0 0 0 1 0  1 1 0       EOIv   NDAC^
       0  0   0   2 950     a   00001010  0 0 0 1 0  0 1 0       NRFDv

I guess that may be the problem, but i have no clue how to fix that... i am at my wit's end 😞

any tips?

Message Edited by -Joe- on 06-06-2006 09:01 AM

[Collin M]

The first issue I see is that EOI asserts simultaneously with DAV, according to the GPIB analyzer, with the CEC/Keithley board. The analyzer has a 50ns resolution so EOI and DAV may not assert at exactly the same time but do assert within a few ns of each other. EOI should change when the DIO lines change, in order for EOI to settle by the time DAV asserts. There is a minimum delay of at least a few hundred ns required after changing DIO/EOI to asserting DAV.

Does the instrument expect to have messages terminated with EOI? It may be possible that the instrument samples EOI as unasserted when DAV asserts with the Keithley/CEC board. With the NI board it will detect EOI is asserted.

Is the behavior 100% consistent?

Can you post the relevant part of your firmware?

[-Joe-]

i did some low level tests on both systems and figured out that the instrument does NOT expect to have messages terminated with EOI.
i attached two new capture logs, they are basically the same now. The DOS/CEC version works, the Win/NI version does not 😞

The only differences i see, which might be important:
- the data lines get asserted at different times
- the timing, maybe modern GPIB interfaces are too fast for this old instrument?

btw, here are two source code snippets:
DOS/CEC (BASICA):
    690 MY.ADDR%=21
    700 RETSTAT%=0:LEVEL%=0
    720 CALL INIT%(MY.ADDR%,LEVEL%)
    750 MESS$="UNL UNT LISTEN 30 MTA"
    751 CALL TRANSMIT%(MESS$, RETSTAT%)
    775 CMD$="D0150T"+CHR$(10)
    780 MESS$="DATA '"+CMD$+"'"
    781 CALL TRANSMIT%(MESS$, RESTAT%)

Win/NI (C/C++):
    int bus = ibfind("GPIB0");
    ibeot(bus, 0);
    ibsic(bus);
    ibcmd(bus, "?", 1);
    ibcmd(bus, "_", 1);
    ibcmd(bus, ">", 1);
    ibcmd(bus, "U", 1);
    ibwrt(bus, "D0150T\n", 7);   

(i removed all the error detection stuff)

[-Joe-]

i attached the wrong capture log of the windows version and was'nt able to edit my message (!?), here is the correct one

[Collin M]

I see that the DOS/CEC system is transferring a data byte every 195us or so, and the Windows/NI system is transferring a byte every 7us or so.

I'm not suggesting this as a long-term solution but can you break apart the data transfer into transfers of individual bytes? For example, you currently have the following function:

ibwrt(bus, "D0150T\n", 7);

Change that to

ibwrt(bus, "D", 1);   
ibwrt(bus, "0", 1);   
ibwrt(bus, "1", 1)

and so on. Then insert some delay function between each ibwrt to try to match the delay of the DOS/CEC system.

There are some older instruments that can't keep up with the modern GPIB controllers. The problem is typically that the instrument unasserts NDAC (signaling data was accepted) before the instrument has actually accepted the data. Most newer controllers immediately change the data byte once NDAC is detected as unasserted.

[-Joe-]

i split up the message into individual bytes and transfered them separately including a small delay.
The problem is that the DIO lines get immediately unasserted once NDAC is detected as unasserted (see attachment) 😞

Can i prevent the controller from doing that?
Or is there a way to do all the handshaking (asserting/unasserting of lines) manually in software?

[Collin M]

Ok, I wanted to verify the problem was caused by DIO changing after NDAC, not the transfer rate. I agree with you that the problem is likely DIO changing soon after NDAC unasserts.

On your NI PCI-GPIB board there should be a label with some numbers and a letter. It should either start with 188513 or 183617. Can you respond with the rest of what is printed on the label?

[-Joe-]

I found three numbers:
ASSY188513B-01
1150FDA
UL94V-0 188515B-01

I guess, you asked for the first one...

Message Edited by -Joe- on 06-08-2006 08:25 AM

[-Joe-]

Hi Collin M,
are you able to make use of the numbers i posted?

you are my last hope... 🙂

[Collin M]

Joe, haven't forgot about you. Am consulting with another engineer to determine the best fix. Will try to get an answer today.