I have an IPC with 2 ethernet ports and 1 Wi-Fi. I'm using ModbusTCP with the ethernet port named "enp2s0" connected to my remote I/O. This works fine when testing with Python and also works with CODESYS, but CODESYS is only able to scan for the Linux SoftPLC when I turn off the "enp2s0" interface. In other words, I can't get online with the IDE if I want my ModbusTCP comms to run with CODESYS.
I'm using a Linux SoftPLC that has the following entry in CODESYSControl.cfg, hoping that this will allow me to connect with "enp1s0" or "wlp3s0", and leave "enp2s0" for field comms, but this seems to only make the source IP of the ModbusTCP comms to be bound to "enp2s0". That last point is the case only if I don't restart the service, but if I do restart the service after changing the config file, the source IP for the ModbusTCP comms then becomes the one for "enp1s0", which is very confusing to me:
On the device list, I only have "enp2s0" given as the ethernet device that has the ModbusTCP master & slave beneath it, shown in Screenshot 1.
On the IPC, I can ping the ModbusTCP client (remote I/O) from "enp2s0", and I've attached a Wireshark capture of running ModbusTCP from the CODESYS runtime as Screenshot 2, 3 & 4 (again, I can't get online when this is running, I have to turn off "enp2s0" to connect even when it's idle and I don't have an active TCP session with my Python tests). Like I explained above, the source IP is "enp1s0", even though the ethernet device on the project is "enp2s0". I was lucky to catch the red message that showed the source IP that makes sense to me (the one for "enp2s0"), but for some reason that connection was reset and I never saw that packet again.
I've also tried this with Auto-reconnect both enabled & disabled, for the ModbusTCP Master device. I also have to turn off "enp1s0" and then turn it on, just so that I can have the ModbusTCP comms running from "enp2s0" (which is not intuitive in any way to me, I'd love some help understanding that phenomenon as well) in the weird manner that I've described above.
I would be very appreciative if someone can help me figure out this pickle. I'd love to just connect to CODESYS through my Wi-Fi interface and leave my ethernet ports for field comms.
I've also noticed that when I turn off "enp1s0", suddenly the source IP for the ModbusTCP changes to that of "enp2s0", which is what makes sense to me. When I turn it back on, the source IP remains that of "enp2s0".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's all good btw, learned that the runtime doesn't isolate the networks that are involved so changing the ethernet subnets away from the Wi-Fi's subnet was all I needed (maybe some config file changes helped, can't say for certain)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have an IPC with 2 ethernet ports and 1 Wi-Fi. I'm using ModbusTCP with the ethernet port named "enp2s0" connected to my remote I/O. This works fine when testing with Python and also works with CODESYS, but CODESYS is only able to scan for the Linux SoftPLC when I turn off the "enp2s0" interface. In other words, I can't get online with the IDE if I want my ModbusTCP comms to run with CODESYS.
I'm using a Linux SoftPLC that has the following entry in CODESYSControl.cfg, hoping that this will allow me to connect with "enp1s0" or "wlp3s0", and leave "enp2s0" for field comms, but this seems to only make the source IP of the ModbusTCP comms to be bound to "enp2s0". That last point is the case only if I don't restart the service, but if I do restart the service after changing the config file, the source IP for the ModbusTCP comms then becomes the one for "enp1s0", which is very confusing to me:
[SysSocket]
Adapter.0.Name="enp2s0"
Adapter.0.EnableSetIpAndMask=1
On the device list, I only have "enp2s0" given as the ethernet device that has the ModbusTCP master & slave beneath it, shown in Screenshot 1.
On the IPC, I can ping the ModbusTCP client (remote I/O) from "enp2s0", and I've attached a Wireshark capture of running ModbusTCP from the CODESYS runtime as Screenshot 2, 3 & 4 (again, I can't get online when this is running, I have to turn off "enp2s0" to connect even when it's idle and I don't have an active TCP session with my Python tests). Like I explained above, the source IP is "enp1s0", even though the ethernet device on the project is "enp2s0". I was lucky to catch the red message that showed the source IP that makes sense to me (the one for "enp2s0"), but for some reason that connection was reset and I never saw that packet again.
I've also tried this with Auto-reconnect both enabled & disabled, for the ModbusTCP Master device. I also have to turn off "enp1s0" and then turn it on, just so that I can have the ModbusTCP comms running from "enp2s0" (which is not intuitive in any way to me, I'd love some help understanding that phenomenon as well) in the weird manner that I've described above.
I would be very appreciative if someone can help me figure out this pickle. I'd love to just connect to CODESYS through my Wi-Fi interface and leave my ethernet ports for field comms.
I've also noticed that when I turn off "enp1s0", suddenly the source IP for the ModbusTCP changes to that of "enp2s0", which is what makes sense to me. When I turn it back on, the source IP remains that of "enp2s0".
It's all good btw, learned that the runtime doesn't isolate the networks that are involved so changing the ethernet subnets away from the Wi-Fi's subnet was all I needed (maybe some config file changes helped, can't say for certain)