Skip to content

Connect two FEN20s at the same time #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Fer-ro opened this issue Jul 29, 2020 · 12 comments
Open

Connect two FEN20s at the same time #21

Fer-ro opened this issue Jul 29, 2020 · 12 comments

Comments

@Fer-ro
Copy link

Fer-ro commented Jul 29, 2020

First of all, congratulations on this library, it is very good!
The thing is, I can't connect to two devices
FEN20s at the same time from a PC.
Error:
Only one usage of each socket address (protocol / network address / port) is normally permitted.

Is there any solution for this?

Regards!

@ekorudiawan
Copy link

same issue here when trying to connect two TS-SH controllers, is there any idea to solve?

@jaegenm
Copy link

jaegenm commented Sep 23, 2021

I am having a similar issue as well. I need to connect to multiple devices and send/receive implicit messages. If I change OriginatorUDPPort to anything other than 2222, T_O_IOData is all zeroes. Is there an example showing how to manage multiple device connections?

@jaegenm
Copy link

jaegenm commented Sep 23, 2021

Some additional info:
If I use a unique OriginatorUDPPort for every client object, I can call ForwardOpen for each one, and I can see the actual data in T_O packets in Wireshark. But I get all zeroes out of the T_O_IOData property for every client which I've set OriginatorUDPPort to anything other than 2222.

@ralftar
Copy link

ralftar commented Sep 26, 2021

Originally posted by @ralftar in #16 (comment):

If the library is published on nuget and PRs are welcome, I will contribute with a couple of PRs (including support for multiple implicit messaging devices, connection exception handling)


I have a feeling that this repository is stalled..? Being MIT licensed, some one can of course create a fork, and continue the work. But it requires long time commitment and resources. Also, I think it would be best if @rossmann-engineering, the original author, is still connected to the maintenance in some form.

@Bissetl
Copy link

Bissetl commented Apr 22, 2022

Did any solution to this ever come to light or is the issue still present? I am having the same problem with two AZ-KEP drives

@BLAGit-NP
Copy link

I am having the same problem with two Keyence Camra IV2 and CVX. They are able to communicate simultaneously in explicit mode. But, not in Implicit mode. When I change any .OriginatorUDPPort property from 2222 default, communication stops.

@BLAGit-NP
Copy link

Based on the source code, I suspect the target is not aware that it needs to communicate to a port other than the default.

@BLAGit-NP
Copy link

bool O_T_OwnerRedundant Only for Implicit Messaging True if Multiple Implicit connections are allowed (Standard: TRUE)
bool T_O_OwnerRedundant Only for Implicit Messaging True if Multiple Implicit connections are allowed (Standard: TRUE)

Both properties are True but do not work ...

@myarc-firmware
Copy link

I had the same issue and it looks like the answer is here: https://github.com/campbell-git/EEIP.NET/tree/testing

Since UDP only allows one port per connection, the above repository is a fork from the original, but has an ImplicitConnection which listens on port 2222 while individual clients are added to the listener so when the data arrives, the listener "routes" it to the appropriate place.

I managed to talk to 3 VFDs using Ethernet/IP using that library.

@dadreamer
Copy link

Well, I used @campbell-git's fork too for communication with several EtherNet/IP devices and it works. But I must notice the following. As I mainly work in LabVIEW, parallel branches (threads) of code are common thing there. So first I tried to run all the communication sessions simultaneously and got odd behaviour. In short, ForwardOpen call was returning the same connectionID_T_O for all the devices and I was getting mixed packets for the first device and no packets at all for the second and third device. I worked around it by setting a clear order of execution of the threads in the initialization and inserting a small delay when moving from one code section to another one (1 second was enough for me). In such a way it all works good. I don't know the reason behind that bug though. Just out of curiosity I tried to apply the commit for concurrent read/write of T_O_IOData/O_T_IOData, but seems like it didn't do any good or I did something wrong. Would be nice, if @campbell-git could take a look, if possible.

@BLAGit-NP
Copy link

I asked Gemini. It turned out that he also did not have access to the ODVA Ethernet/IP standard documentation. I instructed him to start a research, to determine whether the Ethernet/IP objects offer a standard setting to change the UDP port 2222. The result of the research:
"There is no indication in the sources that the core communication objects (Connection Object, TCP/IP Object, Assembly Object) offer a standard, universally applicable attribute to change this UDP port."
Based on all this, it seems that the standard does not support changing the default UDP port 2222, therefore it is not possible to create multiple Implicit communications simultaneously in this way.
It seems that https://github.com/campbell-git/EEIP.NET can handle simultaneous Implicit connections to multiple devices, even through a single UDP 2222 port .

@dadreamer
Copy link

dadreamer commented May 9, 2025

I don't know if we can completely trust AI ​​in this matter, but here Marc Bommert writes:

The proper solution for that is to use only one instance of the lib and instruct it to send a "CPF Socket address item" along with your FowardOpen, which would allow you to determine the UDP destination port from the peer's POV, but I don't know if your lib is capable of doing this.

No idea, what that "CPF Socket address item" means. So now we have only Ryan Campbell's solution, which looks more of a workaround (it's a message router, operating on a connection ID's list), but it's smart enough to work normally (except for initialization, maybe). Of course, if you have many free NIC's around, you could assign them individual IP's and use the original library, if this is acceptable for your project.

upd. I think, this is what was meant.

/* Translate function to Common packet format values */
static const value_string cpf_type_vals[] = {
   { CPF_ITEM_NULL,                 "Null Address Item"        },
   { CPF_ITEM_CIP_IDENTITY,         "CIP Identity"             },
   { CPF_ITEM_CIP_SECURITY,         "CIP Security Information" },
   { CPF_ITEM_ENIP_CAPABILITY,      "EtherNet/IP Capability"   },
   { CPF_ITEM_ENIP_USAGE,           "EtherNet/IP Usage"        },
   { CPF_ITEM_CONNECTED_ADDRESS,    "Connected Address Item"   },
   { CPF_ITEM_CONNECTED_DATA,       "Connected Data Item"      },
   { CPF_ITEM_UNCONNECTED_DATA,     "Unconnected Data Item"    },
   { CPF_ITEM_LIST_SERVICES_RESP,   "List Services Response"   },
   { CPF_ITEM_SOCK_ADR_INFO_OT,     "Socket Address Info O->T" }, // <--
   { CPF_ITEM_SOCK_ADR_INFO_TO,     "Socket Address Info T->O" }, // <--
   { CPF_ITEM_SEQUENCED_ADDRESS,    "Sequenced Address Item"   },
   { CPF_ITEM_UNCONNECTED_MSG_DTLS, "Unconnected Message over UDP" },

   { 0,                    NULL }
};

Looking at the sources of EEIP.NET I see that CPF_ITEM_UNCONNECTED_DATA (0xB2) is used everywhere.

commonPacketFormat.DataItem = 0xB2;

No marks of using any other Data Items in the code. So the task is to make a proper packet with CPF_ITEM_SOCK_ADR_INFO_OT (0x8000) or CPF_ITEM_SOCK_ADR_INFO_TO (0x8001) Data Item, send it to the device and hope that it will work. The structure of the Socket Address Info items is as follows:

Structure Field Length (bytes) Byte order
Socket Address Info T → O or O → T Type ID 2 Little-endian
Length 2 Little-endian
sin_family 2 Big-endian
sin_port 2 Big-endian
sin_addr 4 Big-endian
sin_zero 8 Big-endian

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants