PoE Ethernet GPIB Adapter – Open Source Project, now public

[Kofen]

This is interesting and I will create a debug build with some serial we can log.

Trying to get response, gets me one of the first try:
^{➜  ~ nc 192.168.30.103 1234
++ver
AR488 GPIB controller, ver. 0.53.03, 08/04/2025}

I will fire up the VM windows tomorrow to test putty.
I have two adapters up now that logs mem and number of sockets in use and state over serial.
Will clean it up a bit and post a hex of a debug build for you Soulman unless I can recreate it on my end.

There is a limit of max open connection on the ethernet chip of 8 clients, but there is logic to close dead sockets, but I'll have to do a review of it.

[The Soulman]

Nice, although I really don't want to use the adapter on this zte router but have to for the lack of being able to setting a fixed ip-address.
But will be happy to assist as it may help other users.

[Kofen]

Nice, although I really don't want to use the adapter on this zte router but have to for the lack of being able to setting a fixed ip-address.
But will be happy to assist as it may help other users.

Nice, need some help to solve this will help others users, I have not been able to locate any zte routers locally to recreate, so I need some community help here to make it more roboust.

Btw, you can now try fixed ip if you like, configured over the serial interface. Example:
<sup>➜  ~ picocom -b115200 /dev/tty.usbserial-1230
picocom v3.1

port is        : /dev/tty.usbserial-1230
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        :
omap is        :
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready
Ethernet2GPIB Gateway v1.1 (AR488 v0.53.03)

- SRAM left: 5098
MAC Address: E8 EB 1B 1B 27 FD
Configuring and Starting GPIB bus...
Waiting for DHCP...
IP Address: 192.168.30.103
Starting Prologix TCP server on port 1234...
Starting Web server on port 80...
Starting Serial Menu...
Setup complete.


1 - Set IP address
? - Menu

>1
  Current IP Address: 192.168.30.103
Configured IP Address: via DHCP.
Enter the desired IP address (0.0.0.0 means: use DHCP):


>10.0.0.1
         IP Address will be set to: 10.0.0.1
You will need to reboot now.</sup>



Reboot needs to be done with the switch for now, looking into if the bootloader will give me watchdog controll without breaking, working progress, but at least possible to set it now.

[Kofen]

Quick update on the adapter "time out" after being connected for a while, still not able to reproduce, have several on test and some have been left totally alone if that could trigger it.
Have to finish the debug code for you Soulman now.

[voltsandjolts]

Like most bench dmm's, my keithley 2000 can save readings to a buffer memory, which can be read after the acquisition is complete. This works fine over usb-serialport and over usb-gpib with the Twilight AR488. With the LXI firmware I'm only getting 256 bytes maximum (i.e. 16 ascii format readings) when I try to read the buffer memory with kei2000.query("trace:data?"), so truncated response. I'm not setup to try with the PRLGX compatible firmware. Has anyone else tried reading >256 bytes?

[bateau020]

Yes, you caught a limitation to the buffer size in the vxi version. I will look into that. Not easy to solve for all response sizes, and streaming will likely never be possible, but better/bigger than now is possible.

Prologix might not have that issue.

[voltsandjolts]

This PoE adapter with PRLGX firmware seems to have the same issue, but with 1024 byte limit.
(might be my setup, so please confirm for yourself)

Using the usb-gpib adapter Twilight AR488 a full buffer of 1024 readings (about 16KiB) can be retrieved OK.

[Kofen]

That the VXI have limit is understandable from looking at the code(And I am not sure about the correct way to fix this for VXI, but as the agilent gateway don't have this issue so I am sure we can fix it, need to read up a little).
But the latest prologix version should be okay, this build: https://github.com/Kofen/PoE_Ethernet_GPIB_Adapter/releases/download/2.0.0/prologix_488.hex
Can you confirm which version you are using, in version 2.0.0 I specifically implemented a fix that sends the buffer if it either reaches 1024 or is terminated with \n so that you should be able to read the whole buffer, you just get two packets(or however long the data array is) I have a Keithley 2002 so I guess it has the same function so I can try to recreate it on my end as well.

What tools are you using to fetch the data?

EDIT: The AR488 stock is a bit different, it is not fully prologix compliant in that it's spits out data as soon as it arrive, it don't wait for the line termination or buffer it. I added this function to my fork as my scripts was not able to work out of the box and it makes it more compliant with Porlogix ethernet adapter.

[voltsandjolts]

Hi Kofen
The adapter webpage reports "Ethernet2GPIB Gateway v1.1 (AR488 v0.53.03)" so I need to update to v2.0.

I'm using python and reading buffer data with "results = gpib.query("trace:data?")" (see attached).
I don't see a keithley command that allows to read a portion of the results buffer, you just get all recorded data at once.
How do I split this into multiple reads?

[Kofen]

Hi Kofen
The adapter webpage reports "Ethernet2GPIB Gateway v1.1 (AR488 v0.53.03)" so I need to update to v2.0.

I'm using python and reading buffer data with "results = gpib.query("trace:data?")" (see attached).
I don't see a keithley command that allows to read a portion of the results buffer, you just get all recorded data at once.
How do I split this into multiple reads?

You were in luck as I had a 2182a right by me that supports this.
The FW is right when you have web interface, forgot to update fw revision in code...

So the problem is not the adapter, but that you only ask for one measurment, two conditions can give you that, either a line termination or a buffer overflow, then it purge it over the connection.
Since you only ask for one, you only get the first 1024 bytes, it might be the issue with the VXI as well, but I have not looked into that, I just ran your prologix code, I made a quick change and this gives you all the data, it request data until the line termination is met, it is needed for that particular python lib.

Output from test: Readings requested:  120
Readings retrieved:  120
Number of bytes retrieved: 1920

The change to your code:
<sup>print("Retrieving...")
gpib.write("trace:data?")

buffer = ""  # Start with an empty string

# Read chunks until we get a full response with \n
while '\n' not in buffer:
    buffer += gpib.read()

print("Raw buffer received:", buffer)

# Now split the buffer into readings (assuming comma-separated)
voltages = buffer.strip().split(',')  # Remove whitespace and split

print("Voltages:", voltages)

print("Readings requested: ", number_of_readings)
print("Readings retrieved: ", len(voltages))
print("Number of bytes retrieved:", len(buffer.encode('ascii')))
gpib.write("trace:clear; feed:control next")
gpib.close()</sup>


So for at least the prologix version, it is a code issue on the top side, not adapter function. Could you try the same approach with your VXI code? I'll have to clear my bench a bit to pull out a boat anchor to help another fella out.

Hope this helps!

EDIT: When I say need for that lib, I did not read the docs or the code, I just observed the behaviour and did a quick patch, maybe there are hints in the docs.

[voltsandjolts]

Thanks Kofen.

I haven't actually used prologix before, I normally use pyvisa, which has a nice function to return all data as list of floats;
voltages = kei2000.query_ascii_values("trace:data?")
which works fine with usb-serial and twilight ar488, as one big read.

Maybe it's the additional network functionality that requires multiple reads, IDK.
Anyway, if multi-read fixes it, that's great.
I'll give it a try after the weekend.

Sounds like you have some nice kit...K2002, K2182. I do like the Keithley stuff.

Regards,

[Kofen]

Could you post you pyvisa code that failed so I can take a look as well? For the VXI adapter version for the adapter that is.

[bateau020]

It would be nice to match the adapter's behavior with how a dmm6500 behaves. I can work on that, but it'll take a bit of time, on the road now.

[Kofen]

Thanks Kofen.

I haven't actually used prologix before, I normally use pyvisa, which has a nice function to return all data as list of floats;
voltages = kei2000.query_ascii_values("trace:data?")
which works fine with usb-serial and twilight ar488, as one big read.

Maybe it's the additional network functionality that requires multiple reads, IDK.
Anyway, if multi-read fixes it, that's great.
I'll give it a try after the weekend.

Sounds like you have some nice kit...K2002, K2182. I do like the Keithley stuff.

Regards,

I realize I was a bit short in my reply yesterday.
Over GPIB there are usally two ways to know when the instrument is done sending/has cleared it buffer.
The gpib bus is quite robust as it has it own hardware line for this EOI (End Of Identify).
Normal behaviour of the Talker(the instrument sending data), is to raise this line to mark the end of a message/buffer.

This is the prefered way and is used on most instruments.

The other method is a line termination in the message string, usally LR/CR (Hence the \n hack in your code yesterday).
This is not the prefered method as this is not a requirement in the GPIB specification so the manufacturer is not required to enforce this, and when you ask for raw binary data of many instrument, you will not get the line termination.

The prologix does support EOI, but you need to handle it on the topside in the driver/library.
Prologix is a very low level bridge, made as transparent as possible so the logic handling is shifted to the driver, aka the user.

Since I have not used the library you are using, beside a quick test to confirm it was compatible with the adapter, I opted to hack in the \n as I know this behaviour is supported by the DMMs in question.
But it is not a fix for all. I don't know how it handles EOI in the background, if at all.

Since the adapter is made to be 100% compatible with prologix ethernet adapter, I do not wish to make any changes on the fw on the adapter to enforce other behaviour as this will just break everything and make it harder for people(aka me) to switch adapter depending on which one is closest in my drawer.

Now more interesting is the VXI apporach, here we have much more options and this is something me and bateau020 need to look at and discuss when he is back.
The goal should not have it mimic a DMM6500 as then we create an "instrument" for the instrument, but rather we should study the behaviour of the Agilent GPIB Gateway as this is a very robust device(and I have one for easy testing comparison). Since we do not need to clone a speific device behaviour, we are much more free to decide how to handle interactions on the instrument side. But every smart logic we add to the adapter, makes for increased risk of incompaible behaviour of older instruments / instruments that do not enforce thru GPIB standard implementation.

I'll admit, I have not yet fully dug into the VXI code for the adapter, as bateau020 did the heavy lifting there and I have focused on fixing bugs in the prologix parts and support.

When it comes to the AR488 serial adapter behaviour, I have no way of knowing why your script works with that, as I have not seen the code. IRCC, it spits out byte for byte on the serial bus so I am sure the heavy lifting is done topside there as well.

What is very important to me is the feedback from all the users, that helps define what is needed for this adapter to work for all of you, regadless of Python / code foo.
Maybe looking into the pyvisa prologix fork and get that pushed to main is good enough. Maybe we need to create a more robust prologix python library to suit more of the use cases?
I don't know, but with feedback and help with issues in this thread we will figure it out, but I hope for some understanding that I need some time to get the overview.

What I do wish for all of you, if you have issues, write it in the thread, not on PM, as this helps us share the challenges so we all learn, and then we can compile it to an FAQ.

Creating my first "popular" open source project is a big learning curve, the most obvious thing that is missing is good documentation, that should have been done before launching, but I did not know any better and I am working on it. But right now I am in a bit of catch22 as I try to write docs to help, but also have a lot of support cases to get you guys running. This is in no way of a complaint, I am very grateful for your orders and support, I just need some patience from you guys. I am truly humble that you have trusted me and supported me.

[voltsandjolts]

Apologies for this quick terse reply, I don't have time this evening!

When it comes to the AR488 serial adapter behaviour, I have no way of knowing why your script works with that, as I have not seen the code.

pyvisa is bit clunky with PRLGX interface, but this code works with Twilight AR488 usb-gpib and retrieves all 1024 (full buffer of k2000) in one read:

Code: [Select]

import time
import pyvisa as visa
from pyvisa.constants import StopBits, Parity, ControlFlow

rm = visa.ResourceManager() # default backend

ar488 = rm.open_resource("ASRL9::INSTR", baud_rate=115200, data_bits=8, flow_control=ControlFlow.none, stop_bits=StopBits.one, parity=Parity.none)
ar488.timeout = 10000 # milli-seconds
ar488.read_termination = '\n'
ar488.write_termination = '\n'

ar488.write("++mode 1")
ar488.write("++addr 20")
ar488.write("++auto 0")
ar488.write("++eoi 1")
ar488.write("++eos 3")

ar488.write("*rst; *cls")
ar488.write("*idn?")
print(ar488.query("++read eoi"))

interval_in_ms = 10
number_of_readings = 1024
ar488.write("volt:dc:rang 10")
ar488.write("func 'volt:dc'")
ar488.write("status:measurement:enable 512; *sre 1")
ar488.write("sample:count %d" % number_of_readings)
ar488.write("trigger:source bus")
ar488.write("trigger:delay %f" % (interval_in_ms / 1000.0))
ar488.write("trace:points %d" % number_of_readings)
ar488.write("trace:feed sense1; feed:control next")
ar488.write("initiate")
ar488.write("*TRG")

print("Sampling", end='')
spin = True
while(spin):
    time.sleep(0.5)
    print(".", end='', flush=True)
    ar488.write("status:measurement?")
    if ((512 & int(ar488.query("++read eoi"))) == 512):
        spin=False

print("\nRetrieving...")
ar488.write("trace:data?")
voltages = ar488.query("++read eoi")
ar488.write("trace:clear; feed:control next")
ar488.close()

print(voltages)
print("Readings requested: ", number_of_readings)
print("Readings retrieved: ", voltages.count(",") + 1)
print("Number of bytes retrieved:", len(voltages.encode('ascii')))



pyvisa with your adapter in VXI form, works for at most 16 samples in one read:

Code: [Select]

import time
import pyvisa as visa

rm = visa.ResourceManager() # default backend

kei2000 = rm.open_resource("TCPIP::192.168.1.84::gpib,20::INSTR")
kei2000.timeout = 10000 # milli-seconds
kei2000.read_termination = '\n'
kei2000.write_termination = '\n'

kei2000.write("*rst; *cls")
print(kei2000.query("*IDN?"))
kei2000.write("func 'volt:dc'")

interval_in_ms = 100
number_of_readings = 16
kei2000.write("status:measurement:enable 512; *sre 1")
kei2000.write("sample:count %d" % number_of_readings)
kei2000.write("trigger:source bus")
kei2000.write("trigger:delay %f" % (interval_in_ms / 1000.0))
kei2000.write("trace:points %d" % number_of_readings)
kei2000.write("trace:feed sense1; feed:control next")
kei2000.write("initiate")
kei2000.write("*TRG")

print("Sampling", end='')
while (512 & int(kei2000.query("status:measurement?")) == 0):
    time.sleep(0.5)
    print(".", end='', flush=True)

print("\nRetrieving...")
voltages = kei2000.query_ascii_values("trace:data?")
kei2000.write("trace:clear; feed:control next")
kei2000.close()

print(voltages)
print("Readings requested: ", number_of_readings)
print("Readings retrieved: ", len(voltages))


Code: [Select]

KEITHLEY INSTRUMENTS INC.,MODEL 2000,4345022,B01  /A02 
Sampling.....
Retrieving...
[-0.0952147802, -0.0677902183, -0.0403273559, -0.0134135439, 0.013183989, 0.0400936004, 0.0662085656, 0.0922829095, 0.115487853, -0.106685633, -0.0747559541, -0.0490926409, -0.0234869743, 0.00241608643, 0.0279617216, 0.0532273171]
Readings requested:  16
Readings retrieved:  16


[H.O]

After about one week of uptime mine was suddenly unreachable. No Telnet, no ping, no web-interface.
Checked my router and sure enough the adapter had gotten a new IP-address. Using that address I can reach it but now the LED on the adapter is red all the time while previously it was breathing green and, I believe, turning purple when there was an open connection.

[bateau020]

Yes, red means there is a network problem or that the ip address got changed since startup. A reboot will reset the led color. It works, but you had to reconnect the client. So an action was needed anyway. It is best to fix the ip address via your dhcp server.

Note to myself: adapt the led controller: reset the led if you see a connection after an ip address change.

[bateau020]

Support for large queries is imminent. If anyone wants to test it (you will need to compile it), be my guest. See the test branch https://github.com/Kofen/PoE_Ethernet_GPIB_Adapter/tree/7-allow-large-reply-when-using-vxi

[WaveyDipole]

With the help of HKJ, I managed to get this interface working with TestController and was able to control my Agilent 34401A.

I have attached a screenshot of the configuration. In the GPIB pop-up, it is first necessary to select the AR488Lan adapter from the list. Apparently AR488Lan is an existing project that provides a TCP connection over WiFi to the AR488. One then provides the IP address and then adds the port number 1234 as a parameter in the Settings field in the the format port:1234, which overrides the default port (23) for AR488Lan.

For some reason it did fail on the first attempt and the meter just beeped, but worked fine on the second attempt. I tested Windows and Linux and it worked on both.

[Kofen]

bateau020 is currently working hard on bug fixes on VXI and I am looking into other minior bugs, there should be a new release very soon. Thanks to all for your feedback, it is extremely valuble to make the design robust.

Also a new batch of pcba in, and plenty of thru hole parts so for any one that needs an adapter, consider it fully stocked now, lead time to ship is max 2 days from order date.

[gentlearc]

Fantastic project. I will be PM'ing as soon as I have the post count. I noticed the w5500 product family appears to be limited to '8 independent sockets'. Is this the hardware limitation for the number of simultaneous devices, or is it more complicated than that? 4 is just fine, I am just curious. 4 per box is still an economical solution.

[bateau020]

Slightly more complicated.


The number of instruments you can connect:

The GPIB bus protocol itself allows up to 30 instruments. This does not mean you can effectively control 30 instruments via the gateway, as the gateway device has its electrical limits, depending on the length of the cables and instruments themselves. And also the software has its limits:

The Prologix service will allow only 1 client software connection and will allow you to interact with only 1 instrument at any given time: you must switch between the instruments you want to address.

The VXI-11 service will allow you to set up multiple instrument connections at the same time. It will allow your client software to be easier to set up and maintain, and will make it easier to interact with multiple instruments, whether they are connected to the gateway or not. There is a however a limit to the number of open connections to the gateway:

- up to 4 instruments: no restriction
- 5 instruments: only if you do not use the web server
- 6 instruments: only if you disable the web server (use the compile option -DDISABLE_WEB_SERVER) (but the web server is nice, see screenshot in the git repo)
- 7 or more: not possible via VXI-11

This does not mean that you cannot physically connect more instruments to the gateway, it just means that you cannot connect to more of them, via your client software, at the same time.

Also, be aware that the GPIB bus is a shared bus. Even if you have connected to multiple instruments, you might encounter problems if you run multiple commands or queries at the same time, via for example multiprocessing or threading.

[voltsandjolts]

This does not mean that you cannot physically connect more instruments to the gateway, it just means that you cannot connect to more of them, via your client software, at the same time.

Can you please elaborate on the meaning of "at the same time"?

Do you mean that if already at max connections, and a new connection is established, then the oldest connection is closed?
So in pyvisa, older connections would error if you tried to use them, e.g.

Code: [Select]

inst_1 = rm.open_resource("TCPIP::192.168.1.84::gpib,21::INSTR")
inst_2 = rm.open_resource("TCPIP::192.168.1.84::gpib,22::INSTR")
inst_3 = rm.open_resource("TCPIP::192.168.1.84::gpib,23::INSTR")
inst_4 = rm.open_resource("TCPIP::192.168.1.84::gpib,24::INSTR") # 4th instrument, all good
inst_5 = rm.open_resource("TCPIP::192.168.1.84::gpib,25::INSTR") # 5th instrument, but don't access the webserver!
inst_6 = rm.open_resource("TCPIP::192.168.1.84::gpib,26::INSTR") # 6th instrument, ok if using compile option -DDISABLE_WEB_SERVER
inst_7 = rm.open_resource("TCPIP::192.168.1.84::gpib,27::INSTR") # inst_1 can't be used, connection closed


[bateau020]

Do you mean that if already at max connections, and a new connection is established, then the oldest connection is closed?

no, the additional ones should fail to connect and fall in timeout. Existing connections will not be closed.

[voltsandjolts]

So to talk to a different set of instruments (on the same bus) you would need to close existing connections.
Would pyvisa inst.close() work for this?
Or would it need power cycling of the adapter, or maybe unplug/reconnect ethernet cable?
Thank you.