Momentary pushbutton problems

[rmiell 0]

Hello. New to this forum, but it looks like I have come to the right place. I have a similar problems as stated on this other forum PLC.net and I thought I would ask you all about this. Any suggestions/comments would be greatly appreciated. Rick Miell PS. Keep up the good work answering these postings

[TimWilborne 108]

Whats the question

[rmiell 0]

I thought a link to the other forum would save me from having to type it all again............ My RSViewME display is where a momentary pushbutton resides. It controls an output in a Micrologix 1200. Intermittenly, after the pushbutton gets pressed, the output stays on, instead of momentary on/off. The question (does this happen, and what to do) was asked by another poster, and he received a few replies that it does happen to others. One poster replied that ..." I found the safest way is to unlatch the bit in the PLC once the action that was supposed to take place (e.g. start a motor) is accomplished. The way I accomplished this is easily is putting all the N.O. buttons in the same word or set of word. Then a put a timer on the word whenever it is not equal to 0 (one of the buttons was pushed) and when the time ends, I set the word to zero". My question is two-fold. #1: What is meant by, or how do I accomplish ..."putting all the N.O. buttons in the same word or set of word"? #2: How do I ... "when the time ends, I set the word to zero"? I am using RSLogix500 for my ladder, and RSViewME for my displays, etc... I replied back to the posting last week, but have not heard anything from that forum yet. TIA Rick

[TechJunki 0]

What version of RsView are you using... I believe 3.2 is the latest if you do not have 3.2 I would first try upgrading. As for your questions.. The same word is just that, if you have a INT data type you will have 16 bits to use in that word for PB's. If you have DINT data type you will have 32 bits in the word to use as PB's. When the timers done just move a 0 into the entire word clearing all bits in the word. Here is a link to another topic on the subject.. http://forums.mrplc.com/index.php?showtopic...31&hl=momentary

[TimWilborne 108]

I know this doesn't answer your question and isn't what you want to hear, but you really need to scrap the Panelview Plus and go with the Standard Panelview. The Panelview Plus is still full of flaws including this lockup problem. I also does not support Class 1(I/O) messaging which is very important safety consideration. This allows the PLC to know when the Panelview stops responding so it can do something about it. The Panelview Plus is a very nice display but isn't ready for machine control where safety is any consideration. We ended up scrapping them. They need a few more years

[rmiell 0]

Thanks for the info. I am not using PanelView. What I have is a PC connected to a ML 1200. The pc has a screen that the police dispatcher can click on, using mouse. The pushbuttons on this screen control different things, such as electric door strikes, and 4 garage door operators(open, close, stop). My problems comes into being when the dispatcher clicks on the "close" pb for one of the doors, to close it. The door closes ok, and stays that way until the dispatcher get a request to open that same door. The door will open, correctly, but at the point where the door opens all the way, the operator has a signal from the close output (because it is "stuck on"), and will close the door right away. You can see that this is a problem, since the fire truck driver has started into the bay with the open door. Luckly no damage to trucks yet, but could easily happen. Hence the request, from me, to add ladder instructions to keep this from happening. The RS equipment has replaced a manual pushbutton setup in dispatch, which came about when the dispatch area was remodeled last year. Instead of installing a cheesy pushbutton panel on a brand new console, I talked the powers-to-be into using a ML system, so dispatcher can control these doors from their pc. I don't really want to have to rewire the operators to give me open/close indications at my ML1200, since it is somewhat limited on inputs. I think the post about unlatching the pushbutton might work, but if anyone has any other suggestions, please feel free to contact me, or post the info here, in order to help others who might have this same, or similiar problem. Again, thanks. Rick Miell

[dleehanson 0]

This is pushbutton logic that i guarentee will always work everytime. I would also disagree with scraping the panelview plus terminals. As every application is only as good as the program is. HMI_Pushbutton.RSS

[TimWilborne 108]

Hard to write a good reliable program with the hardware as flawed as it is. My problems were safety issues with the panelview plus that were acknowledge by Rockwell. I was just trying to warn people to think twice if they were doing machine control with it that could cause injury. But go ahead and write your "good program". It's your liability Edited 14 Dec 2005 by TWControls

[panic mode 246]

exactly, if the bit B3:0/0 in the example stays latched, it's a dead end... one can try clearing B3:0/0 either periodically or as soon as it's set (in this case it would work as one shot anyway) but this is not solution, only workaround for product flaw. this could be ok to detect moment button is pressed but one would not know how long it was pressed (like for jog etc.)

[hakko808 0]

So if I follow the topic correctly, RSViewME is running on PC and not on a panelview? Not sure if it is the same as on RSView32 on PC but if mouse is moved away from pushbutton while mouse button is depressed, the button will stay latched. Could this be the problem you are having? If you are using a PC, have you considerded getting rid of the rather flakey and limited ME in favor of RSView32?

[rmiell 0]

This could be whats happening. Thanks for that info. Rick Miell

[gravitar 3]

Well if you end up "scrapping" any more, let me give you my address.. I'll happily cover your shipping charges and you can take heart that these PV+ terminals won't end up in a landfill somewhere :)

[OkiePC 14]

I've seen this "stuck button" problem with every AB HMI product I've used including RSView32. I unlatch all momentary pushbuttons when the action is complete, or when the Node stops communicating. For jog buttons, I have resorted to putting a time limit on the jog command and unlatching it when the timer is done. I will only use real hardwired pushbuttons for jog controls where safety is a concern.

[TimWilborne 108]

There is one of the problems. With RsView and the Panelview Plus you really have no way to know if the node is communicating. Although you can do some crude messaging to check if the node is present. With the Standard Panelview and any of the logix platforms the Panelview can be added into the module configuration so the processor polls the panelview and knows when it stops communicating. It is much more deterministic similar to devicenet. The way most people setup the Panelview (and the only way you can currently setup the Plus) you just blindly hope that the thing keeps communicating. Thats why you end up with all of this code trying to unlatch things that shouldn't lock up in the first place. But Class 1 I/O messaging is coming to the Panelview Plus and I'll definately be going with the new Panelview when Rockwell completes that. It has many more pros than cons compared to the Standard Panelview but the communications quirks need to be worked out first.

[OkiePC 14]

With DH+ you can use the status bits for active nodes to detect when comms stop ... It takes a few seconds for the bit to turn off, but it's better than nothing.

[TimWilborne 108]

Little over 100ms with Standard Panelview in I/O configuration of Logix