Connect two FEN20s at the same time

[Fer-ro]

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]

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

[jaegenm]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[sanehost]

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.

@dadreamer, cheers for sharing your experience with using EEIP.NET in LabVIEW — really helpful! I'm also trying to communicate with multiple EtherNet/IP devices and ran into issues with the original EEIP .net library.

Is the .dll from [@campbell-git]’s fork you're using up-to-date, or did you have to rebuild it yourself? Also, aside from serialized initialization, are there any other things I should watch out for?

Appreciate any tips!

[dadreamer]

@sanehost

Is the .dll from [@campbell-git]’s fork you're using up-to-date, or did you have to rebuild it yourself?

You mean the EEIP.dll binary at \EEIP.NET-master\EEIP.NET\LabView Example\ and \EEIP.NET-master\EEIP.NET\LabView Example\Builds\data? No, it's the same as in the original code branch from @rossmann-engineering . You need to compile the dll on your own from the @campbell-git's code. Visual Studio Community worked good for me.

Also, aside from serialized initialization, are there any other things I should watch out for?

Can't remember any other pitfalls here. If your data flow is right, everything works right. I have operated three devices (motor drivers) simultaneously, both implicit and explicit communication. At first, one SocketListener object is created, then the receive socket with the current NIC's IP is created (CreateReceiveSocket), then the common initialization for EEIPClient follows and after ForwardOpen call the client's ID is added to the dictionary (TryAddClient). After that the common communication loop may be entered. For any other device the same SocketListener object is used: TryAddClient is called after the corresponding ForwardOpen.

[johmarjac]

I used a different approach now which is not the way one should use it that way but thats how I workaround this:

I gave my Originators network adapter a second IP address. In the ForwardOpen() function at the bottom where it creates the Udp Receive endpoint, instead of passing IPAddress.Any i pass a fixed ip (the one i added in my network adapter).
That way i can have 2 instances of EIPClient connect to 2 separate devices.

I actually first tried to use a different OriginatorPort but unfortunately somehow i get ICMP packet errors. I can still send data but reading does not work somehow...