Faulting a AB L33 PLC

I am pretty certain that this is not always true - if the array is part of a UDT-scoped tag, and there is something after the array in the UDT, then the "out-of-bounds" crash doesn't work.

Indexed instructions simply check that the destination address calculated is consistent with the tag size, meaning the UDT tag, not the array "member".


Are you sure about this. Maybe I'm not understanding...


Let's say I have a UDT, members are .Name and .Count. I create an instance of it that is an array, let's say 10.

So I have MyTag[0].Name, MyTag[1].Count and so on. If I try to point to MyTag[10].Name, it's going to fault.

Maybe I structure it another way. My UDT is now .Name[10] and .Count[10] and I create a single instance. So now I have OtherTag.Name[0-9] and OtherTag.Count[0-9]. If I point to OtherTag.Name[10], it's going to fault.
 
Could you share a sample of that? We have the same issue as many of the lines are very similar but not exactly the same and sometimes people download the wrong program to the wrong controller and it's close enough that most times it works until we find 1 or 2 small operations are not working and by then sometimes we have ran a lot of bad production that has to be scrapped.


You don't need to go to the extremes of making code to check it's the correct controller.

On the "Advanced" tab of the Controller Properties window, there is a check-box to "Match the Project to the Controller Serial Number".

Just do a successful download, and the serial number will be populated once you are online. Check the box, and save the project. From now on, you can only download that project to that controller.

Of course, if you have to change a controller you will have to turn the check-box off to download the project, but just turn it "re-match" it, and save again.

2019-12-12_084055.jpg
 
Could you share a sample of that? We have the same issue as many of the lines are very similar but not exactly the same and sometimes people download the wrong program to the wrong controller and it's close enough that most times it works until we find 1 or 2 small operations are not working and by then sometimes we have ran a lot of bad production that has to be scrapped.


Here is a PDF.
 
Need some assistance. I am testing out a heart beat code and I want to fault the processor so I can check from the SCADA system that the PLC is Faulted and Alarms me. Thank you.

If you're only testing heartbeat code, then why bother faulting the processor? Just unplug the Ethernet cable.
 
Are you sure about this. Maybe I'm not understanding...


Let's say I have a UDT, members are .Name and .Count. I create an instance of it that is an array, let's say 10.

So I have MyTag[0].Name, MyTag[1].Count and so on. If I try to point to MyTag[10].Name, it's going to fault.

Maybe I structure it another way. My UDT is now .Name[10] and .Count[10] and I create a single instance. So now I have OtherTag.Name[0-9] and OtherTag.Count[0-9]. If I point to OtherTag.Name[10], it's going to fault.


If you try this with a MOV or similar instruction, it faults out, the array boundaries are checked.

However, if you use a COP, CPS, or FLL instruction, it does not check that you are writing or reading outside of the array, see the picture, I think it speaks for itself.

2019-12-13_090714.jpg
 
That will fault a CompactLogix but not a ControlLogix.


Default setting for an I/O module in ControlLogix is to NOT fault the processor if it fails and the connection is lost. However this can be turned ON in the module properties.

2019-12-13_092342.jpg
 
If you try this with a MOV or similar instruction, it faults out, the array boundaries are checked.

However, if you use a COP, CPS, or FLL instruction, it does not check that you are writing or reading outside of the array, see the picture, I think it speaks for itself.

Ah I see what you say.

Default setting for an I/O module in ControlLogix is to NOT fault the processor if it fails and the connection is lost. However this can be turned ON in the module properties.

Touche
 
Ah I see what you say.

Put COP CPS and FLL into a class of instructions called DANGEROUS !

AFAIK they are the only instructions that can corrupt your stored data if you get the instruction arguments wrong...

They were designed and implemented to execute as fast as possible, and have minimal error-checking.

They will not encroach outside of the current tag, but as you have seen can corrupt data within the destination tag.
 
Put COP CPS and FLL into a class of instructions called DANGEROUS !

AFAIK they are the only instructions that can corrupt your stored data if you get the instruction arguments wrong...

They were designed and implemented to execute as fast as possible, and have minimal error-checking.

They will not encroach outside of the current tag, but as you have seen can corrupt data within the destination tag.

I understand the behavior of copying data, I just wan't following the plot what you originally said about indirect addressing. My brain had the context of MOV/Compare usage.

daba said:
They were designed and implemented to execute as fast as possible, and have minimal error-checking.

Same mentality with their software too. Though they tend to miss the bar with speed. :)
 
I remember in PLC 5, you could actually message to the Status register that told you the fault code.

As a joke, I did that to a coworker, wrote random fault codes to his processor over DH+.

I kept him on the hook for 5 minutes, I could not stop laughing.

Have to have fun at work sometimes.
 

Similar Topics

Hey Everyone, After reading a lot on this forum and elsewhere I see not many are fond of the 1794-VHSC module. I can see to a degree as I was...
Replies
2
Views
32
During the "no parts available" era of 2020-2022, we were told that a 1756-OBV8S would have better delivery than PointIO safety modules that we...
Replies
6
Views
1,051
Hi everyone, I recently put in a 1769-AENTR, and where it is installed has had a couple power outages. Every time when the PLC comes back online...
Replies
3
Views
671
In the past I have been familiar with the 1769-L35E series CompactLogix PLCs by Allen Bradley. For those PLCs (firmware version 20.19), when the...
Replies
7
Views
1,092
We programmed a Micrologix 1500 we had left over. We forgot to insert the memory module. So we powered down, inserted the memory module and...
Replies
6
Views
4,164
Back
Top Bottom