Logic in PLC or HMI app?

Just wondering what other peoples thoughts are on using the script code in your HMI application compared to keeping the logic in the PLC.

If a programmer is going to be the only person to view the code then why not. The way HMI's are going you usually to do a bit of script.
Problem is if you plan to let maintenance troubleshoot, they are not going to be able to.

I'm no expert programmer (INEP?)...

I would use some "logic" in the answer.
If the script affects the HMI only (ie scaling etc) then use it in the HMI. If it affects anything in the PLC then do it in the PLC if possible; if you cannot do the script on the PLC, then I would comment in the PLC very well in the logic that it relates to.

My answer to that is a resounding NO.
One of my design goals on anything with an HMI, is that unplugging, shutting off, rebooting, or replacing an HMI should have zero effect on the operation of the controlled equipment.
Auxiliary functions, such as data-logging, and report generation may be disabled while the HMI is being replaced/repaired, but the machine operation should not be affected.
For the same reason, I insist on always having hard-wired start/stop/jog buttons, even if that functionality is duplicated on an HMI.

If I have only one HMI, and it's used to set the line speed, I will have an auxiliary speed pot that can override it (I use a 'Last Change' routine in the PLC to determine what speed reference source controls a machine. In one case, I had something like 16 speed pots, any of which could control machine speed).

Troubleshooting is also much easier if you only have one 'Control Source' to deal with.

rdrast said:

My answer to that is a resounding NO.
One of my design goals on anything with an HMI, is that unplugging, shutting off, rebooting, or replacing an HMI should have zero effect on the operation of the controlled equipment.

Click to expand...

I completely agree.

rdrast said:

My answer to that is a resounding NO.
One of my design goals on anything with an HMI, is that unplugging, shutting off, rebooting, or replacing an HMI should have zero effect on the operation of the controlled equipment.
Auxiliary functions, such as data-logging, and report generation may be disabled while the HMI is being replaced/repaired, but the machine operation should not be affected.
For the same reason, I insist on always having hard-wired start/stop/jog buttons, even if that functionality is duplicated on an HMI.

If I have only one HMI, and it's used to set the line speed, I will have an auxiliary speed pot that can override it (I use a 'Last Change' routine in the PLC to determine what speed reference source controls a machine. In one case, I had something like 16 speed pots, any of which could control machine speed).

Troubleshooting is also much easier if you only have one 'Control Source' to deal with.

Click to expand...

That's always been my policy

I concur.

Control belongs in the PLC.
Scripting in the HMI should be related only aspects in the HMI.

Even though we have customers who try to control their entire plants with a single G306, my view is also that the control logic belongs in the PLC. The HMI is, by its nature, vulnerable to damage from, for example, people using screwdrivers to operate the touchscreen. (Yes, it happens. Speak to our repair department!) It also contains much more complex code and will therefore be less reliable than a PLC. (Some people will claim all their code is 100% reliable, but that's just silly. The more complex the system, the more likely there is to be an error.) Placing control function in an environment where an error is more likely to occur is bad good practice.

So.....

What about HMIs with integrated PLC functions? I know some of our competitors offer these, and I know we've discussed them at length in-house. We've always come down to the view that an HMI is an HMI and a PLC is a PLC, and never the twain shall meet, but obviously enough people think otherwise for these things to sell, and from what I hear from certain sources, to sell in some quantities. This is making us wonder whether we ought to get on this bandwagon. But, what is the value add of such a device? The single programming pacakage? Or the (minor) reduction in cost from a single enclosure, PSU etc? And what about the pain of having to run wiring around the door hinge? I've never liked these devices, but I beginning to wonder if I'm in a minority.

rdrast said:

My answer to that is a resounding NO.
One of my design goals on anything with an HMI, is that unplugging, shutting off, rebooting, or replacing an HMI should have zero effect on the operation of the controlled equipment.
Auxiliary functions, such as data-logging, and report generation may be disabled while the HMI is being replaced/repaired, but the machine operation should not be affected.

Click to expand...

This should be the polic of the majority of programmers.

And Mike, I know what you mean about screwdrivers and HMI's, just got a call today that the start-button on one has ....... been 'punished' with a screwdriver.
Atm I'm refusing to replace it as the machine can still fully operate without that one button.
Like rdrast we prefer to have hardware to take over should the HMI fail.

MikeGranby said:

Even though we have customers who try to control their entire plants with a single G306....

Click to expand...

Now that is ridiculos.... you need a G308 or better for the entire plant

I use Unitronics plcs to exclusion, and they present an interesting wrinkle - the HMI and PLC are a single integrated unit, and portions of the logic can be run based on which screen is currently on display. The "unplugging" isn't really an option

Aside from that, I think I largely use the same principles as everyone else - screen logic should only affect the screens, so indicator logic and such go there. One likely exception in my approach is command permissions.

For instance, in a simple manual command, the code to execute the command is part of the system logic. The code to check if the command is allowed (not in auto, all sensors correct, etc) is part of the screen logic.

This avoids cluttering the system logic with permissives that don't actually impact the execution of the command, and if the routine triggers properly from one screen and not another, the problem is localized to the particular screen in question.

Because only one screen subroutine is ever active at a time, I don't need to track of which screen is displayed in system logic. This also allows me to re-use bits for pushbuttons, and although there is some duplication if a command appears on more than screen, since only one routine is ever active, scan time is not impacted.

TM

MikeGranby said:

But, what is the value add of such a device? The single programming pacakage? Or the (minor) reduction in cost from a single enclosure, PSU etc? And what about the pain of having to run wiring around the door hinge? I've never liked these devices, but I beginning to wonder if I'm in a minority.

Click to expand...

I've never used an integrated PLC/HMI device, but I can't imagine advocating one except for possibly the simplest machine where separate PLC and HMI are overkill for a few I/O points.

As for the original question. I never put any logic in the HMI that doesn't need to be there. That would just be asking for trouble later when the HMI needs to be replaced, or additional HMIs/SCADA systems are added.

rdrast said:

My answer to that is a resounding NO.
One of my design goals on anything with an HMI, is that unplugging, shutting off, rebooting, or replacing an HMI should have zero effect on the operation of the controlled equipment.

Click to expand...

I used to run by this rule but with the newer HMI's and all that they can do, i have plenty of customers who ask can we do this, add this, talk to this ? In the end without the HMI some of the functionality of the system gets lost and i now regard it as an important part of the system like the plc.

I do explain to customers if the HMI breaks in some cases then the machine wont function, most customers do not care and look at it like a plc in that a spare can be put on the shelf with a cf card for the program.

MikeGranby said:

So.....

What about HMIs with integrated PLC functions? I know some of our competitors offer these, and I know we've discussed them at length in-house. We've always come down to the view that an HMI is an HMI and a PLC is a PLC, and never the twain shall meet, but obviously enough people think otherwise for these things to sell, and from what I hear from certain sources, to sell in some quantities. This is making us wonder whether we ought to get on this bandwagon. But, what is the value add of such a device? The single programming pacakage? Or the (minor) reduction in cost from a single enclosure, PSU etc? And what about the pain of having to run wiring around the door hinge? I've never liked these devices, but I beginning to wonder if I'm in a minority.

Click to expand...

A G3 with perhaps some RL remote IO modules at a decent price, digital and analogue over say ethernet or 485 would be superb, din rail mount would be good also...

Hi Mr Granby,

I've worked on systems with separate HMI and PLC before - I cut my teeth on Rockwell and Modicon products - and I don't look back to those days without wincing.

In my experience, the benefits of integrated PLC and HMI, ala Unitronics, are:

1. No tag database - man, that's a nuisance. Having full direct access to every operand in the system can't be beat. No time wasted configuring all the tags, assigning addresses, going back and adding more tags when something get expanded. Massive time saver.

2. No communications headaches. We have a machine that marries a G&L MMC to an Exor panel using DH+ as the protocol. The MMC and the Exor did not share a common protocol, but both spoke DH+, so that's what got used. Comms are slow as mud, and occasionally drop out altogether. What a mess.

3. No protocol issues. In this same machine, the processor will communicate 32-bit data, but the HMI only does 16-bit (older machine), so there's a ton of extraneous logic added into the ladder to parse data passing between them.

4. Easier programming - one integrated environment, seamless switching from HMI to ladder. One file to rule them all, and only one to keep track of for modifications and archives.

5. Reduced outlay, not buying separate pieces. Sure, you can argue that you end up replacing 2 major components if the screen gets damaged, but the cost of these combined, in Unitronics' case, far below the cost of either component from AB, so not a major issue as far as I'm concerned.

And that's just off the top of my head. Yeah, this all breaks the "rule" that "the HMI is the HMI and the PLC is the PLC". But to my mind, when you break an existing paradigm, it should be for sufficient benefit. And using an integrated unit is of sufficient benefit to merit leaving that particular rule in the dust.

My two bits.

Thanks!

TM