Logix 5000 IO Fault Handling

AMarks95 · Aug 10, 2022

I've made a fault routine to notify operators when an IO module causes a major fault, and provided a button to manually reset the fault, but I'd like to be able to tell the operators exactly which module faulted.

(1769-L36ERM)

I've been referencing this PDF for creating the fault routine https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm014_-en-p.pdf

However, there's no information on what the "fault-specific" info DINT[8] values are. I'm thinking this might be able help me programmatically determine which module has faulted. Has anyone had experience with this?

joseph_e2 · Aug 10, 2022

At a previous location, I wrote a routine to display the status of each module. It used a GSV for each module. Attached is a screenshot of the GSV for an input module in the local chassis.

A screen on the HMI had a multi-state indicator for each module that looked at the destination tag.

Refer to this manual:
https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm003_-en-p.pdf
Page 197 lists the EntryStatus values and what they mean. Page 215 talks about the fault values for the modules.

Locodios · Aug 10, 2022

For fault routines, I typically program the following:
1. CONTROLLERDEVICE Object Status
2. MODULE Object ForceStatus and LED Status Attributes (Processor)
3. FAULTLOG object - All four attributes
4. MODULE Object for each Comm and IO Module. Alarm and Status Tag.

AMarks95 · Aug 10, 2022

joseph_e2 said:
At a previous location, I wrote a routine to display the status of each module. It used a GSV for each module. Attached is a screenshot of the GSV for an input module in the local chassis.

A screen on the HMI had a multi-state indicator for each module that looked at the destination tag.

Refer to this manual:
https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm003_-en-p.pdf
Page 197 lists the EntryStatus values and what they mean. Page 215 talks about the fault values for the modules.

I ended up doing basically this. One GSV for each of 15 modules.

I just want to log which module faulted, not necessarily why (at this moment in time).
So, I compiled the fault codes into an array and looped through to check for error codes (NEQ 0). There's a parallel array of static STRING tags that get appended (CONCAT) to the base alarm string.

Operaghost · Aug 10, 2022

I typically monitor the I/O indicator on the controller as my starting point. When it is flashing green I use that to call a subroutine where I have my GSVs for the local I/O and communication modules. That way I'm not triggering all those GSVs when there isn't a problem.

If a communication module is the cause, then I use that to call a subroutine with GSVs to check all the "child" remote communication modules to see which one of those have an issue. When I find out which remote chassis has the issue then I use that to trigger GSVs to the modules in that remote chassis.

OG

AMarks95 · Aug 10, 2022

Operaghost said:
I typically monitor the I/O indicator on the controller as my starting point. When it is flashing green I use that to call a subroutine where I have my GSVs for the local I/O and communication modules. That way I'm not triggering all those GSVs when there isn't a problem.

If a communication module is the cause, then I use that to call a subroutine with GSVs to check all the "child" remote communication modules to see which one of those have an issue. When I find out which remote chassis has the issue then I use that to trigger GSVs to the modules in that remote chassis.

OG

Yes, I'm only calling the GSVs in the fault routine. After processing all the GSVs and creating my alarm description string I auto-reset the module. The bit that triggers the alarm for the operator stays on so they know which modules failed.

widelto · Aug 11, 2022

@AMarks95:
Please send me a PM with your email I got an example for module testing and identify which one is the bad.
It is written in V20 because that was the version of the customer, you can changed it to any other version.

Tim Ganz · Aug 15, 2022

Operaghost said:
I typically monitor the I/O indicator on the controller as my starting point. When it is flashing green I use that to call a subroutine where I have my GSVs for the local I/O and communication modules. That way I'm not triggering all those GSVs when there isn't a problem.

If a communication module is the cause, then I use that to call a subroutine with GSVs to check all the "child" remote communication modules to see which one of those have an issue. When I find out which remote chassis has the issue then I use that to trigger GSVs to the modules in that remote chassis.

OG

OG

Is that program something you could share a sample of? I never knew that functionality was there and would love to check it out in depth.

cardosocea · Aug 15, 2022

There's an AOI from Rockwell called Module_Sts that provides this and other details (with faceplates too). You point the module to it and it retrieves data.

Logix 5000 IO Fault Handling

AMarks95

Member

joseph_e2

Member

Locodios

Member

AMarks95

Member

Operaghost

Member

AMarks95

Member

widelto

Member

Tim Ganz

Member

cardosocea

Member

Similar Topics