Howdy- We’re trying to install the Keysight IO Libs on the OpenTap Ubuntu docker container. There are probably some network packages that need to be installed before hand, because, when trying to install the library in the container, it (the installer) reports the error: “This device is not connected to the network – aborting the installation.”
The container can get to the internet because I was able to download other packages and github projects.
Any idea what it might need?
I checked with our IO Libs support and this is what they said:
IOLS for Linux installer does ping the Google DNS at 8.8.8.8 and if it doesn’t get a response, I’ve seen the installer throw the “This device is not connected to the network - aborting the installation” error. It does that internet connectivity check because it needs to connect to the EPEL repository to install DKMS.
Great, thanks, so I installed “ping” on the container (apt-get install iputils.ping).
Still can’t ping google (by name or by 8.8.8.8), but I will update this thread if I can get past this.
Thanks once again
1 Like
If you are using Python, this is not something we officially support, but it may be easier to get installed:
https://pyvisa.readthedocs.io/projects/pyvisa-py/en/latest/
@brennen_direnzo , yah, I figured that the python approach would simplify things, but our team is probably going forward with the .Net approach.
As for the original attempt to get the KS libs installed on the OT/Ubuntu container, I cannot get the ping command to hit 8.8.8.8 so I have to give up for now on this approach (since the KS installer requires more intricate networking than the opentap/tui installers).
I created the following github project that shows how far I got, namely:
- creating the 18.0.4 Ubuntu/w network utilities
- adding and installing opentap
- adding and installing TUI
- adding but NOT installing KS libraries
If anyone has time to trouble-shoot this, let us know if you can make it work.
Gitlab project:
UPDATE: after restarting docker on my host (a Mac, btw), I can ping 8.8.8.8 from inside the container. Argh!
UPDATE2: After having retarted the docker engine and having the ping work, i was able to install the KS lib inside the container.
1 Like
Cool! So was it just a networking issue? I’m interested to see what you do from here 
Yah, basically a networking thing. Plus, on the Mac I’ve noticed that the Docker engine can get bogged down and misbehave.
Quick question: could we take a test plan that was created using PathWave/C#/VisualStudio and then run it on this docker image with the TUI? (As long as we didn’t do any fancy GUI tricks in the code?)
1 Like
Yes, that would work. You would need to make sure to include the other dependencies as well:
- DLLs of custom plugins
- Bench Settings for any instruments used (Setting\Bench\Default*.xml). This could also be configured in the container.
The best way to do this, I think, would be to create a .TapPackage and include the DLLs, TestPlan, and any other files needed. Then you just have single file to distribute that can be versioned.
In the container you could install that with: tap package install <packageName>
Thanks very much. I might try that with just a very very very simple one-or-two step plan.
1 Like
Did you test out the I/O? Say connecting to some LAN instrument?
Not yet, working with our IT dept. to get a SigGen authorized for our VPN. (working remotely)
Update:
We created a docker image/w the KS libraries and just tried to run a simple python script to hit an instrument. With the Keysight libraries this would not work, but when we installed the pyvisa-py backend instead, (and not install the KSL) we were able to get some scpi commands across. Next step would be to see if we can get TUI working with the pyvisa-py libs and running a single scpi test step.
UPDATE:
I ran out of ideas to try to get the test plan scpi step to execute (the libraries or OT imply that it cannot find the instrument on the network-- I think). We got really really close, even got the ConnectionExpert gui to run inside the container, but I think there is a low-level network configuration that prevents the libraries or OT from finding the device.
So abandoning this effort for now.
2 Likes
Can you share what you did to get the Connection Expert GUI running?
I’ll take a crack at this, maybe later today.
Re the gui: i added the x11-apps and a few other dependent x11 libraries to the docker image and had to twiddle with a few settings on our Mac XQuartz xterm viewer. I sent to you the actual Dockerfile and run.sh script that I used. To make sure that a gui would show up from the xterm, I ran the xclock command first, just to make sure that the clock app pops up.
I’d suspect that for a container running in Docker, using a Linux container on macOS (as the host OS) might only work with SCPI Sockets. Any other protocol/interface may require a device driver which supports that interface, and a device driver needs to be installed on the host OS (macOS in that case). Keysight doesn’t provide IOLS device drivers for macOS. However, SCPI Sockets doesn’t required any IOLS-specific device driver - it just uses TCP/IP which is available intrinsically on the macOS host operating system.
1 Like
Check out the pull request I made on your repo.
I left some comments about how to start the Keysight Instrument Discovery Service, which Keysight VISA depends on before I/O will work, and how to test that the service is up (vifind).
I was able to get the TUI working with a Keysight scope over SCPI Sockets (port 5025) on my Intel Mac. I think your instrument supports the HiSLIP protocol (port 4880), which has a more robust protocol for instrument I/O, so its recommended (TCPIP::<instrument ip / hostname>::hislip0::INSTR). HiSLIP will work inside of the container as well, I’m fairly certain.
2 Likes
I was able to run the SCPI *IDN? command from the container using pyvisa and pyvisa-py and I believe that was with the vxi-11 (I didn’t try the py/py combination/w sockets).
When testing/w the OpenTap stack (OpenTap/KS/TUI) in the container I had also tried the sockets and hislip addresses, but no success there either (same results- instrument could not be found/accesssed).
Can’t remember if I posted this in another thread, and not sure if this helps, but this diagram tries to summarize what worked and didn’t work (doesn’t show all of the varieties, heh-- just the main ones):
w00t!
Starting the discovery service seemed to be the final piece (well, so far, anyway). Also, adding the debug flag to the install of the libraries seemed to fix (or alleviate) the proble of the TUI “hanging” when creating a new instrument. UPDATE: the latter may have also been due to the fact that I had previously not been using an xterm and I switched over to using an xterm. Switching to an xterm probably provided better UX with the TUI.
I was also able to run the ConnectionExpert (ConEx) from the container and have its GUI show up in the xterm. Good job, @alan_copeland !
This is a snapshot of TUI running in the docker container and running a single-SCPI step and hitting the SigGen:
2 Likes
So if there were a way to wget the (latest) OT libraries and wget the (latest) KS libraries from within a Dockerfile, I would post the final summary of this research. But right now it requires downloading the latter libraries “by hand” because I couldn’t find a way to download specific libs from through the Dockerfile.
Maybe the most recent OT and KS libs could be added to the OT CICD docker image as a BETA tag.
1 Like