Config Assembly in I/O messaging

[Vien Huy Nguyen]

Hi all,

ConfigureExclusiveOwnerConnectionPoint() function requires a Config Assembly, an Input Assembly, and an Output Assembly. Is a Config Assembly usually included in a cyclic I/O messaging? 

I test my device with a few different CIP Scanner software I found online; none of them seem to define the config assembly in the ForwardOpen package. This is giving me problems because when GetExclusiveOwnerConnection() is called, the connection_object->configuration_path.instance_id does not match with the defined Config Assembly 0x97.

Maybe the tools I used are outdated? Please advise.

[stm-at-esd]

Hi,

the ConfigureExclusiveOwnerConnectionPoint() function tells the OpENer stack which assemblies belong to your Explicit Connection.

The config assembly is never included in the cyclic I/O messaging of the "implicit messaging" Exclusive Owner Connection.

The config assembly is only used during the forward open for the Exclusive Owner Connection as an optional parameter.

The following is only from the top of my head to give you an idea why a config assembly exists (cross check with the spec). 

The meaning of the configuration assembly depends on the Device Profile you have selected. Basically the contents of

the config assembly could "configure" the contents of your input and output assembly. Your device wakes up with a

"default" or initial content of the configuration assembly. The client decides if it wants to transmit configuration data

during the forward open or not. If it doesn't transfer configuration data the "default" configuration is kept, in the other

case the content of the configuration assembly is overwritten with the configuration data transmitted during

forward open. 

Please be aware that the forward open request simply transfers the configuration data as "simple data segment". 

You may see the decoding in ParseConnectionPath() in cipconnectionmanager.c.

You can see the difference in the attached Wireshark logs that show an forward open with or without transmission of

config data (2 bytes in this case). The screen shot shows the "Implicit Messaging" dialog of the ENIPexplorer used to

do the forward open (observe the "Write Config" check box in the left lower corner). This tool can be downloaded

at https://sourceforge.net/projects/EnIPExplorer/

Maybe that helps.

Best regards,

    Stefan

[Vien Huy Nguyen]

Thank you Stefan,

I have another question regarding cyclic implicit messaging. I ported OpENer v2.3 and noticed that O->T and T->O are transferred on two different socket; UDP for O->T and IPRAW for T->O. When data is sent out, the UDP header is added by OpENer.

Can I just use one UDP socket, bound to port 2222 for bi directional data transfer? 

I am using OpENer on a resource-limited microcontroller.

[Vien Huy Nguyen]

Hi Stefan,

In generic_networkhandler.c, I replace SOCK_RAW with SOCK_DGRAM for Producing port, and remove all the added UDP header in the SendUDPData() function. 

I am able establish a connection with the scanner, the T->O I/O messages look ok to me. However, the scanner isn't sending out the O->T messages.

I use the Hilscher EtherNet/IP Tool that I get from this link: https://kb.hilscher.com/pages/viewpage.action?pageId=97444743

Wireshark capture is attached. I am wondering if you could tell me if I am missing anything.

Thank you.

[martin...@gmail.com]

Hi. 

If you bind to port 2222 there is no way to influence if the message is delivered to the receiving or sending port. 

Also, the originator decides on which port you need to send the T to O messages.

Usually if the scanner does not answer, the sent messages are somehow malformed. 

The current head version has a working variant which does not need raw socket, if that is an issue. 

Best regards, 

Martin

[Vien Huy Nguyen]

Hi Martin,

Also, the originator decides on which port you need to send the T to O messages.

-> Shouldn't it always be UDP port 2222 for both the originator and the target?

If you bind to port 2222 there is no way to influence if the message is delivered to the receiving or sending port. 

-> Could you please elaborate on this? I am not sure I understand.

In the current head version, in generic_networkhandler.c line 914, it states: "Create the UDP socket for the implicit IO messaging, one socket handles all connections."

Does it mean it is using one socket for both  T->O and  O->T, the same as what I am trying to achieve?

Thank you.

[Vien Huy Nguyen]

I also try to use the Ethernet/IP Explorer tool which Stefan uses. It seems this tool doesn't register a session before sending the get command; therefore it gets rejected by OpENer and a message with kEncapsulationProtocolInvalidSessionHandle error code in the encapsulation header is sent back to the tool. I try to use Explicit Message to get the data; Register Session request and response are okay but somehow in the Send RR Data message, there is only the encapsulation header, the command data is empty. 

[martin...@gmail.com]

Hi,

no, the default for both is 2222, but the originator can specify different ports for O->T and T->O Class 1 connections. They also don't have to match.

Sorry, I didn't meant ports, but sockets. Each UDP connection is a pair of two connections. In the current head version, sockets bound to the same port are now shared, so all good.

In the version with the raw sockets, which you said you modified, they are not shared, so simply changing this from raw to UDP and binding to a specific port won't work there, as if two sockets bind to the same port, then its implementation specific which socket will get the received message. But if you use the UDP_DATAGRM mode you need to bind, to specify the correct outgoing port, otherwise you will get a random port.

I tried that, and went with the raw socket route in the past. If I remember correct, Peter Christen fixed this, as there are no raw sockets on FreeRTOS.