"stuck key" anomaly RSLogixs5000v21

Hi, hope someone could enlighten me on this issue
I had that happen only twice in 2 years of operation of that particular program so its very rare (at least to detect). Here is what happened:
I was called to situation in which particular machinery was not able to start. After troubleshooting on line for a while I found that the momentary STOP button from one of the HMI screens was showing active in the PLC program. All what I had to do to "fix" it - was to toggle status inside PLC ladder logic.
Here are the other relevant details: PLC are interacting with number of redundant HMI's (running same Factory Talk View application on Windows based touchscreens) through HMI server on Industrial Ethernet network. At both instances that happen years apart I was able to toggle status from the PLC program which would imply that there was nothing wrong with HMI's, but rather it is related to the way and frequency (if any) this status is refreshed. Each time it was completely different switch and Page of application (two different machinery was controlled from same HMI).
At first time it happen, when I report it to my Engineering Department - I was told that AB is aware of "glitch from HMI", they call it "stuck key anomaly". However I was never forced to follow on it since there was no reoccurrence till now.
If anyone knows any official details from AB on that issue and forward it to me I would be very thankful
Cheers

What I would do is, put at the end of your main ladder a line that turns OFF all the HMI momentary PB's

AFI
--||--------------------------( )-

Even if you check PB's with a OSR if the PB is still pressed it will turn right back on and the scan will see that it's still on. If it has been released and the status isn't refreshed this will turn it off, until it's pressed again. If you have a lot of momentary PB's this line may get long, or split it into more lines.

If this was on a SLC500 or PLC5 and the PB's were programmed together in words of bits, then it would be faster to: MOV 0 [that word] at the end.

Hi and Welcome to the Forum!

I'm sure you are aware of these terms, having used v21, but just for correctness...

As of v20, RSLogix 5000 Enterprise Series software was retired in name.

As of version 21, it is now called Logix Designer and is packaged within the Studio 5000 suite of software products, which up to version 26 actually only contained Logix Designer. Studio 5000 version 27 introduced View Designer, which was released to design applications for the newer PanelView 5500 HMI terminals, and so Studio 5000 grows.

Buzzwords aside...

For me, the term "stuck key" specifically refers to the errors you receive on the PanelView terminals when there is a faulty touch cell or key. This is a hardware fault local to the terminal.

What you are referring to, for me, is more referred to as a "stuck bit". This is where an operator presses a HMI button, such as a momentary button, to set a bit in the controller and then when the button is released, the HMI is expected to reset the bit in the controller. Sometimes, for one reason or another, the HMI fails to reset the bit when the button is released.

For Logix controllers, and many others, it is good practice to use the controller to reset the bit once you have used the set condition and not rely on the HMI to perform the reset.

In Logix controllers the norm is to let the HMI set the bit, execute the logic, then reset the bit in the controller. This is often seen for the likes of Start, Stop, Reset functions, etc. This way the possibility of the HMI failing to reset the bit is ruled out.

I would add that one advantage to keeping your HMI bits sequential within the same word addresses is that you can reset multiple bits at once, rather than many separate instances.

But some do prefer to just do it as they go as it appears somewhat clearer to the next guy.

Regards,
George

Thanks Geospark,
you are completely right on all accounts! and most importantly the sound argument you gives me - it's opening shot for this case (going through the "big boys company" process which I explained for Aabeck - his reply was in line with what I would do as well).
When I think about it - in case I get too much grief from them, I could probably stir some pot on line you give me. I have been troubleshooting all kinds of problems with their program and sometimes I create temporary edit with "troubleshooting logic" to capture momentary events that cause problems randomly. Because of that I'm perfectly aware of lots of warnings with all kinds of shabby programming they have (some as simple as same OTE used twice )
So - summing, thanks for great sensible argument, for working solution (to both of you) - now if anyone got some official AB paper - that would cover the whole possible position.
Thanks a bunch

Sorry Aabeck,
this is first time I'm using forum and my reply to you must went nowhere (I'm now in Asia with really weak Internet connection - nothing makes me wonder in that regard). So anyway - what I was saying, is that my challenge is to present issue for scrutiny in big companies environment. The people I deal with on those issues are not very knowledgeable (but very skilled on debating without the merit ;D), I'm sure first I will here is how come we did not have that issue since August 2013 (last real program update, when we switch among the others RS to version 21). this program is big (9MB) and it have lots of screens controlling many different machines in this process, since this is RS5000 - unlike in RS500 they use direct addressing. It is mind boggling hybrid verity sourced from original program that was created in Siemens Step7 with overlay of new English abbreviations/connotations created by group of programmers having no working knowledge of controlled applications etc... (I could rave on and on, simply stating they were inexpensive and work fast )
Thanks for your advise - I couldn't agree more for solution (it will be however whole new routine to address whole HMI functionality of possibility of stuck bits - which will force me to go through approval process)
Thanks again!

I recommend that you take a quick look through the following thread ...

http://www.plctalk.net/qanda/showthread.php?p=620313&postcount=5

then search for Article 29486 on the Allen-Bradley Knowledgebase ... you'll have to have a TechConnect password to access it ... that might provide the "official" information that you're looking for ... be sure to read the "Important Note" at the very bottom ...

Well, on the surface, that does sound like one big, bloated, puss filled mess of a conversion, most likely to cause headaches, and has "please redo me from scratch" written all over it!

I don't know if this has enough ammo to fire a decent salvo back at them, but it's all I could find "official" on the matter...

29486 - Troubleshooting "stuck bits"
Access Level: TechConnect

Pay special attention to the "IMPORTANT NOTE" at the end.

I hope you can access that and I hope it helps.

I would just like to add though that the controller reset method is more intended as a guideline or good practice in programming, more so than a stipulation. I would always recommend it as such to a customer if they want to avoid experiencing "stuck bit" syndrome.

But something tells me you need to cure this lot from "stuck in the mud" syndrome first.

Regards,
George

Hehe Ron,

How is my twin doing today?

scary isn't it? ...

Wow, I was just feeling scared there too!

Telepathy, it's the new higher order programming language, don't you know.

One more time, thanks a bunch to all of you - I will get my Rockwell access tomorrow when Houston gets to life ). I cant belief we are already on v.27 - this is another thing I will need to update when I get broadband access to Internet!
I enjoyed the thread Ron mention, in which the AFS member note was something that be very useful for a lot of some of the "industrial programmers" that are core of our Engineering group. I definitely will.
I'm grateful to you guys )

ChrisKM said:

...I cant belief we are already on v.27 - this is another thing I will need to update when I get broadband access to Internet!...

Click to expand...

They've actually just released Studio 5000 v28, so you'd better get your skates on!

Little Update...

Studio 5000 v27 introduced a feature I had read about when it was released, but I had forgotten about it when addressing this thread. I was just reminded of it again today and thought it relevant to come back and mention it here...

With the release of Studio 5000 v27, they introduced a new instruction to combat the very issue we were discussing here, the HMI "stuck bit". The new instruction is called the "HMI Button Control" or "HMIBC".

So, what is the HMI Button Control Instruction?

The HMI Button Control (HMIBC) instruction can be used in conjunction with a PanelView 5500 Human Machine Interface (HMI) to provide operators with the ability to initiate machine control operations, such as jogging a motor or enabling a valve, with a high degree of accuracy and determinism. The HMIBC instruction also provides built-in communications diagnostics that permit the instruction to automatically reset itself if the communications from the controlling HMI become unavailable.

Each Logix controller is able to support up to 256 HMIBC tags. Additionally, the HMIBC instruction supports the ability for up to 32 PanelView 5500 HMIs to simultaneously communicate and control the instruction. The HMIBC instruction goes active and enables its output when a PanelView 5500 HMI device initiates a button control operation associated with the instruction's instance tag.

Important:

You must be using a PanelView 5500 terminal to use the HMIBC instruction.

To function, the Logix controller's I/O Configuration must include all of the PanelView 5500 HMIs that need to interact with the HMIBC instruction.

Additionally, the application created for each PanelView 5500 HMI must include button actions configured to reference each of the tags associated with the HMIBC instructions that are to be controlled.

Safety Advisory:

This instruction must be executed at least once per scan. It should not be jumped over.

Note the following about the HMIBC tag. The HMIBC instruction uses the HMIBC Data Type, which...

Is available at Controller and Program scope.
Is not available within Add-On Instruction scope.
Can be used in a Jump to Subroutine (JSR).
Cannot be used with input and output program parameters.
Is not available within a safety program.
Must have an external access value of Read/Write. You are not given the option to choose other external access values.

The HMIBC tag has import and export formats for .L5K, .L5X, and .CSV.

Because the PanelView is added to the controller's I/O Configuration, there is a monitored connection at all times. This is how the instruction can detect if the communications to the HMI have been lost and reset the ButtonState tag within the HMIBC Data Type.

While it is specific to the new PanelView 5550 HMI terminals, it is still interesting to see them addressing this all too common a problem in some shape or form.

Regards,
George

Thanks again George,
this is really invaluable info. I mention before that I'm working down the line of automation on site support. You don't usually program there primary functions but if you able there is a lot of tweaking you need to do to address problems miss by OEM Engineering. This one is very much what you deal with, problem that in my case happen less then once in blue moon. You know for a fact that cause is very strange but real, intuitively you know that need to be fix through some sort of reset - but people around you are doubting that due to time it took for glitch to act. Without help of people like you I would be really in the dark... and since "office duds" nature is not very inquisitive, it would take some serious accident to fix it. I cant do this now - but as soon as I came to our office back in USA will get them to look at all our programs with this in mind.
So thank you very much again, don't want to sound hush, hush - but who knows, you may just saved someone life in future ) !
Cheers

I have had this issue quite a few times with RedLion Crimson 3 HMIs. It usually happens when a button is pressed and the screen changes to a new page (like a prompt or on action). The button is not active on a screen so its status is not scanned and it stays in the last state. If the button is a momentary I make sure the PLC logic turns it off once it is "seen" by the PLC. It caused us serious grief a couple of times so remember - even if you have an HMI with all the button you will ever need - ALWAYS HAVE A HARDWIRED ESTOP AND MAYBE ALSO A STOP BUTTON.

Also forgot to mention, once or twice we had a stuck button was when the OP touched the screen he left behind a "blob" of grease. The screen though his finger was still there. So keeping the screens at least kind of clean is important. I make a "Clean Me Screen" (an empty white screen using only a return button) so the operator can clean the screen with out pushing buttons and making unexpected things happen.