Jog Button on Touchscreen HMI in Perspective

[Carly_Jankowski]

Hi everyone,

I have a jog button on a touch screen HMI that is hosting my perspective session. The goal is that when I hold the button down, the machine will jog until I release the button. With the help of a past forum post I was able to get it working while using a mouse. The logic is as follows:

onMouseDown:

def runAction(self,event):
	self.custom.clickReleased = False

	def confirm_if_click_held():
		from time import sleep 
		sleep(0.5)
		if not self.custom.clickReleased:	
			self.custom.tag=True
	system.util.invokeAsynchronous(confirm_if_click_held)

onMouseLeave AND onMouseUp:

def runAction(self,event):
	self.custom.clickReleased = True
	self.custom.tag = False

However, I need this to apply when using only the touchscreen, as there won't be a mouse in the field. With the logic as is, using the touchscreen when I press the button down, nothing happens until I release it, and then the machine begins to move. It isn't until I press somewhere else on the screen to act as the 'mouse release,' that the movement stops. I have tried putting this logic on other mouse events, on the component event 'onActionPerformed', and even on a text label in case the physical pressing was throwing it off. Please let me know if there is a work around to this issue or if it is even possible to achieve this goal. Thank you!

[Transistor]

Jogging and momentary buttons in general on web based HMI are consider a bad thing. Related:

Click and Hold button in Perspective

There’s no good answer at this time. What you are looking for is a Momentary button, like real buttons typically used for “jog” type operations. Perspective doesn’t have one, largely because there’s currently no good way to ensure the “button” is released reliably. Particular in the case of broken comms.

PF755 and PF525 Jog Button

There will be grief in your life. Perspective doesn't have an out-of-the-box momentary button. You can approximate one with MouseEvents, but you will always be vulnerable to missed events, leaving the button "pressed". Vision does have a Momentary pushbutton, but it too is vulnerable to missed events. There are ways to make the Vision button fairly robust, fortunately, if a bit complicated. This forum search will get you started: https://forum.inductiveautomation.com/search?q=momentary%20c…

PF755 and PF525 Jog Button

There will be grief in your life. Perspective doesn't have an out-of-the-box momentary button. You can approximate one with MouseEvents, but you will always be vulnerable to missed events, leaving the button "pressed". Vision does have a Momentary pushbutton, but it too is vulnerable to missed events. There are ways to make the Vision button fairly robust, fortunately, if a bit complicated. This forum search will get you started: https://forum.inductiveautomation.com/search?q=momentary%20c…

[ryan.white]

To add to Transistor's post

How to create the momentary Button in Perspective

Because, with currently available components, there is no way to ensure the PLC gets its bit released (in a reasonably short bounded time, typically ~100ms) if: The browser hard crashes while the button is pressed, The browser encounters a javascript bug or sandbox violation while the button is pressed, Some other javascript operation hogs the CPU(s) (charts for the win!), delaying recognition of the mouse release, The websocket gets cut off between browser and gateway (for any reaso…

[pturmel]

@Carly_Jankowski

a jog button on a touch screen HMI that is hosting my perspective session

As noted, the answer is to not have a jog button. Or not use Perspective.

[Carly_Jankowski]

In the case of this being a non-safety issue, the application currently is super small scale and not doing anything crazy. We do plan on implementing the continuous stream of timestamps so the PLC would catch it. Right now, it just seems like the button extension functions do not work correctly with a touch screen. I do not see anything in the HMI settings regarding 'clicking' either.

[michael.flagler]

My guess is that the touchscreen is registering long presses as right clicks. You might have to check your touchscreen driver settings to see how it's set to react to long presses. I typically just use start/stop buttons instead of buttons that need held (unless I'm using physical buttons on a panel, in which case I will allow jogging by holding a button).

[Carly_Jankowski]

This makes sense, previously when holding down on the button it would highlight the text and give copy/paste/etc options, until I disabled this using a stylesheet.css function. In this case then, I do not see a onRightClick or similar option under mouse events, does anyone know if there is some action to capture a right click?

Also to preface, the OS of the HMI is Linux. I checked the configuration settings and did not see any settings related to this issue.

[pturmel]

@Carly_Jankowski

We do plan on implementing the continuous stream of timestamps so the PLC would catch it.

You cannot do that in Perspective without writing a custom java module that implements a new Perspective button type. Because any other solution uses scripts that run in the gateway, not in the browser. If it was easy, or even just moderately difficult, it would have been done by now.

@Carly_Jankowski

this being a non-safety issue

Some future developer will copy your questionable code and use it for something more significant. I strong recommend you not do this.

Relevant recent topic:

How to implement "Momentary Button" function in Perspective View

The technique uses a fast timer tightly bound to the button in the UI to check and send "I'm still pressed" messages through the full comms path, with a PLC timeout catching any hiccups to release the button. Also requires some metadata to prevent re-activation if a UI script stalls and resumes. Perspective cannot do this because its scripts run in the gateway, not in the UI. It might be possible to do with javascript in a custom Perspective component, but I haven't figured out how, and nobo…

[bkarabinchak.psi]

If I tried to do

def runAction(self,event):
	self.custom.clickReleased = False

	def confirm_if_click_held():
		from time import sleep 
		sleep(0.5)
		if not self.custom.clickReleased:	
			system.tag.writeBlocking(['lastConfirmedRunRequest', system.date.addSeconds(system.date.now(),1)]
	system.util.invokeAsynchronous(confirm_if_click_held)

and comms broke, what would happen, that script would keep running until comms resumed and detected the click was off?

[lrose]

@bkarabinchak.psi

and comms broke

But where did comms break?

[Brian_Stilson]

Jog buttons on ANY touch screen, in my opinion, are a very bad idea, for several reasons. Jogs, cycle starts, resets, or any other button that will be used frequently should always be a physical button.

Unlike a physical button, smooth, flat screens have no physical feedback for where your finger is. If your eyes aren’t on the screen, you have no idea where your finger is if you aren’t directly touching the button. With physical buttons, you have all kinds of physical feedback that will tell you that your finger is still on the button and whether you are pressing it or not. With a touchscreen, you have no idea. Even if your finger is touching the screen, it may or may not be with enough force to actually register as a touch. And sometimes, your finger can actually register a touch without it actually touching. So there is absolutely no way for your body to know whether you are pressing the screen hard enough unless you are physically looking at the screen and seeing visual feedback (that was hopefully programmed in) indicating as such. Additionally, it is extremely difficult for most people to keep their finger in the exact same position over the exact same area of the screen when they have to release the button. It can get very bad in jogging operations when lots of presses and releases happen in succession. It is very easy for hands to drift off the button, onto a blank area of the screen, or even onto another button that you don’t intend to press.

That really matters because you really should always know what button you’re about to press before you cause motion. A lot of those kinds of operations are fine when executed from the touch screen because you’re looking at the screen anyway. But with jogging operations, you really shouldn’t be looking at the screen. You should be looking at the thing you are moving.

So, putting a jogging operation on a touchscreen gives us a potentially dangerous Catch-22. You can’t/shouldn’t look at the HMI screen when you’re moving something manually, but if you don’t, it is very easy to lose your place on the screen, and in a worst case scenario, initiate a motion you didn’t intend to initiate.

Additionally, most touch panels are not designed for repeated high-force presses in the same location day in and day out. Operators can be rough on their panels. I have literally seen spiderwebbed screens from frustrated operators forgetting that pushing harder doesn’t “make thing work gooder.” I have seen HMIs develop “dead spots” within a few years of operation because of a frequently-pressed reset button in that location. One operator will press a little too hard too many times and that area will be slightly damaged, and lighter touches stop registering. So the operators start touching it with more force, which damages the panel more, which causes the operators to press even harder, which causes more damage, etc. etc. Frequently-used buttons on a touch panel can absolutely kill the service life of the terminal. Don’t do it.

These reasons are why I never put cycle starts (unless the cycle is only being started one or a few times a day), resets, jog buttons, or any frequently-used button on the HMI in my system designs. Buttons that need to be pressed a lot should be physical buttons. They are very easy for any operator to be able to operate reliably and consistently without having to look at it, and they are rated for that level of wear and tear. Touch panels are, in my opinion, rarely safe for manual motion operations and not nearly rugged enough to withstand the forces that physical push buttons and switches in an industrial environment are rated and designed for.