Problem with getting GPIB-ENET/100 communication with old instrument

[Paul66]

Hi!

I am trying to get my VB.net program to communicate with an older instrument (Infratek 305 A, instrument for power measurements) via a GPIB-ENET/100 device.

The manual of the instrument does not say what GPIB standard it support, but the instrument is detected by the Measurement and Automation Explorer.

By detected i mean that MAE has detected an instrument located on the correct GPIB address but the identification shown is the instrument measurement output string

instead of the instrument name (as shown for some newer Agilent instruments).

When i run my application i monitor the communication with NISpy.

Configuration of the instrument seems to work and i do this only once in the program.

The problem is related to reading data from the instrument. I do get a correct string from the instrument every time i read data. But the problem is

that i get the same data in two consecutive reads and first after that i get new data and also this new data is received in two consecutive reads.

According to the instrument manual the instrument outputs data as follows:

"A data line is terminated with CRLF. The instrument may send several lines of data. When the whole data transfer is finished the EOI (End or Identify) is sent"

My termination settings are:

Send EOI at end of write : YES

Terminate read on EOS: NO

EOS byte : 2

8 bit EOS compare: YES

Set EOI with EOS on write: NO

How should i configure the GPIB-ENET/100 to work with my instrument?

Here are som NISpy logs:

---

### Configuration ###

61.  ibwrt(UD3, "C0C2C4C8..", 10 (0xA))
Process ID: 0x0000113C         Thread ID: 0x000008B4
Start Time: 13:54:43.671       Call Duration 00:00:00.079
ibsta: 0x100       iberr: 0             ibcntl: 10(0xa)

62.  ThreadIbcntl()

Process ID: 0x0000113C         Thread ID: 0x000008B4
Start Time: 13:54:43.750       Call Duration 00:00:00.000
ibsta: 0x100       iberr: 0             ibcntl: 10(0xa)

63.  ibwrt(UD3, "K0K3K5K9..", 10 (0xA))
Process ID: 0x0000113C         Thread ID: 0x000008B4
Start Time: 13:54:43.765       Call Duration 00:00:00.125
ibsta: 0x100       iberr: 0             ibcntl: 10(0xa)

64.  ThreadIbcntl()
Process ID: 0x0000113C         Thread ID: 0x000008B4
Start Time: 13:54:43.890       Call Duration 00:00:00.000
ibsta: 0x100       iberr: 0             ibcntl: 10(0xa)

65.  ibwrt(UD3, "F14F18F24..", 11 (0xB))
Process ID: 0x0000113C         Thread ID: 0x000008B4
Start Time: 13:54:43.890       Call Duration 00:00:09.250
ibsta: 0x100       iberr: 0             ibcntl: 11(0xb)

66.  ThreadIbcntl()
Process ID: 0x0000113C         Thread ID: 0x000008B4
Start Time: 13:54:53.140       Call Duration 00:00:00.000
ibsta: 0x100       iberr: 0             ibcntl: 11(0xb)

### READ ###

437.  ibrd(UD3, "*AC/1.0A480V/...", 1024 (0x400))
Process ID: 0x0000113C         Thread ID: 0x000008B4
Start Time: 13:58:52.484       Call Duration 00:00:00.094
ibsta: 0x2100       iberr: 0             ibcntl: 225(0xe1)

438.  ThreadIbcntl()
Process ID: 0x0000113C         Thread ID: 0x000008B4
Start Time: 13:58:52.578       Call Duration 00:00:00.000
ibsta: 0x2100       iberr: 0             ibcntl: 225(0xe1)

439.  ThreadIbcntl()
Process ID: 0x0000113C         Thread ID: 0x000008B4
Start Time: 13:58:52.578       Call Duration 00:00:00.000
ibsta: 0x2100       iberr: 0             ibcntl: 225(0xe1)

[Paul66]

Hi!

I do not know anything about GPIB communication, but i have done some research myself.

According to the instrument manual it say:

bla, bla bla .. the instrument outputs many lines of data . When the whole data transfer is finished the EOI is sent.

According to the NI-488.2 help (Terminating Data Transfer) it say:

GPIB data transfers are terminated either when the GPIB EOI line is asserted with the last byte of a transfer or when a preconfigured end-of-string (EOS) character is transmitted.

If EOI is asserted AFTER the last byte is sent instead of WITH the last byte could this be the reason to my problems?

If EOI is asserted one cycle after the last transfered byte then i guess my GPIB-ENET/100 tries to read one additional byte.

This is probably why i see an extra line which is an empty string that is read from the instrument. I suspect that reading

this extra byte in some way block my instrument from working properly.

OK, my question is:

Is there a way to configure the GPIB-ENET/100 if EOI is not asserted WITH the last byte?

Or is the best solution to terminate read on EOS and define EOS byte as LF?

Any other ideas?

[Lambsauce]

Hello,

If your data transmission termination was not correctly configured, you would get a timeout on the ibrd function, but still get data.  Since your EOS is disabled, it should not be stopping a read early, which is the only other symptom of incorrectly configured termination.  So if EOI did not get detected by the GPIB-ENET/100, there is no reason that the instrument woudl transmit the data again.

I think your instrument is just loading its output queue with data and it happens to be the same datapoint (or the instrument is loading it twice).  Does this behavior happen with multiple controllers or different types of controllers?

-Lamb

[Paul66 · Accepted solution]

Hi!

I do not have the possibility to test with other controllers.

However i found a solution to my problem.

The instrument should output 4 lines of data.

L1 - line with comments

L2 - line with Current values

L3 - line with Voltage values

L4 - line with power values

Reading the first line halts the instrument from performing further measurements.

The measurements in the instrument started again when reading the last line of data (L4)

The problem was that the instrument for some reason also output a fifth line, that was empty.

Reading this 5'th line halted the instrument again.

By configuring the HW to terminate read on EOS, with EOS byte set to LF, i could read the

output buffer from the instrument line by line instead. This way i could just read L1-L4

and the instrument would work again.

The next time i should read data from the instr. i would first read the empty line and then

L1-L4.

Why the instr. outputs an extra empty line will be left unsolved.

My problem is solved.