Controllogix Communications

nic00 · Mar 13, 2014

Hello All,

Today i have been attempting to setup some more data acquisition from one of our plant PLC's to an IBA server utilising Ethernet/IP. This is setup using a Generic Ethernet module of which points to our IBA server.

I have previously setup around 10 of these PLC's around plant, the only difference today is that this PLC is on a different IP range 150.1.58.xxx rather than 150.1.12.xxx

Unfortunately when i setup the two generic Ethernet cards (1 Digital / 1 Analogue) and downloaded to the controller, both modules kept timing out i.e. 16#0203 Connection Timeout. After a bit of searching i found a thread that indicated that this could be due to router setup issues so i contacted the IT dept. who tell me there is nothing wrong their end (Hmmmm).

If the IT dept. is correct and it is not network related, can anybody offer any thoughts of what could be wrong. (I am hoping Ken reads this as i have seen quite a few threads that he has been more than helpful in with regards to these type of errors)

Any help would be very much appreciated.

danatomega · Mar 13, 2014

If your subnet mask is set to 255.255.255.0 then 150.1.58.xxx is on a different network than 150.1.12.xxx. There is likely nothing wrong with the router setup but there would need to be a route added to enable a translation between the two. It can set this up if you can convince them it's required.

nic00 · Mar 13, 2014

Hi dan,

I believe the subnet was set to 255.255.254.0

dmroeder · Mar 13, 2014

I've never really tinkered with subnets like you are attempting, but according to this site, your subnet would need to be 255.255.192.0

nic00 · Mar 13, 2014

dmroeder, I can actually see on wire shark the "forwardopen" so do not believe it to subnet related (I could be wrong).

Ken Roach · Mar 13, 2014

I don't think you would see the CIP Forward Open if the problem were subnetting, because the ordinary TCP Connection (SYN/ACK) would not complete.

Can you capture the traffic between the IBA Server and the ControlLogix ?

Error code 0x0204 is the most common "Connection Failed" error when two EtherNet/IP devices cannot communicate at all.

Error code 0x0203 is generated after a connection is established, when something goes wrong with the connection negotiation.

One common instance of 0x00203 is when a connection is requested to use Multicast, but the router or network in between the devices blocks Multicast addresses.

Do you know if the Generic Module objects are set up for Unicast or Multicast ?

Maybe your other connections are on a local network and this one has to go through a router.

Operaghost · Mar 13, 2014

There are a number of ways to come up with the subnet that will work, but the one you mentioned (255.255.254.0) will most definitely NOT work without a router.

Also, are both devices using the same subnet mask? You should not be seeing the Forward open based on those subnets and that mask.

The devices at 150.1.58.xx could talk to anyone on it's own subnet and also with devices at 150.1.59.xx

The devices at 150.1.12.xx could talk to anyone on it's own subnet and also with devices at 150.1.13.xx.

The subnet dmroeder suggested would allow your devices to talk to anyone with addresses ranging from 150.1.0.xx though 150.1.63.xx without requiring a router.

OG

** EDIT ** Just rereading post #1 and immediately thought AHA the router is blocking the data. To IT everything is just fine. They are blocking the data, just fine by them. Sure enough, Ken caught it!

nic00 · Mar 13, 2014

Hi Ken,

You are right this one will have to go thru a router. I have the wireshark log at work and will post first thing in the morning, it seems like it opens and more or less closes about 0.75s later. I have set the module up as follows (from memory):
Input :1,1
Output :1,32
Conf :27,0

They are using multicast.

nic00 · Mar 13, 2014

Opera,

My apologies I should of stated that this connection will be thru a router rather than be local, my apologies.

We have two PLCs on the 58 network communicating to our factory talk distributed scada on the .12 network so would assume that the network side "should" be ok?

dmroeder · Mar 13, 2014

nic00 said:
Hi Ken,

You are right this one will have to go thru a router. I have the wireshark log at work and will post first thing in the morning, it seems like it opens and more or less closes about 0.75s later. I have set the module up as follows (from memory):
Input :1,1
Output :1,32
Conf :27,0

There is a checkbox on the connection tab of those generic modules that says something like "allow unicast connection". Ken is asking if it is checked or now.

edit: never mind, I see you answered it...

nic00 · Mar 13, 2014

Just edited the post as you posted, prefer the laptop to the ipad....

Operaghost · Mar 13, 2014

nic00 said:
......We have two PLCs on the 58 network communicating to our factory talk distributed scada on the .12 network so would assume that the network side "should" be ok?

Yes, if there is a router then the subnet mask is ok. But, the multicast setting is indeed where you are getting tripped up. It is common for IT to block multicast traffic through their routers. If you can change to Unicast you will probably be successful.

OG

nic00 · Mar 13, 2014

The project is v15 I believe, is unicast available as I couldn't see a selection for it. On a recent v20 project I could see a selection for this.

nic00 · Mar 14, 2014

Ken,

The fault is actually Code 16#0203. The wireshark log with a CIP filter on is attached.

robertkjonesjr · Mar 14, 2014

Does the cip display filter pick up class 1 packets as well? I forget, and don't have a trace handy to try it. Do you have any UDP/port 2222 traffic, which Wireshark interprets as enip?

Could you try cip or enip? Two seconds is a short time to timeout if the T->O packets are not coming in, I recall the spec says 10s to wait, but would have to check. Also you have another issue with multicast - by default/per spec, the multicast traffic TTL should be 1 so would be dropped by the router anyway, even if multicast routing configuration is correct.

As already described by others, if this is root cause, unicast will help.

Controllogix Communications

nic00

Member

danatomega

Lifetime Supporting Member

nic00

Member

dmroeder

Lifetime Supporting Member

nic00

Member

Ken Roach

Lifetime Supporting Member + Moderator

Operaghost

Member

nic00

Member

nic00

Member

dmroeder

Lifetime Supporting Member

nic00

Member

Operaghost

Member

nic00

Member

nic00

Member

robertkjonesjr

Member

Similar Topics