Is this a problem with Ignition OPC UA ControlLogix Drivers?

THIS MAY NOT BE AN IGNITION ISSUE; But I am just curious if others have observed it:

We recently configured a demo system for a customer. They have networked 5 CLX based processors on Ethernet and we use the OPC UA drivers built in Ignition (latest release).

Here is a complaint from our customer:

As communicated to you yesterday at @ 5 pm, All the subject truck presses PLC stopped working at 4.10pm on communication faults , due to problem in LAN networking. As PLC halted, all the above presses were not opening after completion of cycle. After removing the LAN cable of each presses PLC started working.
Fortunately this was communicated to the engineer who was present on shop floor; problem was identified and the network was isolated by him other wise 10 nos of expensive parts would have been scrapped
This is serious issue , Now the network to presses is isolated , kindly arrange to rectify the same and ensure the same is not repeat again.
Now data will not be captured as communication is isolated

This is not much to go on. In the project are there any SQLTags being written to?
It sounds like a ControlLogix tag was being written to that was interfering with the press operation.

We are not writing any tags back to the PLC; all groups are configured for one way (read only ) monitoring.

What is also bothering me is that even if there is a communication error; how can the entire PLC stop functioning and hang.

This is a complete shot in the dark, but on equipment that the HMI is critical to operation and process logging/tracking I have put in watchdog communication timers in the code that when they timeout the equipment stops at the end of the cycle and switches to manual until the problem can be corrected or run from a backup dedicated HMI.

Do you think that the data collection could have interfered with a supervisory PC that may be monitoring the press and caused it to stop or switch to manual mode?


Reread the post again and had another thought. Does the ControlLogix (& I assume you mean the large 1756 series, not CompactLogix) have any Ethernet based I/O communications? This can include variable frequency drives, input/output modules, motion controllers, etc.

If so, and you are communicating through the same Ethernet port as is being used for the Ethernet I/O you can definitively have a problem. There is a little bit of work someone needs to do (none of it major) to make all that work.

Depending on I/O updates and quantity of I/O on Ethernet you may need to upgrade to a managed switch that includes IGMP Snooping. Next, if there is not another Ethernet module in the rack dedicated for HMI/data collection comms, it needs to be added. If there are no available slots in the base rack then you should upgrade your Ethernet Module to a 1756-EN2T.

Also, depending on your controller firmware revision and the Ethernet module firmware revision you may be able to just update the Ethernet module firmware. If it is older then I think V3.5 there was an issue with TCP communication timing that could take down the I/O UDP based communication (that is where the recommendation for separate Ethernet modules stems from). Anyway, like alluded to a post above, not much information to go on to help.


Thanks a lot for your response; I am trying to check with the customer and confirm the model nos and the firm ware versions you mentioned.


Sorry for the delay but here is the information about controllers;

  1. The exact model of the PLC (for confirmation) :-Compactlogix L23E QBFC 1B ,1769-L23E-QBFC1B
  2. Controller firmware version, Ethernet Module firmware version: CONTROLLER VER 17.2 AND REMOT IO 1734-AENT VER 2.2
  3. Does the Control System have any Ethernet based I/O communications ? Like variable frequency drives, input/output modules, motion controllers, etc.

Also, I was looking at the below forum and was curious if our problem is similar to the one indicated in the discussion: … mpactLogix.