PCCC protocol causing problems

Ignition Version 7.8.2
Java™ SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot™ 64-Bit Server VM (build 25.92-b14, mixed mode)
OS : Ubuntu 14.04

Is there a way yet to stop a protocol from being used?
I have an issue where remote equipment (ML1400) will loose connection because any number of accidental or purposeful reasons. The problem then becomes that Ignition will try the PCCC protocol and if the timing is right (often is) when the equipment comes back on it will connect to it using that protocol (PCCC) and it does not actually do anything useful.

I had this problem in 2014 and I was told that upgrading to 7.5.12 would fix it. I am now upgraded to 7.8.2 and it is still there.

I would think since the protocol doesn’t actually do anything on this equipment this would be a bug?
Does anybody have any experience with this?

Thanks for any ideas.

Did you get any response to this? I’m having the same thing occur at a customer site now.

I believe you can set a firewall rule to block TCP port 2222 to cut off native PCCC support.

Here is what I got from them.

   The issue you are seeing is due to an known issue with older AB drivers in ignition. 
   This issue has been resolved in later updates, these updates are included with the 7.5.12 updated release.
   In terms of impact on your system, this will just be an update with the latest bug fixes and improvements to ignition. 
   I would not recommend just installing the updated AB drivers since I can't say how that will work with the older
   version of ignition 7.5.5. 

I have since upgraded to 7.7.8 (LTS) and it still does it intermittently.

Same problem here - does the firewall rule work? You can set that with the windows firewall? I’m running the latest version of ignition.

Same problem here. It’s most frustrating because if I have to reboot a server, I then have to disable/enable all devices with PCCC until all the micrologix controllers have reconnected as EIP. Happens intermittently, so it’s very hard to identify.

Running 7.8 on various windows platforms.

On linux, on the Ignition gateway, the rule would be:

iptables -t filter -I OUTPUT 1 -m tcp -p tcp -dport 2222 -j REJECT

On a linux-based firewall between the gateway and PLC use FORWARD in place of OUTPUT. In either case, the resulting complete ruleset would have to be saved with the distro’s preferred tools.
I’ll let a Windows guru translate that into a suitable setting.

I have the same problem for MicroLogix 1100’s with V4.9.7 driver. Have a 1400 that would have turned off/on at the same time that came back to life correctly. Think 4.9.8 would fix the problem? Change log doesn’t indicate it made any adjustments for the MicroLogix driver. Blocking ports isn’t an option as IT deploys their own firewall package.

Hi. I had the same problem a few days ago. Several Micrologix 1400 are usually connected through EIP protocol. There was a communication failure due to a faulty network switch. When the switch was replaced, Ignition switched to PCCC protocol. It showed devices as connected, but no data was coming through. I disabled and enabled the devices in Ignition and after that Ignition is again using EIP protocol. However, this resulted in a few days of lost data. Nobody saw that there was no data comming in since it was a holiday and alarm is set on device disconnected, which PCCC driver didn’t show. Ignition v7.9.4, Allen-Bradley driver v4.9.4.

It’s frustrating. IT deploys the firewall here too. After a huge task to get them to allow me to run a firewall on the server, I blocked those ports. It didn’t work for me. Still need a fix.

Did you block those ports going outbound from your server? Windows firewall’s configuration isn’t entirely intuitive, last I looked.

Thanks Pturmel. Yes - I blocked them both inbound and outbound.

Any chance there’s an Ignition-specific rule that is overriding that one? (I’m at my limit for Windows Server management…)

Thanks. I played with it a little bit this morning. I’m far from very knowledgeable in this area - but ignition doesn’t seem to use port 2222 to connect with the PCCC protocol. I turned on firewall logging, and the server was connecting to port 44818 on the AB MicroLogixs. With the EIP protocol it was also connecting to 44818.

And actually to make things more complicated - I do have a SLC that connects successfully via the “direct” protocol using port 2222. So, I break that connection if I block 2222.

Ah! I was thinking the driver was falling back to the direct protocol. You won’t be able to block PCCC access via Ethernet/IP without also blocking straight E/IP. Hmmm. Sounds like we need a new advanced setting in the driver. Maybe posting in ideas.inductiveautomation.com would help – I’d upvote it.

This seemed to work:

“The correct protocol is EIP (or Bridged EIP). PCCC will not work, it looks like the connection is just getting stuck with an invalid protocol choice. The fastest way to resolve this is to add a connection path of 1,0 to the connection properties. This will result in the selected protocol being Bridged EIP.”

3 Likes

Is there a downside to Bridged EIP? For instance if we are connecting to 50 PLC’s will this chew up more resources?

No, it’s just a nuance added to the ForwardOpen that initiates the connection. Following traffic should be identical.

Sorry to resurrect an old thread here, but can someone help me understand how to “add a connection path of 1,0 to the connection properties”.

We are having this same comm issue with several brand-new MLX’s.

Thanks for the help!!!

John

Advanced properties on the device.