Troubleshooting PLC fault: CompactLogix L33ER

One thing that is worthy of mention at this point, is that the in-built error checking, i.e. have we addressed an area outside of the array dimensions, ONLY works for unique array tags.

If the array in question is part of a UDT structure, and not the last part, then an "illegal" array index WILL stomp on, or read from, whatever is in memory after the array.

In other words, the in-built error checking ONLY looks to see if you are trying to address OUTSIDE of the TAG, and in the case of a UDT tag, you could have lots of corruption going on, and you'd never spot it, because the processor doesn't fault out.

It is wise therefore, to use any means possible to range test or limit the array index before you use it
 
Rung 4 [ADD Press.Val_HolesPerPart 1 L_PunchCounter.PRE] should cause some concern: if Press.Val_HolesPerPart ever has a value larger than 15, then L_PunchCounter.DN will mean nothing with respect to the index overflow. So a [LES L_PunchCounter.ACC 16] is needed, in addition to checking L_PunchCounter.DN, on the feed of current Rung 8.
 
First off, I want to thank everybody for the replies. Without getting too deep into it, this problem has pointed out answers to questions I've had in the past. Funny how the universe does that.

Right now, I'm leaning towards putting the reset prior to rung eight. I need to have a conversation with my customer and understand his needs. This is my first time with this customer, and I have been on site for a total of 3 hours. It sounds like this problem happened because they were trying to manually make the machine handle longer pieces then it was designed to do.

I'll start there and see where it goes. Their controls guy retired a while back so I get the feeling I might spend some time work on on extending the array and learning what that might entail.
 
Rung 4 [ADD Press.Val_HolesPerPart 1 L_PunchCounter.PRE] should cause some concern: if Press.Val_HolesPerPart ever has a value larger than 15, then L_PunchCounter.DN will mean nothing with respect to the index overflow. So a [LES L_PunchCounter.ACC 16] is needed, in addition to checking L_PunchCounter.DN, on the feed of current Rung 8.

Yes! I was looking at that. I might need to limit the panelview input to 15. I will look at this again when I get home. Right now, this post is keeping me entertained while my girlfriend is shopping. Lol
 
I think it makes sense to extend the array to some ludicrous equivalent length, and also add guards, and maybe HMI alarms, for when someone tries to run a piece longer than that.
 
Yes! I was looking at that. I might need to limit the panelview input to 15.

You could use a SIZE instruction to capture the array length and then set the panelview maximum input to one less than that -- this would automatically adjust the input limitation even if the array size were to change in the future.
 
You could use a SIZE instruction to capture the array length and then set the panelview maximum input to one less than that -- this would automatically adjust the input limitation even if the array size were to change in the future.


Ooh, sweet!
 
Follow up: I went on-site and talked through options with the customer. I wasn't feeling well, so I wore a mask and worked 20 ft. away from him, just in case. He said their sales guy promised a customer 40 ea. of a product that was outside of the machine's length capabilities, and they had been trying to 'trick' the machine into going that large. Unless the Production Manager gets over-ruled, this is the last time they'll do this. So, with all the circumstances in mind, I just inserted a 'if x = 16, then reset counter' before rung 8. That was a quick solution, and we tried it out to make sure it worked the way we anticipated. They were able to get 15 punches, then jog the product far enough to finish the last bit manually. I wanted to extend the array, but figured I'd better get a COVID test first before spending a lot of time there. Plus, I think the Production Manager preferred that I didn't make it easier to create the longer product.

Thanks for the help, guys. I picked up a couple of good bits from this one. Now, I need to learn about the SIZE function.
 
Had this exact same issue with another plant a few weeks ago.
As we killed the AOIs that were throwing this error, we just kept getting deeper.
This was a "newer" system that no on there had any ideas how about it.
In the end, the correction was to update the Allen Bradley software version up 1 sub revision.
The reason for the update was there was an issue with the sub revision they were using, it would cause issues with the AOIs when the program was downloaded to the PLC.
Upon updating the software revision 1 level, they downloaded the program back to the PLC and all the errors went away.

Update:
Tech replied quickly, the version he started with was 32.2 or 32.3, he cant remember exactly.
The version that corrected the aoi array error was 32.4.
Hope this helps.

Gad
 
Last edited:
...I wanted to extend the array, but figured I'd better get a COVID test first before spending a lot of time there. Plus, I think the Production Manager preferred that I didn't make it easier to create the longer product...

Years ago, I was working on a service call for a customer that had this fault. They were new to Logix systems and couldn’t figure out what was going on. They had about twenty fans in this process. Each time a fan turned on they would capture its fan # and store it into an array. They used a counter to increment the data storage through the array elements. At the end of the day, they would send that data out to their data logs, wipe the array data, reset the increment counter, and start over. Most of the fans ran continuously so on an average day they would see about 10-15 transitions get recorded. This worked fine for 2+ years.

Well, one day they were doing some maintenance on the fans. After working on a unit, they would turn them on and off a few times to test the functionality and verify all was good. After about the fifth fan, suddenly everything shut down. They had this same fault. That’s when I got involved.

Turns out they had an array of just 30 elements and no logic to test the increment against the array size. Their counter had gone beyond the size of the array and caused a major fault. After discussing the operation with them it was decided that we would do two things to resolve the issue. First, we extended the array to 300 elements. Second, we added logic to check the counter did not increment past the end of the array and prevented someone trying to change the counter preset beyond the array size. I also added logic to record if they ever hit 50, 100, 200, or 300. Just to see if we would need to make the array larger still. I was back there a few years later and they had added those targets to display on an HMI that had also been added since I was there. They had hit 50 a few times, but never reached 100.

I hope you are feeling better. I was in Seattle for the holidays, and everyone was wearing masks and you had to show your vaccine card to sit down in a restaurant. Then I came home to Texas, and it was as if COVID didn't exist. Now COVID is tearing through our staff (again). Tons of people out. Many of them are getting it for the second time.

OG
 
Great info here.

I was at a customer that came up with the same fault when an operator was trying to adjust a label placer. Well, he entered a larger number than was allowed, but the hmi had no restriction on the number that could be entered, so it faulted.

It was easy enough to walk in, read the code and know what the issue was, but they didn't want me to try to fix it, they had their OEM who just finished building the machine a few weeks ago take care of their mistake.

now I may know what to do, or at least where to look, if I run into it again 🍻
 
OG & Ian...

Great stories! This has been a good issue to encounter. I've certainly learned from it. Working *more* with arrays has been on my radar for where I am in my development. I'm always amazed when I've been thinking about something, and the next thing I know, it falls out of the sky, right in front of me... not a minute before I was ready to tackle it.

As far as COVID... I don't think I've got COVID, but I got tested Monday and am waiting results. I'm vaccinated, but no booster yet. I felt crappy for a day or so, but now it just feels like a mild cold. I'm using the at-home time to finish my end-of-year accounting, which isn't a bad way to use the down time. As I speak to my customers who I planned on working with this week, most have people out for COVID. We're all in the same boat right now.
 

Similar Topics

Hey when I turn on my Siemens PLC CPU 216-2 after runing 10 minute it's stop and showing SF indication after I turn off and some time later turn...
Replies
0
Views
94
Hello everyone, It is the first time to use automation studio of B&R PLC How can I see the ladder diagram of the current program and search for...
Replies
8
Views
2,064
Hello! My name is Luke and I started training about a month ago at a company to repair and remanufacture PLCs. I've done a lot of training and...
Replies
3
Views
1,610
I was troubleshooting a customer's machine today, and I came across a couple of questions that I need your thoughts on. 1. At the end of the...
Replies
11
Views
3,534
Hello everyone, Background: We have a Directlogic 405 PLC that has an output card that has all solenoids on it. These solenoids are on plugs with...
Replies
9
Views
2,837
Back
Top Bottom