Controllogix Major Fault Type 4 Code 20

[mrctnj]

I have a strange behavior, sometimes Major Fault Type 4 Code 20 occur, I know the reason, I used an array with a word index which can assume a wrong value but non in that ladder.
I know it is my mistake but the index is always correct when PLC faulted because the rung adjust the index before using it.
I also know this may happen when PLC startup because during pres-can the controller check the indirect addressing (also if ladder will not be executed).
I just have the Continuous Task (no periodic Task), I solved using a dedicated index but watch a "Type 4 Code 20" fault in a rung while index is within the limits it is strange for me.
It happens causally once in a while.
Someone can help me for future?
Tks.

 

[daba]

Type 4, Code 20 could also be a Control tag .POS or .LEN invalid.

Are you certain it is the indirection that is generating the fault ? Have you inspected the fault information to see where it faults ?

 

[mrctnj]

Yes it is always "Type 4, Code 20", the instruction is "OTL [INDEX]" where INDEX is always within range in that routine, even when the PLC Fault is within range...
It can assume different value in other routine but always synchronous (there are no Periodic Task).
It seems sometimes PLC checks for potentials indirect addressing out of range (like during prescan).

 

[daba]

Yes it is always "Type 4, Code 20", the instruction is "OTL [INDEX]" where INDEX is always within range in that routine, even when the PLC Fault is within range...
It can assume different value in other routine but always synchronous (there are no Periodic Task).
It seems sometimes PLC checks for potentials indirect addressing out of range (like during prescan).

Can you post the section of code preceding where it faults, i.e. the point where INDEX is generated ....

 

[mrctnj]

Here is, as you can see the INDEX can't be out of range in this rung (could be in others rungs).

 

[daba]

Got it !! The whole of the rung is scanned ....

The LIM may evaluate as FALSE, so the MOV does not occur, so the OTL will try to address the bit number whatever was in INDEX.

I can think of two ways round this ...

1. Use a unique Index tag into the BOOL Array that cannot get set outside the array bounds (preferred).

2. Restructure the code so that the OTL rung does not get scanned (messy).

 

[daba]

Actually a simpler solution is to CLR INDEX in front of the LIM

 

[mrctnj]

I tought if LIM was False "the MOV does not occur" but also "OTL will NOT try to address". It behaves like "OTE".

Tks

 

[plvlce]

I believe I recall reading some months ago in some manual or technote that this was a (potential) issue, that the processor will essentially scan the entire rung and check the validity of array indices even if the rung evaluates false before they would actually be used.

In short, from what I remember the array index will be checked and cause a fault if not in bounds even if the instruction in which it is referenced is not enabled.

 

[Operaghost]

If the rung preceding it is false, the OTL still must be evaluated as false. It does not affect the bit, but it still must detect a valid tag name.

OG

 

[Jim3846]

maybe also try not to move a number that is greater then the index as it relates to this rung?

 

[mrctnj]

I made some test with index out of range, I placed an AFI at the beginning, here are the results:

- OTL > Fault
- OTU > Fault
- OTE > Fault
- XIC > Fault
- MOV > NOT Fault (even if index array out of range)

 

[daba]

Post #7 is the simplest cure ....

Seems like the bit array instructions are handled slightly differently .... hmmm, nice !

 

[Operaghost]

I made some test with index out of range, I placed an AFI at the beginning, here are the results:

- OTL > Fault
- OTU > Fault
- OTE > Fault
- XIC > Fault
- MOV > NOT Fault (even if index array out of range)

My take on that is that is that it isn't surprising. I would imagine any word level instruction wouldn't fault.

I agree that post #7 is probably the best prevention method for this. That or a LIM with a low and high limit for the acceptable values for INDEX.

OG

 

[daba]

... I would imagine any word level instruction wouldn't fault...... That or a LIM with a low and high limit for the acceptable values for INDEX.

OG

Why wouldn't a word level instruction fault ? It's the same dynamic. An "out-of-bounds" indirect address should NOT fault the controller if the rung is FALSE, period !

But, it appears as though bit instructions addressing bit arrays will fault when scanned, even though the rung may be false at that time.

So a LIM testing the indirection index ahead of the bit instruction would still produce a fault, even though the LIM makes the rung false.

My suggestion of the CLR will ensure that whatever happens, the indirectly addressed bit instruction cannot fault the controller, even if the rung evaluates as false by the LIM test of the CMD number.

The controller's handling of Bit and Word arrays must be different, and IMHO that constitutes a "bug".

In this particular case, if INDEX was only used to indirectly address bits within this array, then you would never generate the fault.

I did a similar test that mrctnj did, and you can see that only the bit-level array index is faulting. Both WordArray and BitArray are 32 elements long. You only need to look at the rung number of where the controller faulted to see this.

EDIT : Yeah I know, the LIM High Limits should be 31, not 32, but it is irrelevant in this scenario....