Ignition HMI as pendant replacement?

Ignition
1

Hi all,

We're looking to use Ignition as a potential replacement to a physical pendant for manual machine control. Has anyone attempted or looked into this? We've got concerns about latency and usability as it would be from a tablet on a WiFi connection. Safety isn't a huge concern, just usability in terms of fine-grain control and latency (e.g. moving a motor a specific distance by holding a button down.) Anyone ever try this or have any feedback as to why this is a good/bad idea? Thanks!

2

Perspective doesn't even have a momentary button. They are sketchy even in Vision, unless you have the right logic in the PLC as well.

2 Likes
3

I would say that these two statements are contradictory.

It is difficult to create a true "momentary" button for "jog" operations.

See here:

Also, do a search for stuck momentary button to learn about the difficulties such a control scheme can present.

1 Like
4

I do this with a few customers.

With Vision, and only with Vision. (No tablets or other devices that use mobile operating systems.)

Yes, this is quite the problem. I created an Ignition module some years ago specifically to support an I/O protocol (EtherNet/IP Class 1 UDP) that offers very low latency. (It can do much more than that, but that was its foundational purpose.)

And this. All of the various solutions involve some kind of code or I/O configuration in the PLC.

{ @lrose already linked the background material. }

2 Likes
5

An option for using Ignition as an HMI that I've done is using some sort of safety 3-way enabling device with hard push buttons on it, then use Ignition to configure what you want the buttons to control, jog speed, etc.

Euchner has some nice options for multiple aux buttons.

2 Likes
6

I know some don't like momentary button, but I am thinking to implement something like this, when it is not possible to change the PLC

  • Create a memory tag with a Timestamp as value;
  • Perspective goal, while a button is pressed, is to update this Timestamp, like every 50ms
  • When the Timestamp is updated and command tag is 0, 1 is written to command tag
  • As long as the command tag is 1, gateway check the Timestamp and set the command tag to 0, if the timestamp is getting older than 100ms or something like that
  • When button release, reset command tag to 0, and timestamp

Not sure of the implementation yet
Would prefer to set the timestamp in the PLC, so the PLC stops on communication loss
And I am still not sure of the hardware reliability to release from any touch screen, so I prefer mouse control

1 Like
7

That's exactly how I was thinking about doing it too! A little heartbeat of sorts.

Thanks so much for all the feedback everyone.

8

It's not possible in this scenario to change the PLC, I presume that includes adding logic to maintain a timestamp.

And what happens when Ignition sees the command tag value as 0, but the PLC sees it as 1 because the write never made it to the controller? Read after write doesn't work because there is a loss of comms and the PLC is still moving the equipment.

There are very good reasons why "some don't like momentary buttons". The long and short of it is, if you can't make modifications to the PLC, and the Client needs this functionality, you should walk away from the job. They're asking for an accident.

I would pass on any request to implement a jog function from Perspective (as it is now) no matter the level of safety concern with the project. I already avoid momentary buttons on HMI's for any hardware interaction even in vision.

9

that is why I would prefer the Timestamp to be in the PLC. The logic to reset the command tag value must be in the PLC also

10

So if I understand correctly, basically only jog the motor as long as the PLC is being sent updated timestamps?

2 Likes
11

yes

3 Likes
12

Not sure how to avoid it is some circumstances. In my case, I work with rollforming machine, that have multiple axis and motors that may need to be controlled independently, and I don't see how I could fit over 60 buttons to jog each of the 30 something axis and motors forward and backward on a single panel

At least, on an HMI, we can organize those button in pages

13

Avoid doesn't mean, absolutely never. It just means look for a better way if possible. If a virtual jog function is required then a proper handshaking schema must be employed to insure that the PLC can detect a loss of comms to the SCADA system and discontinue the motion.

For equipment with multiple axis, I employee a jog select button along with a position increment (if the axis is a motion axis). If a loss of comms occurs then the position stops incrementing and motion stops. A momentary button is not the control mechanism for the jog.

Otherwise, I utilize a rolling count that is sourced from the PLC and written to another tag via the SCADA system. If the two get out of sync then all motion is stopped by the PLC.

The network traffic and latency make this unreliable at best in Perspective. I would not want to put my name and reputation on the line if it failed. Perspective as it stands now, IMHO, is a no go for jog functionality with purely momentary buttons.

14

A good solution is to have one hard-wired jog button and let its function be determined by the HMI. So, your HMI has the axis select radio buttons (which are by definition mutually exclusive) and a forward and reverse radio buttons (also exclusive).

If the additional jog button is too much then toggle normal / jog mode on the HMI and use the hard-wired start button for start / jog depending on selected mode.

3 Likes