What are FactoryTalk SE View HMI Sticky Buttons?

In the industry, there are many different causes to why we have HMI issues with buttons that we make for operator screens and often the easiest methods are overlooked or in other cases may not have been thought of.

In my own experience throughout working with different HMI software, I have found a very helpful technique that is an easy pick up to add to your front end programming of your HMI interface application either using FactoryTalk View ME or what I prefer to use, FactoryTalk View Site Edition network distributed.

An HMI sticky button that does not transition the tag or bit from a 1 to a 0 or vice versa, this can cause machine upsets or just take away the control of the machine from the operator.

Before I get into a good best practice of how I program an HMI button to avoid an HMI sticky button, let’s talk about some of the key reasons why an HMI system would have issues with a push-button not working correctly.

Here is a shortlist of common issues:

• Network lags, meaning not set up to a solid communication platform… For example, if Ethernet then devices should be a speed of 100/Full.
• Improper RSLinx enterprise setup or save
• Using a tag database or direct tagging
• Improper HMI button setup
• Driver issues with the HMI display
• Computer operating system

This is just to name a few and not a written in stone direct cause but is some of the most common issues related to an HMI application push button not working correctly. As some of these issues will definitely cause a lot more than just an HMI sticky button then the one that tends to stand out is the improper setup of an HMI button.

---

 

 

HMI Button Properties Used – Set tag to 1 on press and to 0 on release

Let me take a minute to describe an issue that I had a few years back but is still very much an issue today if you choose to program your button this way.

When I set up my button, I entered in the direct tag that I wanted to turn on and have it turn off when it was not pressed so I first programmed it like so, using the action as a set to 1 when press and to 0 on release with the tag of {[PrcessObjix]P3_DosingSeq.OCmd_Start} as the tag that was used for this example.

 

---

 

 

HMI Button Properties Used – Run Command with Press and Release

After programming the button, as shown above, it did work however there were times when the button would get held in the on or off state and someone would have to go into the PLC program to set the bit back to its correct state so I then started at looking towards the root cause of the issues which in my case was not so obvious because we did not have a communication lag or an RSLinx enterprise issue.

I did research this through Rockwell’s knowledge base website and found an article talking about setting up the HMI button slightly different so I then tried this technique which is shown below in figure #2.

In figure #2 example:

I used the Action as a Run Command with the press action as

&Set {[PrcessObjix]P3_DosingSeq.OCmd_Start} 1

and the Release Action as a

&Set {[PrcessObjix]P3_DosingSeq.OCmd_Start} 0

 

 

---

 

 

HMI Button Properties – Run Command with just a press action

From what the knowledge base article told me, this was the exact way to program the button which uses a run command to give the ability to use a press action and a release action. There were a few different articles that they had talking about how to use best practices with programming HMI buttons.

I did the program this button as shown in figure #2 which worked fine but after a while, I learned a much better way to use the run command feature of the HMI button properties which is shown in Figure #3. I was shown this method by a one on my senior Rockwell reps who I have been able to work around to gain some very helpful tricks or the trade.

In figure #3 example:

I used the Action as a Run Command with the press action as

&Set {[PrcessObjix]P3_DosingSeq.OCmd_Start} 1 with a pause of 2 seconds

then an automatic

&Set {[PrcessObjix]P3_DosingSeq.OCmd_Start} 0

to make sure all tasks were done within one operator interface.

From the time I learned this method, I have not had any issue with an HMI sticky button or in other words and button that was getting stuck in a 0 or in a 1 state which could not be influenced by the HMI client application.

I have shown the exact way that I went through the steps above or the progression of my findings but I did make a video on this topic using Rockwell’s process library 3.5 to aid in giving a better understanding of what the process is that I use to make sure I do not have this issue in future projects and such or even fixing older applications.

Sometimes going back to view older applications gives you an experience of what used to be the best practice or maybe just another perspective on how to do something.

 

---

 

 

FactoryTalk SE – How to Avoid an HMI sticky button for an HMI system

To describe a little about the video, it shows exactly how to trace down a tag structure of a global object that is being used in the HMI application to give a viewpoint of what building the tag structure looks like which can greatly aid you in troubleshooting a system or isolating a system down to the exact section.

It also shows how to use that very tag structure in a normal HMI button using the run command in the HMI button properties.

So without further ado:

---

 

After reading the above sections and watching the video that was provided, I hope that this article has helped peak interest in how FactoryTalk SE buttons should be programmed to minimize the risk of any sort of issue related to an HMI application button hanging up.

If by some chance you still have this issue happen and have programmed the button as shown then I would suggest looking into either your communication to the system which could be any of these items but is not limited to.

• Computer network speed (Is your computer’s NIC card set to 100/Full?)
• Ethernet network health (Is your Ethernet switch set to 100/Full?)
• Touch screen drivers (verify the driver is set up and working correctly)
• Optional – if using a Virtual image then verify that the owner of the touch screen is the virtual computer.
• Computer Operating System
• RSlinx setup

So if any of these issues have not fixed or helped resolve an issue with an HMI sticky button then please let me know and I will be happy to assist in getting the issue resolved. Just go to my contact page and send me a message or if you have topics that you would like to see or see more of current topics then send me a message and I will be sure to add some more content on that topic.

Just like giving a value-added article like how to make a start-up macro for an HMI client.

Thank you for your time,

Shane

What are FactoryTalk SE View HMI Sticky Buttons?

In the industry, there are many different causes to why we have HMI issues with buttons that we make for operator screens and often the easiest methods are overlooked or in other cases may not have been thought of.

In my own experience throughout working with different HMI software, I have found a very helpful technique that is an easy pick up to add to your front end programming of your HMI interface application either using FactoryTalk View ME or what I prefer to use, FactoryTalk View Site Edition network distributed.

An HMI sticky button that does not transition the tag or bit from a 1 to a 0 or vice versa, this can cause machine upsets or just take away the control of the machine from the operator.

Before I get into a good best practice of how I program an HMI button to avoid an HMI sticky button, let’s talk about some of the key reasons why an HMI system would have issues with a push-button not working correctly.

Here is a short list of common issues:

• Network lags, meaning not set up to a solid communication platform… For example if Ethernet then devices should be a speed of 100/Full.
• Improper RSLinx enterprise setup or save
• Using a tag database or direct tagging
• Improper HMI button setup
• Driver issues with the HMI display
• Computer operating system

This is just to name a few and not a written in stone direct cause but is some of the most common issues related to an HMI application push button not working correctly.

As some of these issues will definitely cause a lot more than just an HMI sticky button then the one that tends to stand out is the improper setup of an HMI button.

---

 

 

HMI Button Properties Used – Set tag to 1 on press and to 0 on release

Let me take a minute to describe an issue that I had a few years back but is still very much an issue today if you choose to program your button this way.

When I set up my button, I entered in the direct tag that I wanted to turn on and have it turn off when it was not pressed so I first programmed it like so, using the action as a set to 1 when press and to 0 on release with the tag of

{[PrcessObjix]P3_DosingSeq.OCmd_Start} as the tag that was used for this example.

 

---

 

 

HMI Button Properties Used – Run Command with Press and Release

After programming the button, as shown above, it did work however there were times when the button would get held in the on or off state and someone would have to go into the PLC program to set the bit back to its correct state so I then started at looking towards the root cause of the issues which in my case was not so obvious because we did not have a communication lag or an RSLinx enterprise issue.

I did research this through Rockwell’s knowledge base website and found an article talking about setting up the HMI button slightly different so I then tried this technique which is shown below in figure #2.

In figure #2 example:

I used the Action as a Run Command with the press action as

&Set {[PrcessObjix]P3_DosingSeq.OCmd_Start} 1

and the Release Action as a

&Set {[PrcessObjix]P3_DosingSeq.OCmd_Start} 0

 

---

 

 

HMI Button Properties – Run Command with just a press action

From what the knowledge base article told me, this was the exact way to program the button which uses a run command to give the ability to use a press action and a release action. There were a few different articles that they had talking about how to use best practices with programming HMI buttons.

I did the program this button as shown in figure #2 which worked fine but after a while, I learned a much better way to use the run command feature of the HMI button properties which is shown in Figure #3.

I was shown this method by a one on my senior Rockwell reps who I have been able to work around to gain some very helpful tricks or the trade.

In figure #3 example:

I used the Action as a Run Command with the press action as

&Set {[PrcessObjix]P3_DosingSeq.OCmd_Start} 1 with a pause of 2 seconds

then an automatic

&Set {[PrcessObjix]P3_DosingSeq.OCmd_Start} 0

to make sure all task were done within one operator interface.

From the time I learned this method, I have not had any issue with an HMI sticky button or in other words, and button that was getting stuck in a 0 or in a 1 state which could not be influenced by the HMI client application.

I have shown the exact way that I went through the steps above or the progression of my findings but I did make a video on this topic using Rockwell’s process library 3.5 to aid in giving a better understanding of what the process is that I use to make sure I do not have this issue in future projects and such or even fixing older applications.

Sometimes going back to view older applications gives you an experience of what used to be the best practice or maybe just another perspective on how to do something.

 

---

 

 

FactoryTalk SE – How to Avoid an HMI sticky button for an HMI system

To describe a little about the video, it shows exactly how to trace down a tag structure of a global object that is being used in the HMI application to give a viewpoint of what building the tag structure looks like which can greatly aid you in troubleshooting a system or isolating a system down to the exact section.

It also shows how to use that very tag structure in a normal HMI button using the run command in the HMI button properties.

So without further ado:

---

 

After reading the above sections and watching the video that was provided, I hope that this article has helped peak interest in how FactoryTalk SE buttons should be programmed to minimize the risk of any sort of issue related to an HMI application button hanging up.

If by some chance you still have this issue happen and have programmed the button as shown then I would suggest looking into either your communication to the system which could be any of these items but is not limited to.

• Computer network speed (Is your computer’s NIC card set to 100/Full?)
• Ethernet network health (Is your Ethernet switch set to 100/Full?)
• Touch screen drivers (verify the driver is setup and working correctly)
• Optional – if using a Virtual image then verify that the owner of the touch screen is the virtual computer.
• Computer Operating System
• RSlinx setup

So if any of these issues have not fixed or helped resolve an issue with an HMI sticky button then please let me know and I will be happy to assist in getting the issue resolved.

Just go to my contact page and send me a message or if you have topics that you would like to see or see more of current topics then send me a message and I will be sure to add some more content on that topic.

Just like giving a value-added article like how to make a start-up macro for an HMI client.

Thank you for your time,

Shane