Connecting to Localhost

[joshgraff-planted]

Connecting through Pyads on localhost fails. Connection on same PC of beckhoff CPP library succeeds, and connection from a remote host succeeds.

I can run the same python script on the windows kernel, and on the Windows Subsystem for Linux, both on the same physical machine as my twincat instance. The errors for each are shown below and happen continuously on multiple attempts to reconnect: Windows: failed to open port on AMS router WSL: Connection closed by remote host Timeout 1861

I have an instance of Pyads working well on WSL on Windows on a remote host connected over ethernet to another windows PC running the TwinCAT engine.

I have added 127.0.0.1.1.1 -> 127.0.0.1 to the PLC router through the GUI (I don't think the addroute works for a PC hosted TC instance?)

I get the distinct impression I'm doing something wrong, but having poured over the documentation (and the github issues), I'm not sure what it could be.

test_pyads.txt

[chrisbeardy]

The WSL use case is certainly unique here and not something we have looked at, I wonder if the way it translates the localhost/ethernet layer is causing some issues. Dis you say the Beckhoff c++ works from within WSL conneting to localhost?

You ideally should not need to create a route when connecting to localhost.

What version of python are you using, there have been reports that one version did not like connecting to localhost?

see #315

[joshgraff-planted]

It's interesting because it's happening both on the windows partition and the WSL.

The Beckhoff C++ works from the bare Windows host. I haven't tried it from WSL yet.

My python version is a bit tricky. I am pretty bad at using venv, so it's all over the place. Remote PC WSL (working connection, pyads on WSL): python3.8 Local PC Windows (Failed to open port on AMS router): python3.9 Local PC WSL (ADS 1861, connection closed by remote host): python3.10

Python3.10 is a virus, I cannot for the life of me keep it off my PC (I'm not a package manager pro, I'm sure there are better ways lol).

[joshgraff-planted]

I executed my script with python3.8 (in venv) on the WSL host and found the same result.

[joshgraff-planted]

I started up a virtualbox running Ubuntu 20.04, and was able (again with some router finagling) to get a positive connection over ADS.

Looks like I'm having trouble connecting to Localhost with PYADS from any host/machine. Weird that I can connect from a remote host.

[chrisbeardy]

I recommend learning how to use venv properly, its a real must if working with python regularly on different projects, real python have a few good tutorials https://realpython.com/python-virtual-environments-a-primer/

On windows, start and activate a new python 3.9 venv, install pyads in it, make sure your PLC is in run mode and try the following:

pyads.open_port()
ams_net_id = pyads.get_local_address().netid
pyads.close_port()
port = 851
plc = pyads.Connection(ams_net_id, port)
var_name = X # replace with actual var name
plc.read_by_name(var_name)

If you still can't connect, then something is an issue here, possibly with the Beckhoff install itself. Or some PC setup somewhere.

[chrisbeardy]

@joshgraff-planted have you solved your problem?

[joshgraff-planted]

@chrisbeardy I have found a workflow that enables me to develop. I spool up a Virtualbox and SSH my vscode session into it. Thusfar, this is the only configuration that has worked.

Venv didn't have an impact on the execution. If I'm the only person to experience this issue, you can close it out as I've found a workaround. The actual problem, however, is not resolved.

[RobertoRoos]

At the risk of stating the obvious: specifically from WSL, the TwinCAT system is not localhost. The Windows host has a different IP from the Linux subsystem. So you would have to connect to an IP that looks like 172...*, and add the necessary routes for it.

[captain-yoshi]

I think you are right but only for WSL2. A virtual network adapter is created with the IP that looks like 172...*.

But you can't run TwinCAT in run-mode with WSL2, because it requires Hyper-V.

---

I think that WSL1 uses the localhost.

This is a file generated by WSL1 for Ubuntu 20.04 :

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateHosts = false
127.0.0.1       localhost
127.0.1.1       DESKTOP-59NOAGT.localdomain     DESKTOP-59NOAGT

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

And when sniffing packets I only see packets coming from/to the localhost adapter.

[chrisbeardy]

@joshgraff-planted can i ask you to close this issue as you have a workaround to help manage the issue tracker as your bug seems pretty unique. Thanks.