PCCC protocol causing problems

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.

This works really well for me. I just stuck it in a 30 second gateway script.

import java.lang.String
x = system.dataset.toPyDataSet(system.device.listDevices())
for row in x:
if java.lang.String(row[2]).contains(‘PCCC’):
system.device.setDeviceEnabled(row[0], 0)
system.device.setDeviceEnabled(row[0], 1)

1 Like

That’s a great idea!

I know this is an old post by now, but for anybody stopping by, what you need to do is go to Device Connections under OPC UA, find the PLC in the list, press edit, and then on the properties screen, write "1,0" (no quotes) in the Connection Path text field. Save it, then your connection problems should be solved. Worked for me.

1 Like