Using pylogix from a container running on a Linux VM

[ChristopheLaurent]

Type of issue

• Question

Description of issue

I use pylogix in a container deployed with docker compose. It runs within a Linux VM from my windows laptop. My windows laptop has local IP address 192.168.1.156 with mask 255.255.0.0 and the PLCs have address 192.168.22.10, 192.168.20.10, 192.168.23.10 and 192.168.24.10.
I can read the tags of these PLCs without any problem but I cannot discover the PLCs automatically.
I slightly modified the discover() method in lgx_comm.py to have a better understanding of the issue, adding a couple of traces. I found that discover() method tries to explore the local network from 172.18.0.2 using port 44818, i.e. from the local IP address of the container. I tried to expose the port 44818 for protocol UDP in my container, but it did not help.
I tried to run the same discover() method directly on windows without any container and it works very well.

Does any one already met such an issue with discover() running pylogix in a microservice ?

[TheFern2]

Hey there, I dunno the docker terminology, but this is what chatgpt suggests, basically you bind your laptop IP to the container and also expose 44818 which you already did, so this should work in theory. Let us know if it worked and please share configs and we can add it to our docs for future uses.

https://chatgpt.com/share/676454ef-a624-8004-a54b-42f6f532d490

[dmroeder]

This came up last year too:

#236

[ChristopheLaurent]

Thank you @dmroeder and @TheFern2 , I tried your network based suggestion but it did not work:

services:
  groot:
    image: groot
    container_name: groot-svc
    build:
      context: ${ROOT}/dev-ts-groot
      dockerfile: Dockerfile
    ports:
      - "44818:44818/udp"
    networks:
      pylogix:
        ipv4_address: 192.168.1.100

networks:
  pylogix:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.0.0/16

I noticed it has some impact on the discover method since new fixed IP address is added to the socket list:
addresses=[(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, 'f551acaff243', ('172.18.0.3', 0)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, 'f551acaff243', ('172.18.0.3', 0)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, 'f551acaff243', ('192.168.1.100', 0)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, 'f551acaff243', ('192.168.1.100', 0))]
Unfortunately there is no answer. I don't think I will investigate this approach any further, but simply try to connect explicitly to each known IP address, there are not so many PLCs in my case.

This other approach raises a subsidiary question: how to send a message to a socket already opened on a well known PLC IP address, that will return a similar answer as the build_list_identity, e.g. the VendorID, DeviceID, SerialNumber, etc... ?

[dmroeder]

from pylogix import PLC
with PLC("192.168.1.9") as comm:
    device = comm.GetDeviceProperties().Value
    print(device.ProductName, device.VendorID)

[atodkar]

@ChristopheLaurent did you try host network_mode? In my case if I mention host as network_mode while running container, the Discover is able to find PLCs on local network

[ChristopheLaurent]

Hello @atodkar , thank you for your suggestion. I cannot use host as network_mode in my case, because this mode prevents using networks attribute and my container also needs communication with other micro services using a bridge as networks. Anyway, I will do further tests later on a Linux VM without WSL2 that may not yet support UDP.