Preventing a PLC fault, caused by human error on a Panelview 300 Micro.

[AutomationTechBrian]

I went on a service call yesterday for a Micrologix 1500. An output wasn't activating and they wanted to know what was hanging it up. It was a small program with one main ladder and about 50 rungs... it took maybe 30 minutes to get setup, hooked-up, uploaded, and the missing input found. Wanting to make the most of our time, my customer asked if there was anything I could do to alleviate an annoying problem. He said they've tried asking the guy who wrote the program how to fix the issue, but he has never replied to their request. Now he's retired and they've evidently given up trying to resolve the issue through him. It's an interesting problem that merits some thought, so I thought I'd share it with you guys to get your input.

The machine uses a Panelview 300 micro to input the size settings. The operator pushes buttons to get to the selection screen, and when the correct selection is highlighted, he pushes F2 to load the selection. The problem comes with the lag-time between screens loading. The operator pushes F2 before the HMI is ready for the input, and it creates an error that freezes the PLC. I tried to get more specific information, but all they said was a guy had to come and hook up to the PLC and clear "a counter". I suspect it's a system thing because I didn't see any counters being used when I looked at the Counters-used-in-the-program file.

Evidently they can get a copy of the Micrologix and Panelview files from the machine builder if I think the issue can be fixed. Like I said, the original programmer has been retired for a while and hasn't responded to their previous requests. I was thinking about it while driving and wondered if this was something you folks have had to deal with. It's too vague to spend a lot of time on at this point, but it seems like it could be a common issue. Any thoughts?

 

[widelto]

What I do to avoid this is to create a new screen where I ask, "are you sure these data is correct ?" (show the values) and when the operator press "YES" is when I move data to the right position.

 

[JesperMP]

So what does F2 actually do ?

I am guessing that the screen dialog selects a recipe or something like that, and F2 calls data to be copied from an indirect address or an indexed address to an fixed (active) address. Or the other way around, from the fixed address to an indirect or indexed address.
If the indirection address or the index (S:24 if I remember correctly) is not set correctly, a non-existing address is attempted be loaded, causing the CPU fault.

You can fix this without changing the Panelview program by finding where in the PLC program the indirect or indexed address is accessed.
Before the code that performs the access to the indirect or indexed address, add a check of the indirection address or the index, and if not OK block the code that accesses the indirect or indexed address.

edit: Not having such a check in the PLC is actually an unacceptable failure on part of the original programmer.

one more edit: I assume that the access to the indirect address is done in the PLC code. Some HMIs however also have the possibility to access PLC variables by indirection of its own.
I do not know Panelview, if it is possible if indirection of addresses is possible in the HMI side. If it is, then that just goes to show why it is a bad idea to have indirection in the HMI.

 

[GaryS]

it looks to me lie when the F2 key is pressed you are passing an invalid value to the PLC
as was said earlier they are using indict addressing to select the recipe but the pointer (Passed in when the F2 key is pressed) is pointing to an invalid address, the processor locks up the way yours is I have seen it before
the fix is, in PLC program write a trap to only pass valid addressed to the index
if you can post the code we can have a look at it and maybe offer more detailed help

 

[JesperMP]

the fix is, in PLC program write a trap to only pass valid addressed to the index

How do you know which index value the operator intended to activate ?
Better is to block the code that does the transfer of data via indirection.

 

[AutomationTechBrian]

in PLC program write a trap to only pass valid addressed to the index
if you can post the code we can have a look at it and maybe offer more detailed help

Ok... now THAT gets the brain juices going! I've got an afternoon service call to make with a long drive on the freeway... or what I call "thinking time". I'm intrigued by the concept and I'm wondering the mechanics of it.

I'll send an email to my customer and see if he can get the original files sent to me. Right now, all I have is the uploaded micrologix file, with no comments or labels.

Thanks for your replies. I'm starting to feel like this would be a good issue to work through for future reference.

 

[Christoff84]

This is where the LIM instruction shines. If the value is outside the lower or upper limits the instruction is false.

 

[AutomationTechBrian]

How do you know which index value the operator intended to activate ?
Better is to block the code that does the transfer of data via indirection.

Yeah..... (more thinking). "via indirection"??

I just sent the email. We'll see if he's committed to fixing this problem.

 

[GaryS]

now you starting to understand
the trouble with this type of fault is when it happens the processor faults and stops
when you restart the processor the fault is cleared and the program runs normally
but you can only read the fault with the processor running
It makes for some real challenges to trouble shoot

 

[AutomationTechBrian]

now you starting to understand

when you restart the processor the fault is cleared and the program runs normally

But here's another consideration...

When the PLC faults, it doesn't always clear when you re-boot the PLC. Some "counter" needs to be cleared first.

....I remember doing something like this with a hand programmer on a Micrologix 1000 PLC. I remember that I was surprised that my RSLogix 500 wouldn't connect, so I was forced to use the hand programmer.

 

[GaryS]

I haven’t used a hand held programmer since the early days of the SCL 100/150 almost 30 years ago
I did run into one time where the SCL100 software would not connect and I had to reset the fault with the handheld programmer. I believe the problem was the com driver in windows I was running a DOS VM machine in windows 10 with the original SLC com adaptor at the time.

As for having to clear counter for a reboot I have to wonder about that. PLC’s load the current program and data table from the Ram in processor unless it is commander to load from an EEPROM if it’s available. That would overwrite any data table values changed while running. An over run counter value would be reset to the default value on boot. A math function on the SLC1100 has a math overflow fault bit that can be set with a bad calculation. The fault can be reset within the program or it is reset when the program boots.
This fault will only fault the processor if it is still set when program P2 loops to end rung to rung 0.
If the program tries to access a data table address that is not valid the program will stop.
Example: you have a data table N20:100 but your program tries to access the value at N20:101 or your program tries to access the value at N21:50 in either case the processor will fault because that address does not exist. This is standard with any PLC even in the Logix processors if you try to have the program access an index value that doesn’t exist it will fault. That’s why when using indirect addressing you must make sure the value is within the valid range.
In these cases restarting the program will clear the condition and allow the program to run.
This is why when I create an array in any processor I always make it a little larger the I think I need so if I do have index over run it doesn’t cause a fault.