How reliable are touch panel HMI's? 2

[rmore]

I have been tasked with designing a touch panel HMI into a product. The product must be able to run unattended 24/7/365. I know alot of HMI's are built on a windows CE platform, and we all know how often applications on windows machines tend to work better in some places than others.
My questions...

How rare is it that a typical touch panel HMI will crash or otherwise become unresponsive in some of it's functions, requiring a reboot?

Generally, what precautions can I take to minimize unpleasant occurances?

Are there generally accepted methods to automatically reboot an HMI when the program crashes or stops talking to the PLC?

Thanks, in advance for any information.

 

[itsmoked]

I have used many and have never had one crash or had one I've fielded crash. I think their SW is constrained enough to be thoroughly tested.

I use mostly C-MORE ones.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[IRstuff]

> simplicity and maturity are big factors in stability.
> airgapped system
> staying away from any OS that runs on any sort user accessible computer. the sheer complexity of the OS and ability of the user to muck up programs and/or OS are key drivers in software reliability.
> any user input should be vetted for format and datatype before it gets processed.
> input buffer overruns must be prevented


TTFN
I can do absolutely anything. I'm an expert!
homework forum: //

http://www.engineering.com/AskForum/aff/32.aspx

faq731-376 forum1529

 

[divine7]

Is your system performing a safety critical function?

Try and look at reliability figures of the HMI you are using. Some HMI design ensure that no more than 1 in 10 failures of its server than can jeopardize the integrity of information being acquired, logged and displayed

 

[rmore]

Has anyone experienced issues with machines with HMI's located near other equipment that use Variable Speed Drives? We have a piece of equipment with an HMI that appears to behave erratically (crashing) when a nearby compressor with a variable speed drive is turned on at the beginning of the day, and again when it is turned off at the end of the day.

 

[divine7]

Hello rmore. You might need to check earthing. So each manufacturer will have its earthing requirements which might be different from the ones you use. For instance, not doing your earth at both ends and doing it at only one point could case earth loops and all.

So you have to check your EMI/RFI immunity and check the way you have earthed and screened. It sounds like something I have experienced.

 

[eeprom]

The communications to the PLC is usually reliable. It is rare that panels will crash, but I have seen some issues with AB PanelviewPlus where they had some issue with the internal clock. Left unattended, this problem resulted in a frozen panel, but it took like a year to fail. That had to be fixed using a firmware update. But for the most part, they run forever. One possible glitch is how they handle a power cycle. First of all, they take a few minutes (not seconds) to boot up. If operator visibility is required immediately at power up, you might want to have your PLC delay executing any code for 2 minutes after any power cycles.

If this is a very critical application, one way to minimize your risk is to install two identical panels located in different areas. This is often done just for convenience, but it can also work for redundancy. Having two panels, your odds of having both fail are exceptionally low. There are some things to consider with respect to coordinating the two screens, mostly with respect to alarms and time. If you use the PLC for both alarm acknowledge (this would be a remote ack) and the time source, then the two screens will function as mirror images.

EE

 

[dV8r]

Most of the "brand" named HMI's are reliable today but of course they all have a few 'lemons' from time-to-time.
However I highly recommend that if it is at all possible your system should be designed in such a way that your machine or process can be run without it in an emergency.

 

[123MB]

+1 for PV/PV Plus - never seen one crash during production in 10 years. Only problems are caused by the programmers.

 

[triden55]

Choose a panel with a high MTBF. You'll pay more for it, but it's less likely to quit on you when you need it most. Brands such as PanelView and Magelis hold up really well in tough environments. I would stay away from the Automation Direct stuff in your application.

 

[roydm]

If the screen crashes it doesn't have to shut the system down while it re-boots it's only a window into the PLC
Consider having two screens or another way of putting to a safe state in an emergency.
Every Allen Bradley panel I bought had teething problems but I'm sure they have solved that by now.
Red Lion is my favorite.

 

[FreddyNurk]

There appears to be two groups of touchscreen HMI, the smaller cutdown capability (although the differences in capability are becoming less) units that are specifically designed for the application (Red Lion is an example, I'd suspect the AB PanelView would be similar), and the larger equivalents for standalone SCADA terminals.

A Wonderware (as an example) touchscreen is effectively a SCADA terminal with a touchscreen interface rather than a dedicated system HMI as an interface, and will likely come with all the dramas associated with a standard PC, plus a few more (ever tried to change BIOS settings on a touchscreen platform without an external keyboard?). A PanelView touchscreen is designed specifically to interface with the process equipment, and doesn't have the same high level OS issues, although if it still goes down, then the process may not be able to be viewed easily.

Each system type has its own benefits and drawbacks, obviously with a SCADA platform, the system was never intended to do direct control of the process, and this should be kept in mind. Other smaller platforms may or may not be able to handle direct control of the process, but the risks of panel failure are similar in terms of no longer being able to view the process on either platform.