Controllogix Major Fault Type 4 Code 20

[daba]

So it appears as though we have exposed a "bug" (which no doubt RA will undoubtedly call a "feature", say it was deliberate, and try to give an explanation why - should be interesting !).

But I have only tested this on Firmware Revision 20.

If anyone can oblige with the same test I did at the latest firmware revision, it would infer that it has always been there, and without an RA fix, it will always be.

I should not have to say this - don't do this on a running, live, active controller in the real world, indications are that bit-level indirection will most likely fault the controller !

This is not mitigation, but it is fair to say that not many people use BOOL Arrays, for the simple fact that there is not a lot you can do with them, other than for storage or HMI/SCADA exchange. Perhaps this is a reason why this "enhanced undocumented feature" has been hidden for so long.

But if we can get proof that this still exists in the latest firmware, then a shout at RA from someone with T/C might get the ball rolling for a "correction" in future firmwares.

 

[drbitboy]

It's a bug on OTL and OTU only.


It's not a bug on OTE. Agreed?

 

[daba]

It's a bug on OTL and OTU only.


It's not a bug on OTE. Agreed?

According to post #12, it seems as though any bit instruction will fault - but I will test ....

EDIT : Every single one of the Bit instructions will fault the controller if the array index is not valid.

I have tested OTE, OTU, OTL, XIC, XIO, ONS, OSR,and OSF

EDIT2 : Word level instructions, (and I have not tested all of them), do NOT fault the controller.

I have tested MOV, MVM, CLR, EQU, NEQ, GRT, LES, GEQ, LEQ

 

[daba]

It appears to affect only bit-level instructions, including any indirection to the bit-level of a word, although in this case the fault generated is different, Type 4 Code 83

 

[drbitboy]

According to post #12, it seems as though any bit instruction will fault - but I will test ....

EDIT : Every single one of the Bit instructions will fault the controller if the array index is not valid.

I have tested OTE, OTU, OTL, XIC, XIO, ONS, OSR,and OSF

EDIT2 : Word level instructions, (and I have not tested all of them), do NOT fault the controller.

I have tested MOV, MVM, CLR, EQU, NEQ, GRT, LES, GEQ, LEQ

Yes, but for an OTE, ONS, OSR and OSF, the PLC must still assign a value at the index, even if the incoming rung is False and the value will be 0.


For XIC and XIO, maybe it still tests the bit at the index, adn there are no short-circuits as there would be in an optimizing compiler; the execution timings* for XIO and XIC are basically independent of the state of the input rung.


* Cf. https://literature.rockwellautomati...documents/rm/1763-rm001_-en-p.pdf#G28.1039971

 

[Operaghost]

My thinking behind stating that I thought word level instructions wouldn't fault was based on my thoughts on how a bit and word instruction might execute.

To my way of thinking, for the OTL as an example, was that when the logic ahead of it is false, it would evaluate the OTL as logically false, then identify the bit, then leave the bit in its current state. So, the bit would have to be a valid tag even though its status is unaffected. It identifies the bit because it is the destination of the instruction. It is the affected bit.

For a Word instruction such as a MOV, it would identify that the logic ahead of it is false, evaluate the instruction as false. Then, in my head, I see it proceeding on without need to inspect the source/destination tags. But for some reason, I think it might inspect the source, or whatever the first parameter might be. That's just how I see it operating on a word or file level instruction.

I would be very curious to see if the source of the MOV was pointing to an invalid tag if we saw the same result. Or as part of an expression like a CPT.

OG

 

[daba]

RA Training teaches you to trap illegal indirection with appropriate comparison instructions, which is what the OP had done, and in my view it ought to have been enough.

Another topic in the training is about rung optimisation, e.g place instructions More likely to be false at the head of the rung, and they say it improves execution speed because the remaining instructions can't turn the rung true again, so the instruction addresses are not evaluated.

However, certain bit instructions will have to address the specified data, even though a LIM has evaluated false.

These instructions legitimately have to visit the date base, when the rung has evaluated false already, are...

OTE : because the specified bit has to be turned off.
ONS : because the one-shot has to be reset.
OSR : because the storage bit has to be reset.
OSF : because the storage bit has to be reset.

All the other bit instructions do not need to go to the specified data base location....

OTL : the rung is false, so no need to address the data.
OTU : the rung is false, so no need to address the data.
XIC : the rung is false, you cannot make it true again.
XIO : the rung is false, you cannot make it true again.

In summary, and only when the rung is false, OTL and OTU should not fault the controller, according to RA training material.





OG, will this do for you ?

 

[daba]

I suppose the best advice I can give is....

a. Create and use separate "index" tags for each and every BOOL Array indirection if your arrays are different sizes.

b. Create and use a unique "index" tag for indirect bit addressing in "word" tags (separate tags for SINT, INT, and DINT).



Keep everything separate when you have to, so that re-using an index tag elsewhere doesn't cause this issue.

The "CLR INDEX" solution I posted should only be used for OTL and OTU. If you use it on OTE it will reset bit 0, which may not be appropriate.

I did state in an earlier post that BOOL Arrays don't have a lot going for them - even less now ...

 

[daba]

Here's another way around the problem. I got to thinking about a JMP/LBL around the indirect address, but then decided it was easier to put the Indirection in a Subroutine.

If it doesn't get called, it doesn't get scanned ....