So far, I have been acquiring data in the lab through a LabView program, managing the communication with different instruments connected to that computer. Since covid-19, and the necessity to alternate presential and remote working, this solution was not ideal. It would necessitate to remote-control the local computer (through VNC or RDP), that forwards a lot of unnecessary data to perform and analyse a few experiments.
I recently came up with a new setup, that I hope will be easier to manage remotely through robust technologies.
The control/data acquisition instruments are all connected to a linux server via LXI (lan extension for instrumentation), and controlled via a suite of python programs, activated via ssh. This now allows me to connect to the server from any location to control my data acquisition setup, while transmitting only a few bits of text data. I decided to get rid of a monitor to actively prevent myself from carrying graphic measurements from this local server that would be hard to access remotely.
My setup is now structured as follows:
- a linux server, connected to:
- lan to the university network, with a fixed IP
- a lan switch connected to all other equipments
- the LXI equipments, connected to the lan switch
- every other computer connected on the University network (or vpn), from which I can send commands to the server. Here, I could have connected all the LXI to the main University network, but I preferred keeping this switch for safety reasons.
Since I have no monitor on the server, managing the communication can be quite
tricky. Here are a few commands to connect to a new ethernet server:
The nmcli program has a unified interface to take care of this. Everything can be
done in ssh without fear of losing the connection (as long as you operate on the
right interface. You can use
nmcli device show to get information about the
connected devices, and
nmcli connection show to get an overview on the active
~ : julien $ nmcli connection show NAME UUID TYPE DEVICE profile_PCIeth d718ee0c-548b-4d17-a4a4-0eaee2f0f22b ethernet enp0s31f6 ~ : julien $ nmcli device show DEVICE TYPE STATE CONNECTION enp0s31f6 ethernet connected profile_PCIeth enxa0cec8c0b3b3 ethernet disconnected -- lo loopback unmanaged --
So far, I have one ethernet cable (
enp0s31f6) connected on the PCI card, with
an active connection, and a USB-eth interface (
enxa0cec8c0b3b3) detected, but
not connected to the network.
The next step is to add a connection profile to the USB-eth interface. This is
achieved with the command nmcli connection add:
~ : julien $ sudo nmcli connection add type ethernet con-name profile_USB_eth0 ifname enxa0cec8c0b3b3 Connection 'profile_USB_eth0' (d94e30c2-ced0-41c9-85c8-0937ccc89f0e) successfully added.
Now I can add this profile to the interface. I chose a fixed IP address: 192.168.0.10 for the server, assuming that all the equipments on that line will have an IP in the range 192.168.0.[0-255].
~ : julien $ sudo nmcli con mod profile_USB_eth0 ipv4.method manual ipv4.addr "192.168.0.10" ipv4.gateway "192.168.0.1" ipv4.routes "192.168.0.1/24 10.10.10.0"
And I activate the connection with the following profile:
~ : julien $ sudo nmcli con up profile_USB_eth0 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/24)
I am now connected to the eth interface. A quick check would give me:
~ : julien $ nmcli con NAME UUID TYPE DEVICE profile_PCIeth d718ee0c-548b-4d17-a4a4-0eaee2f0f22b ethernet enp0s31f6 profile_USB_eth0 d94e30c2-ced0-41c9-85c8-0937ccc89f0e ethernet enxa0cec8c0b3b3 ~ : julien $ nmcli dev DEVICE TYPE STATE CONNECTION enp0s31f6 ethernet connected profile_PCIeth enxa0cec8c0b3b3 ethernet connected profile_USB_eth0 lo loopback unmanaged --
The next step now is to individually set up all the LXI equipments connected to the switch, with the following configuration:
- IP addresses: 192.168.0.[0-255]
- Subnet mask: 255.255.255.0
- Gateway: 22.214.171.124
To check that they are all connected, I am using the simple tool
arp-scan that allows to scan for MAC
addresses on a subnet. On Debian-based distributions, it can easily be installed
sudo apt-get install arp-scan.
~ : julien $ sudo arp-scan --interface=enxa0cec8c0b3b3 --localnet Interface: enxa0cec8c0b3b3, type: EN10MB, MAC: a0:ce:c8:c0:b3:b3, IPv4: 192.168.0.10 Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan) 192.168.0.2 00:01:29:82:00:aa DFI Inc. 192.168.0.3 08:00:11:20:00:aa TEKTRONIX INC. 192.168.0.3 08:00:11:20:00:aa TEKTRONIX INC. (DUP: 2) 192.168.0.4 08:00:11:20:00:aa TEKTRONIX INC. 192.168.0.4 08:00:11:20:00:aa TEKTRONIX INC. (DUP: 2) 192.168.0.5 80:2f:de:00:00:aa Zurich Instruments AG 192.168.0.6 80:2f:de:00:00:aa Zurich Instruments AG 192.168.0.7 80:2f:de:00:00:aa Zurich Instruments AG 192.168.0.8 80:2f:de:00:00:aa Zurich Instruments AG 9 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.9.7: 256 hosts scanned in 1.949 seconds (131.35 hosts/sec). 9 responded
Here I have the dilution refrigerator and magnet controller, connected on IP 126.96.36.199; two Keithley Sourcemeters on IPs 192.168.0.3-4 and 4 lock-ins from Zurich Instruments on IPs 192.168.0.5-8.