ControlLogix FTView DLR - Stale DATA AOI Faulted

[ivanjoseph21]

Hi Guys,

I just wanted to ask regarding to an error that we got troubleshooting the PLC system. Everything is working well then we tried to add a Ring supervisor in the network.

We have a redundant ControlLogix PLC, 3 RIOs and Redundant HMI (FTView) with an ETAP. No switch. The ring supervisors were the ENTRs of the redundant PLC when we arrived. Communication faults was visible in the HMI prior to troubleshooting.

The DLR_AOI block had an error during troubleshooting and I believe the attached is the cause of the error indication in the FTView. This cause the DLR page to not update when there is an communication failure. We checked if the ring is working if one cable is removed and its functioning properly. The PLC recognizes the fault in the system but not the HMI.

What could be the problem and solution to this?

 

[AlfredoQuintero]

I think your problem is you are using instance attribute 0, which is not legal in the CIP specification.

 

[Contr_Conn]

I think your problem is you are using instance attribute 0, which is not legal in the CIP specification.

This is a Get Attribute All message, attribute must be 0
This message looks correct, but I would check the path, as it looks like Device is not responding.

Also, I would try to disable AOI and then enable again. This will reset all messages.

 

[AlfredoQuintero]

Ooops!, sorry. I thought it was GetAttributeSingle. My bad

 

[ivanjoseph21]

We did try to enable and disable the messaging but no luck. We also replaced the ETAP which was the path of the message.

 

[AlfredoQuintero]

Ivan, I have had a closer look at your pictures. Can you confirm the PATH that you are using? As Contr_Conn says, we need to verify the path because according to the screenshot you sent in the first post, the ETAP does not have the logo of the crown, so it has net the DLR supervision function enabled. PLease see below:

 

[Contr_Conn]

I think this old version of the AOI had an issue with Redundancy systems. It’s related to the supervisor address reporting on the DLR. When EN2TRs swap addresses during redundancy switchover the supervisor physical location remains the same with new address, but new IP address is not propagated to the DLR devices, causing timeous as a result.
I would set ETAP as a primary supervisor and point AOI path to it.

 

[ivanjoseph21]

Yes Sirs. Initially when we arrived, the crowns (ring supervisors) are only the EN2TRs of the redundant PLC. The DLR faceplate was working like what I've mentioned and to add detail the primary CPU was on the left side of the panel.

During our efforts of tracing the communication failure (removing one side of the ring one at a time), the primary CPU switch (not sure when) then we later on saw the error on the FTView. I've attached the initial settings of the DLR AOI. Tried to check the "Connect" box but no effect.

We'll try tomorrow what you suggested.

 

[ivanjoseph21]

Last notes.. Currently the settings are the same with the initial. Also we have returned the primary cpu to the defaut one. address is 192.168.1.1. The 192.168.1.2 is the redundant cpu/en2tr

 

[Contr_Conn]

Your last screenshot has a lot of questions.
But before I comment, I must say that you can't check "Connected" box, this message should be unconnected.
Then you can't just go to the message and change path, this is controlled by the AOI, and dynamically manipulated,
You must disable AOI using "Enable" parameter, change Path_to_DLR tag, and then enable message again.
However, you should not need to change the path here, it will work as it it.

Next you need to enable DLR supervisor on ETAP, this is done in RSlinx.
Make sure change Precedence parameter as well, so ETAP is the Active supervisor. Do it when "Enable" signal on the AOI is Off, then Enable the AOI

 

[ivanjoseph21]

We did try what you have suggested. However, the error still exists in the DLR_AOI instrucion.

From RSLinx the following was made. We did a power cycle of the System for each step made.

1. Set ETAP the only ring supervisor. DIP switches was set appropriately.
2. Set ETAP are primary supervisor with Redundant CPUs as ring supervisor precedence.
3. Tried to Switch the Primary CPU. Waiting to SYNC before enabling the DLR AOI instruction.
4. Returned the Redundant CPUs as ring supervisor (192.168.1.2). This was the As Found before troubleshooting. Note that the Primary CPU is addressed at 192.168.1.

Sent a ticket to ra support already. I've attached the initial settings of the DLR AOI.

 

[Contr_Conn]

Can you posed full ACD upload in faulted state? it's hard to help using just pictures.

The proper way to correct this is to delete this rung, delete all Message tags, delete AOIs and then re-import rung.
Without it you may not get AOI and messages from Faulted states.

However, this old AOI version (3.x) is no longer available. Current version 4.x will require also HMI Faceplate replacement as well.

 

[ivanjoseph21]

https://drive.google.com/drive/folders/1PQosMXcAFdLrjamfs1Ly3WrdCsQQUB3Q?usp=sharing

Gonna delete link in 24 hours

 

[Contr_Conn]

The DLR01_Path is wrong. It should be 1,2,2,192.168.1.14
You must disable AOI before changing it.
You can also use 1,2,2,192.168.1.1 (point to the controller EN2TR).

This is all assuming that you have ETAP as the Active Supervisor.
I did not see RSLinx screenshots indicating that.

 

[ivanjoseph21]

Got it Sir. Thanks for your help.

Just wondering how it worked before with that configuration and only the redundant CPU as ring supervisors.