-
Notifications
You must be signed in to change notification settings - Fork 101
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
Unable to talk to two devices simulataneously #66
Comments
@ashwinmudigonda2 Did you find a solution here? |
I did a deep dive into the library code and I think I found the reason why multiple instances doesn't work. The solution sounds simple, just use one socket for all connections and use I can see two possibilities to implement a solution:
Hope this helps. I'm trying to do a "quick fix". But for a clean solution there should be some discussion. Btw. Is there any simulator (Python or so) for devices with class 1 connections? Would be simpler for development than always using multiple HW-devices |
@chruetli thanks for the analysis. I decided to pass over this library and switch to a Modbus based solution. It was easily extensible and more stable. |
@chruetli I am facing same issue, and your analysis is logical, do you have a quick fix? |
@sriharshav No, at the moment I cannot provide you with a quick fix. |
I managed to get this to work. In my system, there is one device with an 8-bit addressing scheme, and another with a 16-bit addressing scheme. It was only implicit IO that I needed.
This limits the ability to connect to multiple adapters. The UDPBoundSocket binds to the local IP address and the port. I fixed it so that the local NIC IP is passed. This way, all inbound traffic is routed based on the received connection Id. With the setBeginReceive handler, the connection Id is at index 0. There are also general changes to forwardClose and constructors based on the updated map structure for instance variables, as noted in point 2. It works with both Balluff EIP and Banner Bar Code simultaneously. For sending, it opens one UDP port per device, but for receiving, it reuses the same UDP bound socket for all devices. |
I the meantime I also came to a "quick" fix. I tried to extract all changes from my working code intot the following repo master...chruetli:EIPScanner:mruetti-multiple-connections-fix. There maybe some flaws (and there are still debug-statements). |
@sriharshav One point I have problems with is the reconnect mechanism when a connection was lost. E.g. disconnecting the Ethernet cable. Does your implementation handle this case out-of-the-box? |
@sriharshav Would it be possible to see your code? |
Thank you @chruetli for your "quick fix"! I tried to fix the remaining issues with the reconnect. I am not aware of the whole EIP spec and I did not understand everything, but I discoverd some lifetime issues with the |
I have 2 EthernetIP devices (both TURCK models) with 2 distinct IP addresses. I am able to talk to each of them separately and set bits. But when I try to talk to both of them in the same program, it does not work.
Here is the Connection1 details from the EDS file:
$
[Connection Manager]
Connection1 =
0x04010002, $ 0-15 = supported transport classes
$ --------------------------------------
$ @16 = trigger: cyclic
$ 17 = trigger: change of state
$ 18 = trigger: application
$ 19 = trigger: reserved
$ --------------------------------------
$ 20-23 = trigger: reserved
$ --------------------------------------
$ 24 = transport type: listen-only
$ 25 = transport type: input-only
$ @26 = transport type: exclusive-owner
$ 27 = transport type: redundant-owner
$ --------------------------------------
$ 28-30 = reserved
$ 31 = Client = 0 / Server = 1
$ --------------------------------------
0x44640405, $ @0 = O->T fixed size supported
$ 1 = O->T variable size supported
$ @2 = T->O fixed size supported
$ 3 = T->O variable size supported
$ ---------------------------------------
$ 4-5 = O->T number of bytes per slot (obsolete)
$ 6-7 = T->O number of bytes per slot (obsolete)
$ ---------------------------------------
$ 8-10 = O->T Real time transfer format
$ 11 = reserved
$ --------------------------------------
$ 12-14 = T->O Real time transfer format
$ 15 = reserved
$ --------------------------------------
$ 16 = O->T connection type: NULL
$ 17 = O->T connection type: MULTICAST
$ @18 = O->T connection type: POINT2POINT
$ 19 = O->T connection type: reserved
$ --------------------------------------
$ 20 = T->O connection type: NULL
$ @21 = T->O connection type: MULTICAST
$ @22 = T->O connection type: POINT2POINT
$ 23 = T->O connection type: reserved
$ --------------------------------------
$ 24 = O->T priority: LOW
$ 25 = O->T priority: HIGH
$ @26 = O->T priority: SCHEDULED
$ 27 = O->T priority: reserved
$ --------------------------------------
$ 28 = T->O priority: LOW
$ 29 = T->O priority: HIGH
$ @30 = T->O priority: SCHEDULED
$ 31 = T->O priority: reserved
$ --------------------------------------
,,Assem104, $ O->T RPI, size in bytes, format
,,Assem103, $ T->O RPI, size in bytes, format
,, $ config #1 size in bytes, format
,Assem106, $ config #2 size in bytes, format
"Exclusive Owner", $ Connection Name
"", $ Fixed data size, input inst. 103, output inst. 104
"20 04 24 6A 2C 68 2C 67"; $ Path
Here are the settings that I modified within ImplicitMessagingExample.cpp:
I modified the ImplictMessagingExample.cpp by wrapping the initialization, open, close, set and get bits into a class and associated functions.
Example:
This does not throw any errors. Output:
However, when I try to set the 0th bit for one of the devices.
I tried to launch each device in its own process. I had a bit toggle every second for a second. The moment the second device received the bit, I see this on the first one's log:
And the first one stops responding.
Expected behavior
I expect the library to be able to set the bits on each of the devices independently.
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: