Dual HMIs

[ptonsparky]

Customer with a group of motors that they would like to control at two locations. I have never done it so am wondering if I can network 2 HMIs with 1 PLC. If so, what might be some of the things to avoid?

 

[Jraef]

Customer with a group of motors that they would like to control at two locations. I have never done it so am wondering if I can network 2 HMIs with 1 PLC. If so, what might be some of the things to avoid?

Yes, what you need is an HMI system that supports what is called a "Thin Client" application. One HMI is the primary, it communicates (usually via ethernet) to the PLC and to the second "thin client" HMI. The 2nd HMI is showing the exact same OI as the primary and in most of them, you can enable or disable functionality at that 2nd location. An example would be to allow someone to view anything, or stop anything, but not start anything other than at the primary. The Thin Client issue allows the use of a less expensive version of the HMI hardware since it is not running the entire HMI application software.

There are other ways of doing it, many are dependent on what you are using as a network.

 

[StephenSDH]

What Jraef is talking about is a PC based HMI, like Wonderware Intouch or RSView32. These are usually higher dollar and great for more complicated and integrated systems.

There are also simpler panelview products, which are just HMI software usually running on windows CE, like AB Panelview Plus. There are hundreds of manufacturers of CE based HMI products, and some cheaper then AB. For all of them you can just put the same application in both HMIs and point them both at the same PLC. Ethernet is usually preferred for communications.

Good Luck, Steve

AB Panelview Plus:
http://www.ab.com/en/epub/catalogs/12762/2181376/1239781/1670480/1670482/index.html

 

[cadpoint]

I just thought, U could just, Google some images or be a reader... here (Electro)

... :grin: Enjoy

 

[justdavemamm]

Yes, in the past I have had 6 HMI's connected to one plc.

You could use RedLion G3 series. As Steve points out, your plc needs to support multiple connections and Ethernet would be very good. If your plc has only have one serial port, then you'll need a multiplexer device to allow this.

You may want to post your particulars (distance, plc type, # of items to display) over at http://www.plctalk.net/qanda/forumdisplay.php?f=2 for more exposure.

 

[petersonra]

Customer with a group of motors that they would like to control at two locations. I have never done it so am wondering if I can network 2 HMIs with 1 PLC. If so, what might be some of the things to avoid?

most HMI/PLC systems can do this, often just by duplicating the HMI. I do this pretty regularly. it is pretty straightforward.

if your PLC does not have a network capable port, your solution will be much harder. most PLCs these days support some kind of networking though.

if you can post what brand/model of plc you are using, it will be fairly easy to tell you how to accomplish what you want to do.

 

[TxEngr]

As others have said, this is a straightforward application for a PLC. My experience is with Allen Bradley ControlLogix series. You can have as many HMIs as you can afford. Have them operate on 10/100 ethernet and you can even use redundant switches if you want. You can even get Cisco industrial swtiches from A-B. Use the PanelView HMI and program them identical to simplify. This may not be the cheapest solution, but is easy to maintain and keeps spare parts down.

TxEngr

 

[ptonsparky]

Haven't started the project yet. I have to design it and sell it first. That means setting up a working model in my shop first. I use have used AB plcs and HMIs because that is all we have in this area for local support. RS500 and PanelBuilder 32. I also have software for both HMIs & PLC from automation direct. Haven't more than installed the software for those yet.

 

[IMM_Doctor]

Multiple HMI

Multiple HMI

Sure no problem.

My suggestions:

A. Never used maintained pushbuttons on the HMI
B. The use of Momentary pushbuttons on the HMI is prefered, use subsequent logic in the PLC for on/off, or push-on/push off control.
C. The PLC is the MASTER
D. Don't have the seperate HMI's trying to modify the same address (tag)
E. Each HMI should modify a UNIQUE bit address (tag) in the PLC
F. Write the rung in the PLC so that there are branches such as:
HMI1 Start PB
HMI2 Start PB
HMI1 Stop PB
HMI2 Stop PB

 

[StephenSDH]

A. Never used maintained pushbuttons on the HMI

There are purposes for maintained push buttons. You would use one to toggle a configuration bit.

D. Don't have the seperate HMI's trying to modify the same address (tag)
E. Each HMI should modify a UNIQUE bit address (tag) in the PLC

I would never recommend this. You are creating a headache for yourself, when it gives you 0 added benefits.

 

[TxEngr]

The Doc makes several good points.

The reason for not latching the bits in the HMI is that the other HMI can't unlatch the bit since the latch resides in the HMI. Let the logic in the PLC latch bits.

As to using different addresses for each HMI you can argue both points. If you use the same bit address for start/stops, you can use a single program in both HMIs and keep one pre-programmed spare on the shelf. All you have to do is change the IP address prior to install. The advantage of different addresses is it makes troubleshooting much easier. You can see where commands are coming from. You can also control which HMI has control of what points in the system. Reading the same bit addresses is fine however.

It sounds like you're using SLC500 PLCs and Panelview HMI's. A good simple combination although I have a personal preference for the ControlLogix series with Logix5000 software. More expensive but more powerful as well. But for your application the SLC PLC should be fine. Good Luck.

 

[petersonra]

Sure no problem.

My suggestions:

A. Never used maintained pushbuttons on the HMI
B. The use of Momentary pushbuttons on the HMI is prefered, use subsequent logic in the PLC for on/off, or push-on/push off control.
C. The PLC is the MASTER
D. Don't have the seperate HMI's trying to modify the same address (tag)
E. Each HMI should modify a UNIQUE bit address (tag) in the PLC
F. Write the rung in the PLC so that there are branches such as:
HMI1 Start PB
HMI2 Start PB
HMI1 Stop PB
HMI2 Stop PB

I agree with never using maintained PBs in the HMI. It just confuses things.

You should also add a rung of code in your PLC that resets all the PB bits if any stay on for more than some period of time (like 2 seconds). Once in a blue moon you will get a PB bit set and it does not reset, which will cause you grief. It also makes it easier to test because you can just set the bit with your software package and the program will shut it off.

I don't have a problem with reusing the PB bits in multiple HMIs. Do it all the time. It simplifies things to use the same addresses, and if it works on one HMI, you only have to test it once.

I also do not like using NC PBs in the HMI. Just more confusion.

I would also stay away from the more complicated templates in the HMI. Sometimes they do not work quite like you think they should, and it takes time to debug them. Make it as simple as possible. For the simple kind of thing you seem to be talking about, thats almost certainly the best approach.

 

[Jraef]

Just by the way, the reason I recommend using a Thin Client topology is that, if you have separate HMIs running independently all talking to the same PLC, you MUST remember to change ALL of the HMI programs if you change one of them. Otherwise you end up with a mess if someone changes only one. Sure, it's not supposed to happen, but Murphy rules.

In a Thin Client topology, only one HMI is actually running the program, the other is a mirrored image of it. So you can only make changes in one place, and any changes made there show up on any others.

Not a big deal if you trust yourself and everyone else who may someday make contact with the operating program, I just have too much experience troubleshooting nightmares like this. The last one I worked on where there were 3 HMIs talking to one PLC had separate alterations done in each HMI by different technicians trying to tweak the process to solve different problems, not realizing that changes made in one were not showing up in the others. I figured it out relatively quickly by just comparing the programming, but before I got there, the plant technicians messed with that for weeks trying to figure out what was going on.

 

[StephenSDH]

The reason for not latching the bits in the HMI is that the other HMI can't unlatch the bit since the latch resides in the HMI. Let the logic in the PLC latch bits.

A Maintained Push Button does not latch the bit in the HMI. It simply toggles the bit in the plc. The other HMIs will see the state change and be able to toggle the same bit.

Maintained Push Button:
The HMI reads the value from the PLC register and stores it in it's local IO Database every poll interval. When you push the push button it writes a preconfigured value to the plc(1,0,Toggle). It then reupdates the IO Database along with all the other HMI nodes to the new value. All the HMI Nodes see the change of state.

Momentary Push Button:
When a push button is pressed the HMI writes a value to the PLC(usually 1). When the operator releases the push button it then writes the opposite value to the PLC(usually 0). All the HMI nodes see the state changes every poll interval.

A programmer needs to understands the risks involved with both of these buttons. It is a Big Safety No-No to use a Momentary Button with a Jog Function. When the Operator pushes a Momentary button, the HMI will attempt to write a 1 to the PLC. When the operator releases the push button the HMI will attempt to write a 0 to the PLC. If communications is intermittent/lost the 0 will never get written and you will have a machine that is permanently jogging. If a program is saved while a person had their finger on the push button, when it is downloaded next the machine can unexpectedly start jogging. It have to understand the risks. If you are smart you will treat momentary buttons as potentially maintained buttons in your HMI and PLC logic to avoid dangerous scenarios. You are putting yourself and your company at a huge liability if you don't understand controls and modern safety standards.

 

[Strahan]

PV Plus form allen bradley as previously mentioned. Easy to setup. You could even do this on the older platforms as well PB32 and PB1400E. One should ask I take it we are talking E-net, because DH+ and RIO can do the same. I'm all for two different panelview programs and seperate addressing in the PLC. Stay away from maintained buttons let the PLC do the work. Momentary buttons can latch up through the PLC and of course can be filtered with conditions required to run the motor. PV plus if new to you can create some headaches in the begining but will turn out to be a great tool. It also has all kinds of visibility functions that may be useful. I also had training with Wonderware which will work as well but I find AB products to be easier just my opinion. Once again creating two seperate programs is the way I would go it may prove beneficial at some point to pinpoint where something is being controlled from at a certain time.

 

[petersonra]

A Maintained Push Button does not latch the bit in the HMI. It simply toggles the bit in the plc. The other HMIs will see the state change and be able to toggle the same bit.

Maintained Push Button:
The HMI reads the value from the PLC register and stores it in it's local IO Database every poll interval. When you push the push button it writes a preconfigured value to the plc(1,0,Toggle). It then reupdates the IO Database along with all the other HMI nodes to the new value. All the HMI Nodes see the change of state.

Momentary Push Button:
When a push button is pressed the HMI writes a value to the PLC(usually 1). When the operator releases the push button it then writes the opposite value to the PLC(usually 0). All the HMI nodes see the state changes every poll interval.

A programmer needs to understands the risks involved with both of these buttons. It is a Big Safety No-No to use a Momentary Button with a Jog Function. When the Operator pushes a Momentary button, the HMI will attempt to write a 1 to the PLC. When the operator releases the push button the HMI will attempt to write a 0 to the PLC. If communications is intermittent/lost the 0 will never get written and you will have a machine that is permanently jogging. If a program is saved while a person had their finger on the push button, when it is downloaded next the machine can unexpectedly start jogging. It have to understand the risks. If you are smart you will treat momentary buttons as potentially maintained buttons in your HMI and PLC logic to avoid dangerous scenarios. You are putting yourself and your company at a huge liability if you don't understand controls and modern safety standards.

In general I agree with you, however, the description of how maintained PBs works is not completely accurate for all HMIs. Try an experiment some time. Take an HMI with a maintained PB feature (say a start/stop) and press the start. You should see it come on in the PLC. Turn power off to the HMI and reset that bit in the PLC with your programming software. Turn the HMI back on and see if the bit comes back on.

Try the same experiment with two HMIs and see if when turning on the start PB on one HMI, it shows on in the second HMI.

Another thing you might want to consider for AB HMIs is there is an option to save presets in the HMI. You want to turn this OFF! If it is not off, it writes the presets that were stored in the HMI to the PLC on power up. Very bad idea usually. especially if you have multiple HMIs.

 

[TxEngr]

As Bob said, not all HMIs act the same way. In my prior experience the HMIs did not interact and a maintained bit in one HMI was not communicated to any other HMI. You have to check the documentation of the system.

Good point about jogging from the HMI. I tend to prefer hardwired jogs anyway but it could definitely create a problem. It can go beyond jogs as well so take that thought with you on other critical programming as well.