Multiple "identical" HMIs

I want to create a single HMI application that will be deployed on five different HMIs all attached to the same PLC. While it is easy do this and have all screens act the same (popup screens would show up simultaneously on all screens), that's not the behavior I want. Instead, I would like to find a way to have each HMI act independently so that a people can work with different HMIs at the same time without overlap.

I'm planning to use Red Lion Graphite terminals and am looking for some settings I can work with to accomplish this. The way I would hope it works is to download a common program into all terminals and then individually configure each HMI to give it a recognizable identity. Obviously there will need to be some support programming in the PLC, but that's not a concern at this point. I really don't want to have to keep up with 5 separate, but seemingly identical, HMI applications.

Any ideas?

The only thing that would be the same unit to unit would be when an alarm pops up but people would be able to control different tags.

If I am user 1 and turn on pump 1 it will show as active on the other HMI units but anyone can turn it back off as long as you are not using latched buttons you should not have any issue and I would not use latched buttons even with a single HMI.

Anyone can turn on pump 2 and so on. if you are drivng screen control from the PLC and you want different areas to have a different reaction you will need a screen control word for each unit.

Steve Etter said:

I want to create a single HMI application that will be deployed on five different HMIs all attached to the same PLC. While it is easy do this and have all screens act the same (popup screens would show up simultaneously on all screens), that's not the behavior I want. Instead, I would like to find a way to have each HMI act independently so that a people can work with different HMIs at the same time without overlap.

I'm planning to use Red Lion Graphite terminals and am looking for some settings I can work with to accomplish this. The way I would hope it works is to download a common program into all terminals and then individually configure each HMI to give it a recognizable identity. Obviously there will need to be some support programming in the PLC, but that's not a concern at this point. I really don't want to have to keep up with 5 separate, but seemingly identical, HMI applications.

Any ideas?

Click to expand...

The configurations should be the same, the only difference would be the IP Address of each unit. You wouldn't have popups showing up on any other unit than the one that is in use. The screens wouldn't change, again, except on the unit being used.

This is easy, not sure what your concerns are.

Back in my integrator days, one of our guys did this where one HMI project loaded onto five PanelView Plus stations. If I'm not mistaken, he either looked up the IP address or an ID file on each station in order to distinguish one station from the other.

In his application, only certain stations could pull up certain screens, enable certain pushbuttons, etc. Not sure if or how you could do this with a Red Lion.

Have you tried adjusting the Ethernet Speed / Duplex setting in the ENI/ENIW Utility? I think it's on the lower left portion of the tab where IP address is configured. I vaguely remember having to adjust it to 10Mbps for a particular ENI in order to get it to work. It defaults to Auto Negotiate

I did a Crimson 3.0 application with a similar purpose. All the HMIs were on different machines, but also acted as Ethernet bridge to a controls LAN. Crimson allows you to dynamically change the IP address of the HMI, but then you have to "CommitAndReset()" it.

So in my application, the operator (or maintenance tech who installed the HMI) would automatically be directed to a configuration page where he was required to choose a machine name (from a list in my case). The script in the HMI would then set the IP address based on that machine name, execute the CommitAndReset() command, and 7 seconds later, was running in control of the machine.

The text for the machine name and the IP address tags are marked retentive so this only has to happen once. When the HMI was programmed and put on the shelf for unknown use, the IP address was set to a reserved value and name set to some string that I used in the startup program to determine whether or not to force the config. page.

IIRC, I used an internal integer tag for the machine name (formatted as Multi-State with predetermined names corresponding to numbers 1 through 14) and that integer value as the index of an array tag for the IP address. Off the top of my head, I don't remember the function for actually assigning the IP address, but there is a format type so you can view and enter it as a IP address as well as a TextToAddr() function to turn a string into a 32 bit integer representing an IPv4 IP address.

I do this in PanelView Plus using the IP address to set an internal tag for that unique station. Then use that tag to control what pops up and what the operator is allowed to control vs just monitor. I also use it in the alarming as a condition of what to monitor, that way that station only gets alarms for that area.

hope you find a way to do that in a Red Lion. It's really nice to have just one app to maintain.

JHarbin said:

The configurations should be the same, the only difference would be the IP Address of each unit. You wouldn't have popups showing up on any other unit than the one that is in use. The screens wouldn't change, again, except on the unit being used.

This is easy, not sure what your concerns are.

Click to expand...

The way I do my programming , I sometimes have the PLC call up a different screen based on user input. In that case, I want only the screen making the call to display the new page, not all of them.

If you want the PLC to control the page being displayed, you will have to build that feature into your Crimson application, but there is no reason it can't be independent for each of your HMI installations.

If the HMI is initiating the data which triggers the logic that the PLC would use to then turn around and call a different page, I would lean toward doing all this logic in the HMI. If you want the PLC ... all by itself ... to be able to change the page of a particular HMI, that could be done too, but would take a little planning to work out how the HMIs all run one app but have a way to differentiate page change commands to which they each respond.

OkiePC said:

If you want the PLC to control the page being displayed, you will have to build that feature into your Crimson application, but there is no reason it can't be independent for each of your HMI installations.

If the HMI is initiating the data which triggers the logic that the PLC would use to then turn around and call a different page, I would lean toward doing all this logic in the HMI. If you want the PLC ... all by itself ... to be able to change the page of a particular HMI, that could be done too, but would take a little planning to work out how the HMIs all run one app but have a way to differentiate page change commands to which they each respond.

Click to expand...

Of course this could be done in a combination of PLC/HMI programming, but I agree with you that the best/easiest way to do this is all in the HMI.

Steve Etter said:

The way I do my programming , I sometimes have the PLC call up a different screen based on user input. In that case, I want only the screen making the call to display the new page, not all of them.

Click to expand...

No offense, but that sounds like an off the wall way to do things.

No offense taken. It may truly be a little off-the-wall, but I haven't been accused of being normal much anyway.

After reading the comments here, I think I will focus away from my previous methods and work to make the HMI programs act independently of the PLC. I think it will be easier in the long run.

There are many things you can do with Crimson that are clean and reliable that are unthinkable with other HMIs. Stuff you used to always have to code in PLC logic like alarm delays and complicated actions triggered by one HMI button are quite easy to do with Red Lion gear.

Just load the same project (with different IP settings) on each HMI? I've done this with redundant Panelviews on a single CompactLogix processor (terminals were on opposite ends of a very long, narrow room, so the manager could control the line from both sides). I just loaded the same project .mer file on each Panelview and it was done. If we're dealing with ethernet the HMI doesn't lock the processor out from any other HMI.

An application like this depending on size is something I'd deploy a FactoryTalk View SE Server for. Only one project runs on the server, but you can deploy PCs (or industrial PCs with touchscreens if you want it to act like an HMI) to run as clients. That way it's just one project file to maintain. If you have to make any changes, all you need to do is change it on the server and all the clients will automatically update once the new screen is loaded. You can also do things like have security levels where only certain terminals have access to certain areas.

It's of course quite expensive to go with a full-on networked SCADA, but it saves a ton of hassle if you're doing something big enough.