RSView ME - Momentary Push Button Stuck?

I have a momentary push button that sticks. I don't know how better to describe it. It is normally open, so when I press it, it changes tag L1.MF_Input to a 1. L1.MF_Input is used in RSLogix 5000 to move a input into another tag. I only use it once, as an XIC. About once every 3-6 pushes, it sticks in 1, as if it is a toggle button. If I push the button again, it will clear the problem about half the time. I have tried rebooting my machine, recompiling the RSLogix, creating a new RSView runtime file, and have varied the time the pushbutton stays pressed from 250ms to 1s.

Has anyone else run into this or have any suggestions?

Thanks
Steve

I've seen this before. Your best option is, first of all, to oneshot the move. I would also recommend making the pushbutton a "set" instead of direct and doing an unlatch in the PLC after the move is completed. This insures the button won't latch itself on and that the PLC sees the input and completes all required logic.

Are you running the application on a PV plus touchscreen?

There was a version of firmware in the PV plus that had an issue such as that. If the unit is fairly new (Last year or so) then I doubt that that is the issue as it was corrected.

Dr. Watson: I had originally one shotted the move, but I haven't used one shots enought to know if I had done it properly, so I removed the ONS.

Your suggestion is to do something like the following?

RSLogix:
XIC:L1.MF_Input
ONS:Storage_bit
MOV:L1.MF_Inputted to L1.MF
OTE:L1.MF_Input_Unlatch

And in RSView:
Create a latched pushbutton with connection being L1.MF_Input and handshake of L1.MF_Input_Unlatch.

That seems like it would work, but can you give me a quick explanation of a one shot? I've read the help files, but still don't quite get it.

Wedee: It is a PVPlus 1000, about a year old. I think the firmware should be up to date. This also happens on my diagnostic terminal when I test the application from RSView ME as well.

Thanks for the quick replies.

Steve

OK.. if it happens on the diagnostic terminal then its not the PV Plus firmware.....

As for other potential issues, It seems as if you have looked at the obvious:
1. Check that the tag isnt used as a coil, or is being written from somewhere else
2. Do a "Search and replace" on that screen just to look at where the tag is used on that screen. (Use Ctrl A to "select all" just incase there is an object under one another)

I would do it this way ...

XIC:L1.MF_Input
MOV:L1.MF_Inputted to L1.MF
OTU:L1.MF_Input

Leave out the ONS, and change the OTE to OTU with the same address as the pushbutton. Unlatching it immediately after the action is complete is effectively a one shot. The only drawback is that you'll never see the button in the true state when monitoring in RSLogix. You could do this to provide that capability, but the stuck button problem would remain and the MEM bit would never re-latch:

Rung 1:
XIC:L1.MF_Input
ONS:1SHOT
OTL:L1.MF_MEM

Rung 2:
XIC:L1.MF_MEM
MOV:L1.MF_Inputted to L1.MF
OTU:L1.MF_MEM

This stuck pushbutton thing can happen with any HMI connected through a comm channel. I have seen it with all AB products from RSView32 to PV550s. Something to keep in mind when programming ... Always think about: "What happens if the blue hose breaks, or the HMI locks up while this button/device is on?". Another common method to deal with it is tie the button to a TON and use the TT bit as the button in the program. Set the PRE to the maximum on time allowable, and use the DN bit to unlatch the button and/or generate a stuck button alarm.
Hope this helps
Paul C.

OkiePC said:

I would do it this way ...

XIC:L1.MF_Input
MOV:L1.MF_Inputted to L1.MF
OTU:L1.MF_Input

Leave out the ONS, and change the OTE to OTU with the same address as the pushbutton. Unlatching it immediately after the action is complete is effectively a one shot. The only drawback is that you'll never see the button in the true state when monitoring in RSLogix. You could do this to provide that capability, but the stuck button problem would remain and the MEM bit would never re-latch:

Rung 1:
XIC:L1.MF_Input
ONS:1SHOT
OTL:L1.MF_MEM

Rung 2:
XIC:L1.MF_MEM
MOV:L1.MF_Inputted to L1.MF
OTU:L1.MF_MEM

This stuck pushbutton thing can happen with any HMI connected through a comm channel. I have seen it with all AB products from RSView32 to PV550s. Something to keep in mind when programming ... Always think about: "What happens if the blue hose breaks, or the HMI locks up while this button/device is on?". Another common method to deal with it is tie the button to a TON and use the TT bit as the button in the program. Set the PRE to the maximum on time allowable, and use the DN bit to unlatch the button and/or generate a stuck button alarm.
Hope this helps
Paul C.

Click to expand...

Okie is correct...the oneshot is really not necessary is the unlatch is done right after the move, but I typically put them in anyway mostly out of habit (and perhaps a bit of anal retentiveness).

Thanks for the advice. What type of button should I use in RSView? Just a momentary, and the logic will prevent the sticking?

You could use momentary, set, or maintained. If you use maintained, it will toggle the state of the button each time it's pressed. I'm not sure if RSView always changes the state of the bit address, or alternates each time using some internal method to remember. It may only work every other time if you use maintained if the latter is true.

If you use a momentary or "set" action, it should work fine.
If you use a set action and have a choice of press action or release action, use the release action to trigger the write command. (RSView32 gives you choices, not sure about other versions).

You can probably just use a momentary, but agaain I would use a set since I'm resetting it in the logic. That way you know the input got to the plc and was processed.

And ditto on the release action to trigger the command.

Thanks again. I don't think RSView ME has a "set" pushbutton though. At least, I haven't used one. I think I used on in RSView32, though. Does it exist in ME?

Using a momentary with the unlatch seems to have fixed the program. Before now, I thought that the only purpose of an unlatch was to reset a bit that had been set by a OTL, but I guess it makes sense that it would do the same to a stuck bit.

Quick question for you all: My system controls and automatically balances a ventilation system, based on specific pre set configurations. So i have 15 individual lines with dampers and air flow stations. Each line is controlled individually, but all use the same logic. I figured out how to create a routine and pass parameters, but I've read in some places that using routines and passing parameters (I have two user defined tags that I send to the routine, each has 17-20 variables) can significantly slow down your program. Is this something I should be concerned about? Also, is there any way to see how long it takes RSLogix to go through 1 iteration of the program? Also, is there a better way to do this? I am just afraid that making 15 different routines, and having to change all 15 anytime a small change is needed would not be practible.

Thanks
Steve

I don't think you'll have an issue with indirect programming...I've used it quite a bit in a variety of processor families for repetitive processes. The only issue I've had with it is difficulty in troubleshooting. You should be able to right click on the task and see the real-time scan time of the task to let you know how long it takes (I don't have the software on theis machine so I can't look it up right now).

Just a confirmation--RSView ME does not have the "Set" button. It is found in RSView32 and RSView SE, however.
Rick

rgurin said:

Just a confirmation--RSView ME does not have the "Set" button. It is found in RSView32 and RSView SE, however.
Rick

Click to expand...

It does however have a 'Latched' PB, which is the same thing.

As far as using parmeterized subroutines, there isn't that severe a penalty time wise. To monitor scan time, right click the task (ie, main task), select properties, and Monitor. If you are online, you will see the scan times for that task.

rdrast & rgurin, thanks for the input. This is my 3rd or 4th PLC project, but the first that I've been able to try out using the subroutines with parameters.

Also a big thanks to Wedee and Dr. Watson and OkiePC. I really appreciate the help, and am really impressed with how quickly I had responces. I was figuring that I wouldn't hear anything back for a couple of days, at best.

Steve