Questions on Specifying an HMI and Working w/Integrator

Z

Thread Starter

Zack Stair

HMI Community, I was pegged to replace current operator interface (HMI) yet had never heard of an HMI before. I have tried to educate my mech. engr. self. Currently we have a VB driven Dynapro HMI. This, i believe, communicates with an Indramat CLC and PLC's (Diaxo 03 n 04, communicates with MS DDE link.). I am charged to replace the VB/Dynapro for a lower cost, simpler system and reliable while keeping everything else. I have pared the screens from 10 to 3 with, as far as i understand, 50 I/0's(?). Screen 1 includes one "field" to select 1 of 4 choices on the screen, three fields to select 1 of 3 choices on the screen, and four numerical inputs on screen. The software that would be programed with the HMI would need to be able to do math ratios, fractions etc and recognize max & mins based on the choices made on screen. The rest of the I/O's would be used for alarms and push buttons. The second screen would be outputs from the inputs, with the 3rd screen being alarms. The No networking capability, database storage, does not need to be color and can have a numeral keypad w/arrows or touch screen. How do i choose a low cost HMI to best suit me? (I have been lookin at automation direct, exor stuff, A-B, and eason because that is what we have in house, but do not know what to look for.) What information do i need for the programmer/ integrator? (Probably be using a local guy.) Where can i get a better understanding of everything necessary to manage a project about an HMI with competancy? (Website, mag articles...?) Thanks for any input, because i'm just winging it. Thank God for the internet. Zack Stair - PA Mech. Eng.
 
B
Hi Zach, VB is great and very flexible but it chews engineering hours and very difficult to maintain. My suggestion is get a Scada Package which has all the build in features you require - most Scada pages will do the job. My personel preferance is Citect, is is extremely powerful has many drivers( can communicate to different PLC'S) and will do all the functions you require. It is one of the cheaper packages on the market. Another package I would consider is iFix. Configuration is a simple job and most integrators will be able to help you. You could keep the Dynapro or use another Industrial PC but I am sure it will do the job. If you run into any problems you can contact me for advise.
 
If you're looking for low-cost HMI, then VB is probably the best way to go. Most other SCADA or HMI packages require a run-time licence that must be purchased each time the application is used on a different machine. From what you've described, VB would be inexpensive and easy to maintain (if written and documented well - just like everything else).
 
B
The problem with VB is that you have to make some sort of plan to communicate to the PLC. Implementing a PLC protocol using the MScomm object is quite painful and time consuming. You could probably short-cut this route if you purchase an OPC driver, but then you could use the drivers in supplied in the SCADA package. These drivers have been used in many plants throughout the world and usually are tried and tested. If you require trending in VB then you must log the data into a database (probably Access) and then use msChart to show this data. - I have done this and I can definitely assure you this is not what you want in terms of expanablity ,maintaince and engineering cost. Not to mention the functions of Alarming and Reporting that you would have to implement. All these functions are already built into most SCADA packages and it is a matter of configuration and not programming. When you compare the cost you must take engineering hour into consideration. GoodLuck
 
N
If you are going to use a OIT Terminal (PanelView, PanelMate, Exor, etc.) rather than software (VB Code, Wonderware, Intellution) on an industrial computer you need to make sure they have a driver for the Indramat CLC, which most of the names you mentioned don't. The one that does which I know of is CTC www.ctcusa.com. Feel free to contact me offline if you want. Best Regards, Nick Pirog CPU Automation, Inc. Voice: 978.692.5404 Fax: 978.692.8844 email: [email protected] web: www.cpuauto.com
 
J
Whether using VB or an off-the-shelf HMI/SCADA package is up to you - but i would like to clarify something on one assertion made here on the list re: trending in VB ><---snip---> >If you require trending in VB then you must log the data into a database >(probably Access) and then use msChart to show this data. You do not have to log the data to VB to trend it. and you do not have to use MSChart either. There are affordable off-the-shelf trending activeX components available that do a nice job of trending data in VB and rival or exceed (i.e. no pen limits) the functionality many of the trend charts built into off-the-shelf SCADA applications and they do not require you to log the data to a database to be able to use them. You can certainly log data to a database AND trend if you want to, but to say you MUST log data to a database in order to do realtime trends is not the case. Is this a better solution for you - i wouldn't purport to claim that without a full evaluation of your needs. As the writer of the above comment said, it sounded like it didn't work well for him in total life cycle cost. On the subject of drivers: if you use OPC drivers they handle all the gory details of the communications to the PLC, there are ActiveX components available that make it easy to marry VB to OPC servers without a ton of custom code. this lets you leverage the field testing that off-the-shelf OPC drivers give you while having the choices avialable to you in VB. Even if you use an HMI package you still need to plan your communications. Last time I checked, that's what part of engineering was --plan, design, implement -- the off-the-shelf tools whether they be HMI solutions or OPC drivers or other drivers can make your "planning" part easier in some cases. OPC drivers take care of optimizing packet sizes, polling lists, etc (if well written) to manage communications for you. At the other extreme, if as one writer said, you plan to write your own serial driver with MSComm, sure you better expect a lot more planning and engineering work -- hence the reason many engineers will opt to license a driver that's been written, field proven, and supported by people who do that for a living rather than do it from the start themselves. That's not always a choice depending on the protocol and how obscure it is. configuration vs. programming Keep in mind that although with off-the-shelf HMI solutions you do more configuration than programming, but don't get lulled into thinking there's no programming. Depending upon what you need to do in terms of customizing the off-the-shelf solution to your needs, you will find yourself programming, either in VBA ( a subset of VB that many HMI/SCADA packages use) or a scripting language provided in the HMI application to do the customizations you might choose to implement. Nothing wrong with that -- many of the HMI/SCADA packages do a nice job of giving you a mix of configurablity and programmability to meet user specific needs. Just be cognizant of the fact that configurability doesn't mean "you'll never see scripting code or programming". All the same, a comment heard here rings true no matter what solution you consider, you will need to consider the value of engineering time in training, development, and ongoing maintenance and support of your solution, whether you do it yourself or contract with a qualified integrator to do the job for you. Hope the input helps you in your evaluation and decision making process Jerry. Sincerely, John Weber Software Toolbox
 
A

Alex Pavloff

Now, I'm going to disagree with you here. I work for Eason, one of the companies that the original poster said he was looking at, so yes, I am biased. :) Wonderware and all those comparable packages are very powerful, and they plug into many things. I would agree that VB would probably be the best fit it this app is going to have to be run on a PC -- no need to spend the money for the runtime licenses there. &lt;pulls out his horn and starts tooting away> However, our company sells hardware (and the software to program the hardware) that would be a perfect fit for this sort of smaller project -- via BASIC, users can program their code to have an app almost as flexible as a PC, without the hassle of having a PC. &lt;puts the horn away>
 
B
At 01:10 PM 2/6/2001 -0500, you wrote: >The problem with VB is that you have to make some sort of plan to >communicate to the PLC. Active X PLC drivers have been around for years and are well tested. >If you require trending in VB then you must log the data into a database >(probably Access) and then use msChart to show this data. - I have done this >and I can definitely assure you this is not what you want in terms of >expanablity ,maintaince and engineering cost. Not to mention the functions >of Alarming and Reporting that you would have to implement. It may be far simpler to not use Access. Just declare a large array of user-define types and store your data in RAM. It is very simple to read and write the array to disk, if you need. Alarming and reporting are very simple in VB also, IMHO. >All these functions are already built into most SCADA packages and it is a >matter of configuration and not programming. When you compare the cost you >must take engineering hour into consideration. It is a classic make versus buy decision. The right answer will vary, depending on the circumstances. I do not believe that there is one right answer. I have used RSView and had over 60 pages of VBA code, so you can even have the best of both worlds, if you like. One major advantage with RSView over VB, is that you can edit RSView while it is running. That is very important in the process industries. With VB, you must stop the program to make a change. Bill Sturm
 
Thank you for your reply. You are right. I am leaning toward a basic hardware HMI option with light programming/configuration. To be able to present eason as an option, does Eason have Indramat drivers? You can e-mail me at [email protected] so we could dialog on how to use an eason for my application. Zack - original poster.
 
John - thanks for your post. I appreciate your comments and will take them into consideration. Zack - original message post.
 
E

Eric J. Feight

I have been developing SCADA systems for the past 15 years. I'll offer some of my observations. VB is great from a software cost standpoint. Implementation will be costly from an engineering standpoint. You will have to develop and/or find (ActiveX, OPC, etc) every piece of the puzzle. If you’re doing this in house it might not be a bad route to go given the availability of lower engineering costs (in-house vs. contracting to a systems integrator). Here’s the catch, custom code is custom code. If the developer leaves (not that anyone is changing jobs a feverous pace lately) you will be in a bind when it comes to future maintenance or expansion of the system. Canned packages like Cimplicity HMI, Wonderware, RSView and packages like that come with a price tag. I think you’ll find, as I have, that the upfront cost of these packages is offset by the shorter development time and you will have far less problems when it comes to talking to your hardware and logging to databases. My favorite so far is Cimplicity HMI especially if you’re going to do a lot of data logging. On the subject of data logging, do yourself a favor….. make sure you log to a standard format like Access or SQL. Wonderware for example still uses it old clunky proprietary flat file database that is a real pain to extract data from for reporting and analysis. You can purchase their SQL module (~$1,000 if I remember right) but you then have to write scripts to do all the logging and query work. The other advantage to using an industrial standard package is that you are not locked to a single person or company for support. I have seen a lot of integrators that use non-standard packages that have a relatively few number of engineers who are familiar with them. This locks you into going back to the same integrator for future work on the system. If that isn’t bad enough, I have seen several instances where the engineer who developed the system left the integrator and now the end user has little to no support avenues left.

The bottom line is SCADA development is not cheap. My opinion is it’s more cost effective in the long run to utilize packages that have hundreds of thousands of hours of development and testing time behind them. Outsourcing to a control systems integrator is usually the quickest and ultimately the cheapest way to go. They will probably get a better discount on hardware and software than you can get. This is also what they do. They know all the pitfalls that you will have to find on your own. A word of warning. If you go the integrator route, don’t base your decision on just price. Make them provide resumes and experience lists of the engineers who will be working on your project. Look for certifications that mean something in today’s environment like MCSE. Also ask them to provide a contact list of similar projects that they have completed and CALL THE PEOPLE ON THE LIST! If you are dealing with reputable integrators they will probably already have this information compiled and available on request. I know I have been asked to provide this several times lately. It can be put together from scratch in a couple hours. If they don’t want to provide you with this information (no matter what the excuse) you have to ask yourself………. Why?

I hope this was helpful. Please reply if I can supply you with any more of my overly opinionated thoughts. Good luck!
 
Top