Factory Talk ME Press and hold button

Mteller

Member
Join Date
May 2017
Location
Michigan
Posts
11
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
 
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.
 
Under the General Tab of a momentary push button there is hold time setting. You can select up to 5 seconds.

hold time.jpg
 
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
 
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.
 
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

Keep it simple and full proof - use the rework button to open an on top 'confirm start' display, on that display is the actual button linked to the PLC tag.

2 presses of different buttons in sequence is hardly accidental then.
 
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).
 
The hold setting on a ftvme momentary pb holds the bit true for the set time. So if hold is set for 2 seconds and you just tap the button, the bit still stays true for 2 seconds.

I have also used a small on top display like janner suggested.
example:
Use a goto display button labeled 'start' that opens a small on top display.
On the display write 'Are you sure you want to start?'.
Use one close display button labeled cancel.
Use another close display button labeled 'Yes' with 'write value on close' checked, with a value of 1, tied to a tag like 'hmi_start_confirmed'.
Use this bit as one of your conditions to start your machine, be sure to unlatch it after started.

There are a lot of different ways to do this stuff and everyone has their on ways and reasons. You will get comfortable and develop your own ways also.
 
Last edited:
There is no delayed write option in FTView ME. As soon as you touch that button it writes to the tag; just like DonBlack says.

If you are worried about an accidental button press, then a confirm popup is the best way.
You will (should) also use the code that ASF put down; for all the reasons he mentioned.

In FTView ME (or any HMI), the confirm popup can be small and simple. Use parameters on it, and code it just like DonBlack suggested.
Then you can use that confirm popup for any/all of your machine motion tag writes. The "Close" button will only set the tag to 1. Then the PLC code should read the tag and clear the tag; exactly like the code from ASF.

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.

use the rework button to open an on top 'confirm start' display, on that display is the actual button linked to the PLC tag.

2 presses of different buttons in sequence is hardly accidental then.

I have also used a small on top display like janner suggested.
example:
Use a goto display button labeled 'start' that opens a small on top display.
On the display write 'Are you sure you want to start?'.
Use one close display button labeled cancel.
Use another close display button labeled 'Yes' with 'write value on close' checked, with a value of 1, tied to a tag like 'hmi_start_confirmed'.
Use this bit as one of your conditions to start your machine, be sure to unlatch it after started.
 
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.

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.
 
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

A different way to solve this problem is to have a hard-wired, physical push button to confirm any start/stop requests from the HMI.

NFPA 79 section 9.2.5.7.1 and jog function NFPA 79 section 9.2.5.5.2
Talks about using two different controls for machine motion.
One to make the request (ex. HMI button for machine start)
Then a different control to enable the motion (ex. hard-wired momentary PB)

The hard-wired push button could be used for any/all motion requests. But you would need code like what ASF recommended, plus extra code to control the requested function from the HMI.
 
The hold setting on a ftvme momentary pb holds the bit true for the set time. So if hold is set for 2 seconds and you just tap the button, the bit still stays true for 2 seconds.

There is no delayed write option in FTView ME. As soon as you touch that button it writes to the tag; just like DonBlack says.

So it turns out I'm wrong about the operation of the "hold time" function! Don and Arlen have it correct - see attached a screenshot of the help file confirming this.

That being the case, my advice above is of limited value. In this instance, I'd suggest that your safest bet is a popup confirmation as others have suggested. And as I mentioned previously, make sure you have some method of "unsticking" the jog button in the case that the button release message gets lost.

Thanks for the correction!

Screen Shot 2018-03-09 at 9.20.11 am.png
 
That being the case, my advice above is of limited value. In this instance, I'd suggest that your safest bet is a popup confirmation as others have suggested. And as I mentioned previously, make sure you have some method of "unsticking" the jog button in the case that the button release message gets lost.

Both suggestions are good to use.

Use the popup to confirm the button press (because there is no long delay on button press).

Use ASF ladder logic to avoid HMI button issues (because they are not wired I/O)
 
|
| 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
 
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.
 

Similar Topics

Does anyone have any idea why Factory Talk (FT) does not have the option to log Audit messages to an SQL database via ODBC in the FT diagnostic...
Replies
4
Views
6,218
I am trying to enable an external alarm via computer speakers for Factory Talk Network Distributed Edition. I am using Alarm and Events setup. I...
Replies
7
Views
126
We have a quad monitor setup with FT SE and we are utilizing a header screen at the top of every display. when we open a new page we abort the...
Replies
0
Views
77
Good day colleagues, I have a problem with a plc slc 5 since I export the tags to my factory program to load them into a panel view 1000 plus 6...
Replies
0
Views
88
Hi all, Attached below is an example of what is happening to our existing SCADA. It seems after patching some Rockwell Software that I thought...
Replies
9
Views
262
Back
Top Bottom