AB SLC 5/03 Strange Behavior

I am working on a program that is behaving oddly and need some expert guidance. I am a novice and understand the basics of programming, but there is something I am missing. The PLC is an Allen Bradley SLC 5/03 with a Panelview attached to it for operator input / control. On the surface the program appears to operate correctly, but digging deeper there are some things that I don't understand. Below is an example, bit B3:0/15 is an input from the touchscreen to put the machine into automatic mode. When the button on the screen is pressed and all else on the rung is in proper order, the rung goes true and auto mode is latched on. If the hydraulic motor is switched off, the rung goes false, but the HMI input stays true even if the HMI cable is disconnected, so if I start the pump motor the rung goes back into automatic mode. Why would bit B3:0/15 stay high?

welcome to the forum ...

there could be a lot of other explanations - but the most likely is that your "button" on the HMI is set up as something besides "Momentary" ... ("Maintained" for example) ...

do you have the software to check the button's configuration/setup in your HMI program? ...

No, I don't currently have access to the HMI programming software (working to get it). I have checked the program and this bit is only used on this one rung, no where else in the program. If the cable to the HMI were disconnected, how would the processor know how the button was programmed on the HMI?

And thank you for taking the time to reply.

If the cable is disconnected from the PLC, the HMI usually retains the last state, and the PLC will retain the last state - just the PLC won't be able to be changed, and pushing buttons on the HMI may change pages on it, so it appears to be working, but not actually.

If the cable to the HMI were disconnected, how would the processor know how the button was programmed on the HMI?

Click to expand...

let's talk about the "disconnected cable" idea ... (note: many "experienced" programmers don't fully understand how this part of an HMI works) ...

first suppose that you're pushing a "REAL" (electrically wired button) and that the button has been wired for Normally Open operation ... when the button is pressed, an electrical current flows through the PLC's input module circuit ... this places a ONE status into a bit/box in the PLC processor ...

then when the button is released, the contacts OPEN ... no current flows – and the bit/box goes to a ZERO status ...

but it's different with a "button" on an HMI screen ...

now suppose that you're pushing a "VIRTUAL" (programmed button) on your HMI screen ... and suppose that the button has been configured for Momentary - Normally Open operation ... when this type of button is pressed, the HMI sends/communicates a MESSAGE to the PLC – and this message is what places a ONE status into a bit/box ...

then when the virtual button is released, the HMI sends/communicates ANOTHER (separate) message to the PLC – and this second message is what places a ZERO status into the bit/box ...

keep that "TWO SEPARATE MESSAGES" concept in mind ...

so ...

if the HMI happens to be placing a ONE into your PLC's bit/box – at the time that the cable gets disconnected – then there is no reason for the bit/box inside the PLC to change back to a ZERO status ...

that's just one way to explain what I "think" that you're reporting ... with more details we might be able to come up with something else ...

Thanks Aabeck and Ron for the reply. I will try to get access to the HMI configuration next week to see if the button is maintained or momentary.

I personally don't trust HMI/SCADA momentary buttons. I always write logic to unlatch/turn off the bit after a short period on time (e.g.5 sec).

If the HMI/SCADA turns off the bit great, if not the logic takes care of it.

I do something similar to Mickey. I have a few rules:

- ALWAYS use "set" or "latch" buttons on the HMI, not momentary. Because I've had it happen too many times where the button gets "stuck" on. Usually pressing it again will "unstick" it - think about Ron's example above, where it has two separate messages - obviously the "turn off" message didn't make it back to the PLC, and pressing the button again will give it another chance. But if the button has since disappeared from the screen, well, then what? Setting them to be latch/maintained buttons means that it's at least always going to behave consistently, and you can deal with it consistently.

- Only ever use the button in the PLC code ONCE. Even if you just use it to turn on one coil in the PLC which is then used in 1000 other places, it just makes it easier to see what's going on, and also makes my third "rule" work nicely:

- Unlatch the button from the HMI in the same rung it's used in. If I'm using the RSLogix 5000 platform (which the OP is not), I put the OTU directly after the XIC, even if it's right at the start of the rung. I know that some people don't like output instructions programmed like this (sorry!) but I figure they're placed in pairs, and those two are the only occurrences of the bits in the whole program, so it's easy to see what's going on. And this way I'm guaranteed that when the HMI turns "on" the button, the rung sees it, turns "off" the button, and then carries on doing whatever the button was supposed to do in that rung. I'm never left with a button stuck on. It's important to note that you have to put this logic at the start of the rung, so that other rung conditions don't preclude it from being executed.
If you're using the RSlogix 500 platform, you have to put your OTU on a separate rung (I make it unconditional) directly below the rung the XIC is used in. The reason for this is because in RSLogix500, all output instructions have to be at the end of the rung. And if you put your OTU at the end of the rung, other rung conditions may not permit your OTU to be activated. Let's say you have condition A, B and C in series, which activates an OTE for output D. Condition B is your HMI pushbutton, so as well as an OTE "D", we'll have an OTU"B" to turn off your HMI pushbutton. But if your condition C is FALSE and someone presses the button on the HMI, the output instructions will not get executed, so your button will remain "stuck on".

Hopefully there's something in my ranting there that will help the OP troubleshoot/solve his problem

Thank you ASF and Mickey, the advice is a quick easy change and makes sense, I will try to implement tomorrow and see if this changes some of the other unexplained problems. At least that will be one less thing to have to be concerned with. I appreciate everyone's feedback.

I follow ASF's rules almost exactly, never trust an HMI

I understand the theory behind using that method but wouldn't using a oneshot accomplish the same thing? If the HMI screw up and leaves the bit 1, it doesn't matter. Or am I missing something in the grand scheme

dlweber said:

I understand the theory behind using that method but wouldn't using a oneshot accomplish the same thing? If the HMI screw up and leaves the bit 1, it doesn't matter. Or am I missing something in the grand scheme

Click to expand...

Its the HMI controlled bit you want to turn off.

I think Ron’s first post is spot on. If the button is a momentary button and it’s “status” is looking at the status of B3:0/15 then when B3:0/15 is off and you push the button then B3:0/15 goes high and the status show that. In order for the status on the HMI to show B3:0/15, B3:0/15 needs to go low which it won’t unless something toggles the bit. One thing you could do is, while online with the PLC, push the button on the HMI watching the status of B3:0/15 in the PLC. Then using RSLogix, toggle B3:0/15 and the HMI button show go off.