Major Fault Type 4 Code 20 (T04:C20)

Hello everyone, has anyone had this problem before PLC 5000 Model 1756-L81E Major Fault Type 4 Code 20 (T04:C20)

Many people have had it before and many people will likely have it in the future.

The PLC has likely attempted to access an array index that is out of bounds, ie either negative or higher than the size of the array allows.

That major fault is common when logic that performs indirect addressing exceeds the array bounds.

It can also be specific to some v32.03 projects that use indirect addressing with boolean arrays inside an AOI, even when the logic doesn't actually exceed the array boundaries. There's an RA Knowledgebase article about that, with instructions about how to purge the compiler error from your project and which firmware resolves the issue (32.04+ or 33.0+).

Thank you for the information. This is helpful.
The PLC version we have is V31.012. Is the issue that is specific to V32.03 projects, for all versions before that version as well?

To my knowledge that defect exists only in the Studio 5000 version 32.03 compiler.

So your system almost certainly really did index past the end of an array.

we got the same error last night in version 33.01.00.
we were creating recipe 301 but only had an index of 300.
we increased the array size.
james

We have been struggling with this fault for the last year. Our fault is occurring on a CompactLogix L30ER with 2 MVI69E-MBS Prosoft Cards.

The AOI in use that gets the Fault does not have indirect addressing and it also does not have data that exceeds the array size but the Fault is type4 code 20. This happens randomly by all appearances.

Sometimes it takes months between faults and other times it happens multiple times a week. It is very disturbing being so intermittent.

Next time, note the location where the fault occurred. It will tell you the task, program, routine, and rung # (for LAD). Using that you can identify if it is the AOI or some other instruction.

OG

I added a picture of the fault info and the AOI it directs to. What I am seeing I believe is a problem in Prosoft handling of the array.

This is happening across 8 sites. Oddly I have not heard of anyone else having this problem. We are not even heavily loading the array.

It appears that the more remote writes that are sent to the Prosoft card to get sent to the PLC the more the fault occurs.

What is the reason for the MSG_DELAY_TMR triggering MBS_SlotX.CONTROL.GetStatus? To my knowledge, the AOI takes care of everything internally. I expect that’s triggering something at the wrong time. Try to eliminate that and see what happens.

Edit: I'm using the AOI for that module with IO size 60 so there might be some differences. I looked through the AOI and see that GetStatus is unlatched but not set. Maybe externally triggered is correct, I haven’t used it. If that’s the case, use a ONS to latch the bit when the timer is done instead of OTE.

The benefit of the OTL suggestion depends on how the timer is triggered. If .DN is on one scan only, this might not help.

ProSoft has great support. If that doesn’t fix it, reach out to them.

Some more editing: It sounds like you’re building write commands and triggering them. I've only created one EventCmd write with that module, so I’m far from an expert and these are somewhat guesses.

Make sure PointCount doesn’t go too large. The comments say max of 50 words or 800 bits.

When triggering CmdTrigger, use a ONS to CLR EventCmdStatusReturned. Wait for EventCmdStatusReturned NEQ 0 before unlatching the command and setting up the next command. Use a timeout timer to unlatch the trigger if it’s still on after a couple seconds when a command fails.