You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old March 7th, 2018, 11:00 AM   #1
Mteller
Member
United States

Mteller is offline
 
Join Date: May 2017
Location: Michigan
Posts: 10
Factory Talk ME Press and hold button

I have added a new button to a HMI(touchscreen). The button is always on the screen and is low(0). When they press the button it goes high(1) and turns green. The button is for a re-work mode. I want it to be a press and hold for 2 sec button. Than turn off once the mech. cycles. It took me some time how to figure out the button than the HMI/PLC tag thing. I see the status change on the PLC side when they press the button. I get the input from the button and we are able to run in re-work mode. I just don't want the button getting press accidently that's why I want to make it a press and hold button.
Thanks
  Reply With Quote
Old March 7th, 2018, 11:34 AM   #2
A_G
Member
United States

A_G is offline
 
Join Date: Jul 2014
Location: MA
Posts: 132
I don't have FTView Studio open right now but I think you can select the button type to be "momentary". Then link the button to a PLC tag (for example, PB1). Then write some logic in the PLC like this: when PB1 is On, start Timer1. Set the Pre of Timer1 for 2 sec. When Timer1 is Done, then run your equipment.
  Reply With Quote
Old March 7th, 2018, 01:07 PM   #3
cwal61
Member
United States

cwal61 is offline
 
Join Date: Jan 2011
Location: NC
Posts: 980
Under the General Tab of a momentary push button there is hold time setting. You can select up to 5 seconds.
Attached Images
File Type: jpg hold time.jpg (35.9 KB, 143 views)
  Reply With Quote
Old March 7th, 2018, 02:07 PM   #4
DonBlack
Member
United States

DonBlack is offline
 
Join Date: Aug 2014
Location: connellsville, pa
Posts: 16
i thought the same thing as cwal61 for a minute, i read it again and i believe he wants the operator to have to hold the button in for a set time before the equipment will run.
the hold setting on a momentary button would keep the bit true for the setpoint time.
I agree with A_G's method
  Reply With Quote
Old March 7th, 2018, 04:55 PM   #5
ASF
Lifetime Supporting Member
Australia

ASF is offline
 
Join Date: Jun 2012
Location: Australia
Posts: 2,688
Quote:
Originally Posted by DonBlack View Post
I agree with A_G's method
I don't.

Remember that a "momentary" button on a HMI is not the same as a "momentary" physical pushbutton wired to an input.

With a physical pushbutton, as long as you hold it down, power flows to your digital input, forcing your input to stay on. The moment you release the button, power flow to your input stops, and your input turns off.

With a HMI button, when you press it, the HMI sends a single message to the PLC saying "set bit [whatever] to 1". The PLC does so. When you release the button, the HMI sends another message to the PLC saying "set bit [whatever] to 0". The PLC does so. But in between those times, the HMI is not actively holding the PLC tag in the "on" state. Nor is the HMI actively holding the PLC tag in the off state when the button is not being pressed.

Now, what happens if there's a momentary glitch in the communications just before you release the button? Or what if a packet is dropped somewhere and that single "set bit [whatever] back to 0" message doesn't get through? That single message is the only thing that "releases" the pushbutton tag, so if it gets lost, as far as the PLC is concerned, your button is still being pressed.

This doesn't happen hugely often, but it happens often enough that I will never ever use HMI buttons without buffering them through the PLC, like this:
Code:
|
|   HMI_PB_Start                     HMI_Start
|--------| |-----------------+---------(   )---|
|                            |
|                            |      HMI_PB_Start
|                            +---------( U )---|
...so that as soon as I see the "Start" pushbutton pressed, I turn it off myself inside the PLC, and set a "HMI_Start" bit for one scan to be used everywhere else in the code.

I say "it doesn't happen hugely often", but by making the operator press and hold for two seconds, you're significantly increasing the likelihood that somewhere in that two second period you'll experience such an issue.

The method suggested by cwal is where I'd be looking. This function exists for exactly this reason. Your HMI sends no message at all to the PLC until the button has been held for two seconds, then it sends the "set bit [whatever] to 1" message. When you release the button, it will send the "set bit [whatever] to 0" message.

However! That still doesn't completely alleviate the issue above! If you're using this button as a jog control of sorts, there's still the possibility of the button release message getting lost. Whenever I have to use a HMI button for a jog function, I always have logic such that if my motor becomes "not ready", I immediately turn off the jog pushbutton. That means I can hit an e/stop, turn off a motor isolator, trip a breaker, or whatever else I need to do to enforce a stop, and know that my HMi button has now been reset as well. Otherwise, as soon as I release the e/stop and reset the safety circuit, the motor may very well pick up and run again, seeing as (as far as it's concerned), someone is still holding their finger on the jog button.
  Reply With Quote
Old March 8th, 2018, 12:49 PM   #6
arlenjacobs
Lifetime Supporting Member
Canada

arlenjacobs is offline
 
Join Date: Sep 2014
Location: Kelowna
Posts: 631
FYI: The button issues that ASF is talking about exists in every HMI.
Something to think about.

There is one HMI that I know of which uses class 1 comms (like an Ethernet I/O module). But that's a limited scope and a different topic.

Quote:
Originally Posted by ASF View Post
Remember that a "momentary" button on a HMI is not the same as a "momentary" physical pushbutton wired to an input.

With a physical pushbutton, as long as you hold it down, power flows to your digital input, forcing your input to stay on. The moment you release the button, power flow to your input stops, and your input turns off.

With a HMI button, when you press it, the HMI sends a single message to the PLC saying "set bit [whatever] to 1". The PLC does so. When you release the button, the HMI sends another message to the PLC saying "set bit [whatever] to 0". The PLC does so. But in between those times, the HMI is not actively holding the PLC tag in the "on" state. Nor is the HMI actively holding the PLC tag in the off state when the button is not being pressed.

Now, what happens if there's a momentary glitch in the communications just before you release the button? Or what if a packet is dropped somewhere and that single "set bit [whatever] back to 0" message doesn't get through? That single message is the only thing that "releases" the pushbutton tag, so if it gets lost, as far as the PLC is concerned, your button is still being pressed.

This doesn't happen hugely often, but it happens often enough that I will never ever use HMI buttons without buffering them through the PLC, like this:
Code:
|
|   HMI_PB_Start                     HMI_Start
|--------| |-----------------+---------(   )---|
|                            |
|                            |      HMI_PB_Start
|                            +---------( U )---|
...so that as soon as I see the "Start" pushbutton pressed, I turn it off myself inside the PLC, and set a "HMI_Start" bit for one scan to be used everywhere else in the code.

I say "it doesn't happen hugely often", but by making the operator press and hold for two seconds, you're significantly increasing the likelihood that somewhere in that two second period you'll experience such an issue.

The method suggested by cwal is where I'd be looking. This function exists for exactly this reason. Your HMI sends no message at all to the PLC until the button has been held for two seconds, then it sends the "set bit [whatever] to 1" message. When you release the button, it will send the "set bit [whatever] to 0" message.

However! That still doesn't completely alleviate the issue above! If you're using this button as a jog control of sorts, there's still the possibility of the button release message getting lost. Whenever I have to use a HMI button for a jog function, I always have logic such that if my motor becomes "not ready", I immediately turn off the jog pushbutton. That means I can hit an e/stop, turn off a motor isolator, trip a breaker, or whatever else I need to do to enforce a stop, and know that my HMi button has now been reset as well. Otherwise, as soon as I release the e/stop and reset the safety circuit, the motor may very well pick up and run again, seeing as (as far as it's concerned), someone is still holding their finger on the jog button.
  Reply With Quote
Old March 13th, 2018, 01:40 PM   #7
Geospark
Lifetime Supporting Member
Ireland

Geospark is offline
 
Geospark's Avatar
 
Join Date: Feb 2012
Location: Kildare
Posts: 2,471
Quote:
Originally Posted by arlenjacobs
FYI: The button issues that ASF is talking about exists in every HMI.
Something to think about.

There is one HMI that I know of which uses class 1 comms (like an Ethernet I/O module). But that's a limited scope and a different topic.
I'm not sure if you mean the following HMI, but if you don't mind me mentioning it (I'm so exited by it!) - I've used the HMIBC instruction (introduced at v27) with the new PanelView 5500 terminals and it's a brilliant feature. The terminal is added to the I/O Configuration to utilize a fast Class 1 connection at 100ms which is monitored under the watchdog timer. Once the connection is maintained, the controller tag assigned to the instruction is reset automatically each and every time. No need for catch & release logic. If the HMI loses comms the instruction resets the tag value automatically. It is very responsive, especially for quick touch jogging.

1046714 - Using HMI Button Control (HMIBC) instruction with a PanelView 5500
Access Level: TechConnect

For the age old issue of "stuck bits" - Yes, the catch & release method, as I call it, and however you achieve it, is a must in your logic to prevent undesirable retention of HMI button actions.

I would also add that the use of the mentioned popup confirmation window is also best practice for the prevention of unintended HMI button actions.

Good stuff all round.

Regards,
George
__________________
"A little nonsense now and then is relished by the wisest men".
  Reply With Quote
Old March 14th, 2018, 07:34 PM   #8
arlenjacobs
Lifetime Supporting Member
Canada

arlenjacobs is offline
 
Join Date: Sep 2014
Location: Kelowna
Posts: 631
Quote:
Originally Posted by Geospark View Post
I'm not sure if you mean the following HMI, but if you don't mind me mentioning it (I'm so exited by it!) - I've used the HMIBC instruction (introduced at v27) with the new PanelView 5500 terminals and it's a brilliant feature.
Yep, the same one.

You need both the PV5000 terminal and a Logix controller.
It solves all the problems you didn't know existed in an HMI push button.
  Reply With Quote
Old March 10th, 2018, 01:34 AM   #9
rupej
Member
United States

rupej is offline
 
Join Date: Sep 2014
Location: NC
Posts: 429
Quote:
Originally Posted by ASF View Post
|
| HMI_PB_Start HMI_Start
|--------| |-----------------+---------( )---|
| |
| | HMI_PB_Start
| +---------( U )---|
[/code]
This is a great idea, but I started using another method that which elimates the need for two of each PB tag, and takes a bit less coding- I'm sharing because I thought others may be interested:

I simply parallel all PB bits into a timer, and if the timer runs for two seconds, unlatch each PB. This allows them to "stick" but only for two seconds. The rung is simplified further if you use a single DINT that holds all of the PB bits.

IF PB_DINT > 0 for two seconds, CLR PB_DINT
  Reply With Quote
Old March 12th, 2018, 02:26 PM   #10
arlenjacobs
Lifetime Supporting Member
Canada

arlenjacobs is offline
 
Join Date: Sep 2014
Location: Kelowna
Posts: 631
Quote:
Originally Posted by rupej View Post
This is a great idea, but I started using another method that which elimates the need for two of each PB tag, and takes a bit less coding- I'm sharing because I thought others may be interested:

I simply parallel all PB bits into a timer, and if the timer runs for two seconds, unlatch each PB. This allows them to "stick" but only for two seconds. The rung is simplified further if you use a single DINT that holds all of the PB bits.

IF PB_DINT > 0 for two seconds, CLR PB_DINT
That works well, too.

Just watch out if you have more than one HMI.
HMI #1 could cause a button clear (unstick) for HMI #2 just as they press their button.
That chance increases with more HMIs, and how often those buttons are pressed.
  Reply With Quote
Old March 12th, 2018, 10:10 PM   #11
rupej
Member
United States

rupej is offline
 
Join Date: Sep 2014
Location: NC
Posts: 429
I may be misunderstanding, but I don't see how my method makes that any more likely. The PB bit is only cleared if it is held for 2 seconds (or whatever time is programmed). The HMI clears the bit any time someone releases it, which would also happen if someone else was using a 2nd HMI somewhere.
  Reply With Quote
Old March 13th, 2018, 12:55 PM   #12
arlenjacobs
Lifetime Supporting Member
Canada

arlenjacobs is offline
 
Join Date: Sep 2014
Location: Kelowna
Posts: 631
Quote:
Originally Posted by rupej View Post
I may be misunderstanding, but I don't see how my method makes that any more likely. The PB bit is only cleared if it is held for 2 seconds (or whatever time is programmed). The HMI clears the bit any time someone releases it, which would also happen if someone else was using a 2nd HMI somewhere.
Rupej your idea is clean, efficient and is easy when you have a lot of push buttons to manage. It can work well in a project, but I've come across a few that didn't.

It matters what you are doing with the input PB bit (trigger or hold an action), and where that is in your ladder code (before or after the clear, in the scan).


Scenario A:
PB #1 is pressed, then just before two seconds is up PB #2 is pressed.
PB #2 will be immediately cleared, being held high for a very short period of time.

That has a few outcomes:
1) Any ladder code for PB #2 after the PB clear will not run. Obvious yes, but when there are more than 1 PLC programmers you can't control everything.
So, I assume that this issue won't occur because it's easy to find in a code review.

2) There is no feedback to the HMI that the PB press was valid. The HMI uses the PB tag as a feedback. With a short time of PB #2 being held high there is no feedback that the PB press was valid.


3) The parallel PB input can work for push buttons that trigger an action in the PLC. But it cannot work for push buttons that hold an action.
Both cases are a Momentary PB in the HMI (set 1 on press, clear 0 on release).
It's the hold action of an HMI momentary PB that would cause a problem; with multiple HMIs.
PB #1 would cause the hold action of PB#2 to be very short.


Scenario #2
4) If PB #1 is pressed for 1 second, then before that is released you have PB #2 pressed for 1 second. The timer would never stop and ends up clearing all PB bits 1 second into the PB #2 press. That is an issue for push buttons with a hold action.


You could increase the timer to 5 or 10 seconds, and reduce the chance of problems. That can work for a lot of projects, as long as you are mindful of the issues.
  Reply With Quote
Old March 15th, 2018, 08:57 AM   #13
rupej
Member
United States

rupej is offline
 
Join Date: Sep 2014
Location: NC
Posts: 429
Quote:
Originally Posted by arlenjacobs View Post
Rupej your idea is clean, efficient and is easy when you have a lot of push buttons to manage. It can work well in a project, but I've come across a few that didn't.

It matters what you are doing with the input PB bit (trigger or hold an action), and where that is in your ladder code (before or after the clear, in the scan).


Scenario A:
PB #1 is pressed, then just before two seconds is up PB #2 is pressed.
PB #2 will be immediately cleared, being held high for a very short period of time.

That has a few outcomes:
1) Any ladder code for PB #2 after the PB clear will not run. Obvious yes, but when there are more than 1 PLC programmers you can't control everything.
So, I assume that this issue won't occur because it's easy to find in a code review.

2) There is no feedback to the HMI that the PB press was valid. The HMI uses the PB tag as a feedback. With a short time of PB #2 being held high there is no feedback that the PB press was valid.


3) The parallel PB input can work for push buttons that trigger an action in the PLC. But it cannot work for push buttons that hold an action.
Both cases are a Momentary PB in the HMI (set 1 on press, clear 0 on release).
It's the hold action of an HMI momentary PB that would cause a problem; with multiple HMIs.
PB #1 would cause the hold action of PB#2 to be very short.


Scenario #2
4) If PB #1 is pressed for 1 second, then before that is released you have PB #2 pressed for 1 second. The timer would never stop and ends up clearing all PB bits 1 second into the PB #2 press. That is an issue for push buttons with a hold action.


You could increase the timer to 5 or 10 seconds, and reduce the chance of problems. That can work for a lot of projects, as long as you are mindful of the issues.
Thanks for taking the time to respond, that's interesting to think about. So yeah this certainly doesn't work for buttons that need to be held, like jog buttons. But thinking about it, the classic catch and release doesn't work for jogs either . How do y'all deal with that situation?

Just a side note, at least for PanelViews, I don't think scenario #2 would happen. When PB#1 is released, the bit would clear. And it wouldn't go high again unless PB#2 released and pressed a second time.
  Reply With Quote
Old March 15th, 2018, 12:37 PM   #14
arlenjacobs
Lifetime Supporting Member
Canada

arlenjacobs is offline
 
Join Date: Sep 2014
Location: Kelowna
Posts: 631
Quote:
Originally Posted by rupej View Post
Thanks for taking the time to respond, that's interesting to think about. So yeah this certainly doesn't work for buttons that need to be held, like jog buttons. But thinking about it, the classic catch and release doesn't work for jogs either . How do y'all deal with that situation?
That is a good question; PLC code to handle HMI jog push buttons.
I'm guessing most don't use any code. Just let the HMI handle it.


Quote:
Originally Posted by rupej View Post
Just a side note, at least for PanelViews, I don't think scenario #2 would happen. When PB#1 is released, the bit would clear. And it wouldn't go high again unless PB#2 released and pressed a second time.
Maybe. You'd have to try it.
If all the PB inputs are in parallel, then overlapping PB presses (of 1 second) would run out the timer.
Post up your ladder for the PB timer. It'd be a lot easier when we could see it.
  Reply With Quote
Old March 7th, 2018, 06:29 PM   #15
nhatsen
Member
Venezuela

nhatsen is offline
 
Join Date: Oct 2010
Location: Argentina
Posts: 674
Quote:
Originally Posted by DonBlack View Post
I agree with A_G's method
Me too:

a) The momentary button (using the default hold time) writes on Start_Tag in the PLC.
b) Start_Tag enables a timer. The preset of the timer will be 2 seconds.
c) Timer's DONE bit activates whatever-needed-function. I'd add the method explained by ASF (resets the Start_Tag).

About the Hold Time feature, the button doesn't return to its original condition until that time is reached. For example, if you set Hold time = 5 secs and press the button for a second, the button will be keep in the pressed state for 5 seconds. That's the reason why I leave the default value (250 ms).
__________________
"If you can't solve a problem, then there is an easier problem you can solve: find it." (George Pólya)
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
HMI Button Question (Safety) pmolive LIVE PLC Questions And Answers 2 January 29th, 2015 09:41 AM
PanelView Plus 600 McBacon LIVE PLC Questions And Answers 8 June 24th, 2013 04:23 AM
Panelview Plus 6 slow button repeat press Paul351W LIVE PLC Questions And Answers 12 December 7th, 2012 10:01 AM
press and hold sweetjohnny LIVE PLC Questions And Answers 20 August 7th, 2012 06:49 AM
Inrcrement/Decrement Button vba (Factory Talk) djpalaz LIVE PLC Questions And Answers 10 January 31st, 2008 05:01 PM


All times are GMT -5. The time now is 06:56 PM.


.