They're getting paid, aren't they? Write your interface requirements into your purchasing specifications. 
3 Likes
This is the way I had always heard it as well, so naturally, I misinterpreted what was actually being said the first time I read a topic in this forum about momentary push buttons. A book I read quite some time ago called Domain Driven Design put a lot of emphasis on the importance of getting everybody's nomenclature on the same page during early development meetings, and things like this are the reason; there's a big difference between a momentary pulse and a sustained signal.
1 Like
I would call this a one shot button.
HMI momentary buttons are intended to replicate mechanical PB’s with a NO contact. Depressed closes the contact, releasing opens it. Even those can stick on. Any programmer who is not handling that possibility in the PLC is IMO committing malpractice.
3 Likes
Getting a tcp connection will not solve all issues for this... Websockets could get you a stable(enough) connection for ping pong isalive stuff.. but its the mouse down itself that can not reliably be tracked in browsers.
You can loose focus of the browser app that it can never know. Which than would think you are still pressing the button and have a connection...
Unless you force the user to hold the mouse button down AND move it around in circles within the button... But good luck with that on touchscreens
But the only reason you would really need this is for some crucial plc control, which you do not want to just be accessable on the whole network... So a real physcal button seems safer
8 Likes
Hey Victor, playing devil's advocate here, a colleague returned me to this by asking questions so I went to prove that it's not reliable. I added both mouseUp and mouseLeave events to stop the jog action, and I couldn't get it to fail. I tried:
- clicking and holding the button, then moving the mouse off the button and releasing stopped the jog action as soon as the mouse left
- clicking and holding and then alt+tabbing to swap to another application (which was covering the browser and button) stopped the jog action
Can I get it to fail somehow else? I could disconnect the client, but anything else?
One of the easiest methodes to test the bad concept is: press button and unplug mouse while still holding down.
Your button will stay "pressed", as the mouse hasnt left, and never fired mouse up.
You can even now stop pressing and reconnect the mouse and the button will still never have fired mouse up.
This can happen for other reasons too that are a bit harder to test but can and will happen, low battery if wireless mouse (
), just missing the mouse event cuz of a bad wifi connection or high traffic, internet loss, browser stop working...
i dont even want to list more cuz just one of these reasons is enough to not trust it.
Do not let the safety of operators hinge on programmed stuff send through the internet.
Use physical buttons (that can easily be maintained) for these things. And have emergency butons too that get reguraly checked and tested.
Do no try to reduce cost for a physical button for such important things
9 Likes
I think disconnecting the client would be reason enough to not use momentary PBs, and especially to not use Jog functions. A client disconnect could be due to many things:
Client crashes
Server crashes
Network topology crashes
Windows crashes
Driver crashes
Packet loss
.... the list goes on.
Full stop, don't use momentary or press and hold functions from an HMI. If theres not an ISA standard against them, there should be.
3 Likes
Yes, and no, client disconnect can be detected by perspective. (Edit: Hm actualy might not not even always be the cause).
But many other issues can never be detected, which is the biggest problem. you have no full control of the computer, only partial acces to the browser screen, which just doesnt know a lot about the state of the compturer, let allone the connection to send the data to the gateway
I'm a vision user, so I get tunnel vision in these discussions. Im assuming in Vision, the client mouse events and tag notification to the gateway are detected on the local box.
I am currious if even vision can detect a mouse disconnect (out of the box)...
Still asumming anything is bad and the reason you should a physical button where there are no questions. Even for vision. (note i dont use vision)
These kinda button are to be used for security reasons, you do not want any chances of it failing. or more like, when it fails it trigger the stop.
I would not make that assumption. This isn't just a problem for perspective, it is a problem for every SCADA/HMI software I have ever used.
Read through this:
2 Likes
Yes. But out of the box, the Vision momentary button is still vulnerable to missed button releases.
My alternate CipIOButton uses repeated "still pressed" messages that are tracked on the gateway to catch various client-side failure modes.
Hmmm. I'll have to test this.
Indeed. I consider my alternate button good enough when aiming to protect a machine from itself.
No HMI button is ever good enough to protect a person from a machine.
8 Likes
This cannot be repeated enough.
7 Likes
100% agree.
Well of course...I'm arguing that position. I wasn't saying that vision had an exception. I was saying Vision was even MORE susceptible due to its client/server nature.
No difference in double-hop communication in Vision versus Perspective. "Perspective browser <=> Gateway <=> PLC" versus "Vision Client <=> Gateway <=> PLC". And both Perspective and Vision talk to the gateway with web technology.
Vision has one crucial advantage: it can run arbitrary code on the local client, enabling the use of robust messaging to catch most of the pitfalls between client and gateway. And with forethought, end-to-end to the PLC. Browsers do not let Perspective run arbitrary code, and Perspective offers no rubust means to have the browser run arbitrary code.
To my knowledge, no one, anywhere (not just Ignition), has made a reliable momentary button for a web application.
I guess i dont understand your distinction that vision has an advantage, as no matter what the vision client can do with scripting and fancy monitoring, if it loses communication to gateway, the tag isnt going to be updated as a result of whats happening on the vision client.
The question becomes, if a button is held on, and the client loses gateway comms, does the gateway sense that last user loss and turn the tag off? I suspect not. So i dont see any advantage of vision client scripting ability
Phil said it can catch most of the pitfalls, not all. It’s not good enough, but it is “better” than perspective.
This module works for my applications. It doesn't resolve some of the issues, but everything I'm using it for can have a 30 second timeout in the PLC.
Out of the box, no. But there are examples on this forum where Vision runs an algorithm that sends repeated "still pressed" messages to the gateway, and the gateway notices and clears the signal when those message stop. Carefully arranged to run on the Vision GUI thread, this catches all gateway/client comms breakages and catches all frozen GUI cases. (And is implemented in my CipIOButton custom component.)
Perspective cannot run such a client-local algorithm in a dependable fashion.
Note that actual PLC remote I/O technologies are all based on quickly-repeating messaging containing the equivalent of "still pressed" data streams, where the PLC firmware monitors it and faults when messages fail to continue. Mimic'ing that messaging is the only way to make HMI momentary buttons behave like real momentary buttons.
1 Like