Missing GPIB command words

[kerwen]

Hi,

Good day, my first post here. I need some advice from the gurus here. I have some intermittent GPIB miscommunication error between 2 test equipment; the tester and handler. The tester is using a NI PCI-GPIB board in the test computer.

This problem usually happens after loading the program on the tester and when the actual communication commence between the 2 equipment, some command words exchanged, have some characters missing. This results in failure to continue production and the need to reboot the test computer to trial & error till there is no error occurred.

Below is some example of the problem where command words from tester to handler have missing character.

      Eg1,

            GP: spcm 255

            GP: prm 255 (missing‘s’, should be sprm)

            ERR: Neither 'prm' or '255' a command

     Eg2,

            GP: trs (missing ‘,,1’ expected trs 1,,1 since we are running dual site 0&3)

            ERR: Missing site(s) for ‘trs’

            GP: sqb?

            => 169

The occurrence range from once per month to 5 times per month on all testers. All the testers are running Win2k SP3, Office SP4. However the gpib driver versions range from 2.0 to 2.4. Any gurus here have similar problem before? Can share your findings/comments? Thanks alot.

Regards,

Kevin

 

[Collin M]

Do you know how the GPIB interfaces for the instruments are implemented? How long are your GPIB cables and what configuration (star/daisy chain)? What model and manufacturer of instrument are you using?

Is it the case that the same characters are always missing or are random characters missing? Is it always the nth character (5th character or 9th character) that is missing? Is the byte that precedes the missing character always the same? Any pattern you can discern? Can you post several instances of the missing byte cases?

Do you get any error notification at the host when this happens? Bytes are handshaked individually in GPIB. It is likely that the PCI-GPIB saw something at the distant end handshake the missing bytes.

[kerwen]

Hi Collin,

Do you mean the software implementation portion aspect? There is only 1 equipment connected to the test computer (master controller) per setup. The GPIB cables used range from 1m to 3m, some setups have 2 shorter cables connected in daisy chain. The equipment is a Delta Castle Logic handler (slave) (IEEE-488.1). The length of the cable recommended by the handler is maximum of 4m. Messages exchanged are base 10 ASCII-coded numbers.

No, random character missing are observed and at different position. There is no specific pattern that i'm able to percieve.

GPIB Settings used:

• Bus timing: 500nsec
• Cable length: Disabled
• System controller: checked
• Enable auto polling: checked
• Send EOI at end of Write: checked
• EOS byte: 0

Eg3.

GP: emm?  (emulator mode?)

=> 2 (mode 2 = no emulation)

GP: spcm 255 (set spoll clear mask)

GP: prm 255 (should be sprm 255: spoll read mask)

ERR: Neither 'prm' or '255' a command

Eg4

GP: spcm 255

GP: sprm 255

GP: sqlm 255 (set SRQ line mask)

GP: ts? (should be nts: read the number of test sites)

There is no error messages coming from the test computer/program. As in the example2, trs 1 (missing ,,1). The tester should be giving the 1 result for each site, i.e total 2. However, due to the missing ',,1', the tester gave only 1 result to the handler.

The problem is strange as we were not able to simulate the problem and the occurrence is intermittent.

Apologize for the lengthy post. Thanks.

Message Edited by kerwen on 10-02-2006 09:34 PM

[Collin M]

This is a tough one. You can try changing the bus timing from 500nsec to 2usec. Also, can you change GPIB cables? Those are long-shots but we should rule them out.

Do you have a GPIB analyzer? I would like to verify what is happening at the physical layer. I suspect that it would show the missing bytes are in fact being transferred.

It is interesting that in one case the last 3 consecutive bytes are missing from one transfer. That may be a different root cause than the random missing byte.

Have you contacted Delta Design about this?

[kerwen]

I don't really suspect the cable to be the cause of problem as there's about 8 setups having this problem. And also, recently, there's was another case of this problem and short cable (1m) was used in this setup.

Unfortunately, i do not have the GPIB analyser.

Our counterpart are also running similar setups and it seems they do not encounter this problem. From there, we align our settings (handler os version / GPIB settings) according to them but was unsuccessful.

I am suspecting it's the GPIB driver version that might be incompatible with the interface of the handler. From the NI website, there's a note which recommend to use v1.7 for PCI-GPIB, Win2k to communicate with legacy device.

[Collin M]

If there are 8 different systems that show this problem I agree that it is not likely the GPIB cable.

Is it possible to determine the firmware version on the instrument itself, and if it is the same as the instruments at the other site? It seems the key is to determine the difference between the two sites.

I don't think that a host driver problem could cause random missing bytes, although I am not positive. It seems more likely the problem is with the the firmware of the instrument or the hardware.

Is your counterpart using identical host hardware (PCI-GPIB), NI-488 driver versions, operating system versions, and instrument HW/SW versions? If you expand the Software tab in MAX it should tell you the exact software versions of all NI software.