# HMI Softwares

P

#### parviz parvizi

Hello
Is it better to write our own HMI by delphi and HMI components or use commercial available HMI softwares like as citect?which is technically and economically better?

What you do with your HMI ?did you write your HMI by delphi or you used HMI softwares like as citect?

Regards

R

#### Rufus

Definitely a "Horses for Courses" question.

If it was a low volume and/or large scale and/or quick delivery project, I'd go Citect or similar.

If it was higher volume or you had specific unusual requirements, or delivery time wasn't tight, I'd go with the "Roll your Own" HMI.

Personally, I'd go with Delphi/Kylix. But I'm a programmer...

Even Visual Basic is viable, if you don't mind supporting Microsoft.

But be prepared to make a lot of design errors and mistakes and possibly rewrites. Citect and others have already gone through the mistakes and rewrites for you, so you pay more because you're paying for that development work they've already done.

However, if you are doing many HMI's, you can develop your own templates and libraries so each project gets faster and cheaper.

Rufus

Rufus V. Smith
[email protected]
http://members.aol.com/rufusvs

P

#### process engineer

It is better to use one of the commercially available packages unless you want to be in the software development business. Many companies have tried to develop in house packages but always revert back to buying one available after they fail inhouse. Bottom line is that a Company can't fund a staff to keep a package current with feature sets and technology and usually the person who wrote it leaves and then there is no support. Companies like Wonderware spend 20 million plus each year on development. Why not take advantage of that investment. The prices of these packages are always less than the total cost of developing and supporting an inhouse developed package.

M

#### Michael Griffin

It is better to define what your application needs to do before you worry about how you are going to do it. An "HMI" can be many things, so there is no standard solution for all applications. The "technically and economically better" solution depends upon what your application is.

--

************************
Michael Griffin
************************

J

#### JP

It is always better to buy then to create.

Visit http://www.wonderware.com for a product for all ages... and enjoy the experience!

JP

P

#### Paul Pierce

Hi,

the answer is rather subjective and it depends on who you ask. I expect you will get a few replies to this.
Firstly do you mean HMI as in Operator Panel interfaces? Usually these require dedicated development packages i.e. Siemens Protool, AB Panel View...
I think you mean SCADA software like Citect, Wonderware, WinCC...

In my opinion, it is better to use dedicated SCADA software. There are several reasons for this, time and range of functinons being major factors.
But really the big question is the cost of the project?
Development software and licences for SCADA are expensive.
Vb, C++ are fine for doing the development (I don't know about Delphi, but I'm sure it ok).

If the cost of the project is small and there is not much control to be done then go with your own development.
But really when it comes to logging, trending and connecting to other PLCs, SCADA software is the best way to go.

Hope this can be of some help.

Regards,
Paul.

B

#### Bob Peterson

I issue a hearty "amen" to that comment. What scares me is all these HMIs out there in ancient O/Ss written in who knows what language that will be coming up for replacement in the next 5 or 10 years.

Who wants to tell an end user that the HMI created by some guy working out of his garage 5 years ago (who has since vanished) is not able to be modified because there is no source code, or the code is so bad its near impossible to work with, or the OS or computer it used is no longer available.

Now the end user has to pay for a whole new system, generally having to be created by reverse engineering, since there is almost never any documentation to be found on these made on the cheap HMIs.

All of a sudden, the inexpensive HMI becomes very expensive.

Even worse is this scenario. The end user is too cheap to replace these abominations. It fails and can't be fixed. His machine is down for the two or three weeks its takes to get it back up, paying emergency service prices. The bargain rapidly becomes a non-bargain.

R

#### RufusVS

JP,

That sounds not only like an answer from someone with limited perspective, but also like an advertisement.

Rufus

Remember, ALL generalizations are WRONG!

C

#### Curt Wuollet

Hello Mr. Engineer

I agree that packaged systems are often best for those with compensation and turnover problems (most employers), but that doesn't justify such sweeping generalizations.

process engineer wrote:
> It is better to use one of the commercially available packages unless you want to be in the software development business. Many companies have tried to develop in house packages but always revert back to buying one available after they fail inhouse.

Failure in this occurs at about the same rate as failure in their line of business projects, and for the same reasons.

> Bottom line is that a Company can't fund a staff to keep a package current with feature sets and technology and usually the person who wrote it leaves and then there is no support.

That's one of the reasons. This is usually a management problem related to cluelessness more than funding. These guys seldom get a fabulous increase to work somewhere else. They just want to work for someone else.

> Companies like Wonderware spend 20million plus each year on development. Why not take advantage of that investment.

Because they fund that development with an upgrade and support mill that makes the initial purchase only part of the cost. At some number of installations the total cost for inhouse development may very well cross over. A great many of these packages began that way, so it's silly to suggest that it can't be done. It probably won't be done as a part of the job with VB, but that doesn't mean that a general class solution is always better than custom work. Or that software companies have some special magic that makes them more competant. Most software companies rely on a very few really good people. Those people could do the same anyplace that supports and respects them. And for that matter, they can do the same without any company if they so desire. Or on their own time for an OSS project, for example. The folks at the software companies are probably ROTFL at your awe and reverance for their image.

> The prices of these packages are always less than the total cost of developing and supporting an inhouse developed package.

Yeah, right. Until they simply stop supporting the product and you eat the cost to upgrade or reimplement. Or you have a few nagging problems that they ignore, or any of the legion of chronic complaints that cross these pages. It's curious how folks can copy the mail here and come to the conclusion that the status quo is the one true way. Even people with second degree burns get back in line again and encourage others.

Why can't there be a better way?

Regards

cww

C

#### Curt Wuollet

And even better to create a small part and use the rest for free in payment for your contribution. And support each other.

Regards

cww

M

#### Michael R. Batchelor

As one who has developed a couple of VB based HMI's at the customer's request, I can agree with these about 95%. The only time I've seen a "custom" HMI make any sense whatsoever is if you're an OEM machine builder who is going to place a fairly large quantity of identical units a year in the field. (Witness the fact that nobody uses iFix or Wonderware to run a consumer VCR or microwave oven, and some of those are pretty sophisticated these days.) But even if you're going to place 5-10 units, it's still less expensive to get a runtime license for each unit and not make yourself crazy. At 15 or 20 units it starts to look attractive, but I'd still lobby against it with that few units. At 50 units a year you probably have a good case. Somewhere between 20 and 50 is a break even point that is situationally determined by your margins, etc.

Even if you can make a case for it, you *WILL* have legacy problems as the years go by, and yo uneed to allocate budget to handle it.

Just as an example of taking our own advice, we're current working on a system with projected sales of 25-30 per year, and we're using one of the off the shelf HMI development packages. My justification is that any field service calls only need a competent control system engineer, not a software engineer with a complete development suite on his portable as well.

MB
--
Michael R. Batchelor - Industrial Informatics, Inc.
Contribute to society: http://www.distributed.net/ogr/
MB

M

#### matt hyatt

I agree with the thought that inhouse development is not very cost effective, unless you can market the product and supply the service (support), your wasting time. Case in point last company I worked for had a really good (not an expert, just good)software guy - it wasn't his job, but he put hundreds of hours into a variety of software features and functions that never got sold to any customers and it turnd out Intellution IFix support team was willing to provide for us all of the same features that he spent all that time working on (to no avail) and they provided support for all of their stuff as well, we couldn't because the company did not have the budget for his time to be spent dealing with the multitude of issues that invariably crop up when you do your own development. Consider this if your paying someone 60 to 80K per year to develop code, your going to have to sell a lot of those packages to even to begin to re-capture their salary, not inculding a ROI and you have not even gotten to support cost. (What about liability and licensing issues?) Programs such as IFix and Wonderware are solid, have excellent support and work on so many platforms that it is not even a consideration to do your own, what happens when you no longer can afford to support the product?, can't write a driver to interface with another product?, can't get a license agreement to use a driver?, it does not work on this platform or that one, or has to be modified to run on the lastest Windows OS or even the latest Linux OS version? Are you willing for a one time development to commit the next several years (10 to 15) supporting this product? What will that cost you?
What happens if you get hit by a bus? Computers and the OS platforms are changing so fast that it is not even reasonable to consider the development cost when you can buy a product which will work 99% of time on 99% of the platforms out there today and even for the next 5 to 10 years.

For the cost of a unlimitied tag IFix package + Global Icare, you think you can do all their software does, better, faster, cleaner, across multiple platforms and provide all of the various drivers and features? Remember they have 100's (maybe)of programmers at their beck and call, you have how many (maybe youself and three or four other guys - heck there is 240K for 1 year of work already, what if you only sell 3 to 5 packages, and then have 5 years of support cost? -your software doesn't do this, can you make do that?, what about historical data collection, trending, reports, alarming, TCP/IP connectivity, does it work on NT, XP, RedHat, does it talk directly to Allen Bradley PLC's, what about Siemens PLC's?) - your package out of the gate is going to be 4 to 6x (minimum) the cost of the IFix solution and it is not even proven yet, you had better be one hell of a prgrammer to pull it off, otherwise your ROI is going to be very, very small.

As far as HMI's go, get a RedLion CL20, or similar product, in a week you can build a great operator interface, that can communicate with 99% of the PLC's out there and even with most SCADA packages, without being an expert programmer (heck I did my first one in a week using a Redlion and a Motorola Moscad-L product, it would have taken months to do it ourselves and the customer would not have paid for it becuase it would have cost at least 10 or 15X the solution we provided.)

If you want to be adeveloper, go work for a development company, get paid well, get all of the benefits, retire in 20 years and never have to worry about someone calling you 15 years later wondering if you can fix their HMI or SCADA program you developed 15 years ago and there is no support for it now or they need changes.)

matt

M

#### matt hyatt

Rufus,
I have to disagree, not all generalizations are WRONG!

Generally speaking what do you think it would cost you to develope an OIT (or HMI) to be the equivalent of a Redlion CL20 product with all of the manuals, support assistance, programming tools and such? Oh, and I need it in 1 week (40 to 50 (max) hours not 120 hours) and my budget is only $3K for the whole job, I will done before your even finished writting the source code, and I will make 25 to 30% on the job and there will be support for the product for the next 10 to 15 years and will your product work with the top 10 products out there?, is that geneal enough for you? You don't have a chance generally speaking! Matt D #### Dave Alright, time to reply.................. No, in the real world most of us have to focus (and I hate to use brainless buzzwords) on our CORE COMPETENCIES..........our companies cannot and will not any longer in this tough business cycle, support a "software development staff", and a "Check writing staff" and unfortunately in a lot of cases an "IT staff", in this quarter to quarter world we live in, those are outsourced to people who focus on them as their Core Competencies..........sorry that is the way it is, I have to focus in my case on making paper......using my skills and tools (yes tools) that are available.....Could I write a better HMI program after all these years...Probably, but what would it cost my company for the development time, support staff, support time, modifications when new OP systems came out (even Linux changes) etc........ CWW - Hello Mr. Engineer CWW - I agree that packaged systems are often best for those with compensation and turnover problems CWW - (most employers), but that doesn't justify such sweeping generalizations. process engineer wrote: > It is better to use one of the commercially available packages unless > you want to be in the software development business. Many companies > have tried to develop in house packages but always revert back to > buying one available after they fail in-house. Yes that is why most companies have turned to "canned" packages like SAP, BAAN , Maximo, etc vs. "home grown" packages which eventually failed when people left, software changed etc........and yes there are places where people actually retire from versus leave due to "as you put it, poor compensation, etc." CWW - Failure in this occurs at about the same rate as failure in their line of business projects, and CWW - for the same reasons. > Bottom line is that a Company can't fund a staff to keep a package > current with feature sets and technology and usually the person who > wrote it leaves and then there is no support. Whaaaat ??? CWW - That's one of the reasons. This is usually a management problem related to cluelessness more than CWW - funding. These guys seldom get a fabulous increase to work somewhere else. They just want to work CWW - for someone else. > Companies like Wonderware spend 20 million plus each year on > development. Why not take advantage of that investment. If you are in the software business............I have to justify my decisions on "business cases" and they do not assume "cost of purchase" and anyone who does is an idiot.........they must take in "total cost of ownership" and by the time I staff up a support team and pay them (yes they want to get paid) and then pay their benefits (funny, they actually want them also) and then I manage them (yes, they seam to wander aimlessly without some coaxing), the$5000 initial investment and \$250/year per package (being generous) ends up slightly cheaper.....(some costs actually left out, before you jump on that one)

CWW - Because they fund that development with an upgrade and support mill that makes the initial purchase only part of the cost. At some number of installations the total cost for in-house development may very well cross over. A great many of these packages began that way, so it's silly to suggest that it can't be done. It probably won't be done as a part of the job with VB, but that doesn't mean that a general class solution is always better than custom work. Or that software companies have some special magic that makes them more competent. Most software companies rely on a very few really good people. Those people could do the same anyplace that supports and respects them. And for that matter, they can do the same without any company if they so desire. Or on their own time for an OSS project, for example. The folks at the software companies are probably ROTFL at your awe and reverence for their image.

And that is why you find reputable companies and take the risk that they will be around, if you go to "flavor of the week" companies then yes that risk is greater (there are no guarantees) but if you stick with companies like Microsoft (Please Curt, I am well aware of your opinion on this one), Cisco, Rockwell (ditto last anti-spam comment), Emerson, GE and any of the other "BIG" players, then your odds go up significantly...........

> The prices of these packages are always less than the total cost of
> developing and supporting an in-house developed package.
CWW - Yeah, right. Until they simply stop supporting the product and you eat the cost to upgrade or reimplement. Or you have a few nagging problems that they ignore, or any of the legion of chronic complaints that cross these pages. It's curious how folks can copy the mail here and come to the conclusion that the status quo is the one true way. Even people with second degree burns get back in line again and encourage others.

CWW - Why can't there be a better way?

Yes I understand all of your comments/arguments but you can write all day on this list and you are not going to convince some of us that it is "cheaper" in the long run...........while you are off building tools, I am actually out there using them to make better widgets............which is what they actually pay me for, making better widgets.....(Unless you just want to be a tool builder in which case, "Have at it"), but most of us (I hate to generalize, so no spam please) are TOOL USERS..............

Everyone can go to Home Depot and buy a hammer, doesn't make them a Craftsman, everyone can go to the art supply store and buy paint , doesn't make them Artists...........It's just a hammer for gosh sakes..................

Old line.........What is the difference between an Artist and a Painter..............One paints houses.........

As Dick Morley says "Manufacturing jobs left 10 years ago, Assembly jobs are leaving now, and Intellectual Property jobs (Engineering) are right behind them"

While we are all busy arguing about the tools to use, others in this world are busy making better products, focusing on "tool usage", Engineering and R&D and we (US) are all busy worried about our ego's and what kind of software is best..........Lets actually make better products and focus our attention on the process, not the hammer............

My 2 cents............

Dave

D

#### Dave

TCO, interesting concept....hmmmmmmmm

Dave

M

#### Michael Griffin

> I have to disagree, not all generalizations are WRONG!
<clip>

Actually, what is wrong is deciding on a solution when you don't know what the problem is. The original poster said he needed an MMI (or HMI). He didn't say what he needed it for or what it had to do. If you want a very low cost and easy to maintain MMI, you might consider using a single illuminated push button. It lights up to tell you something, and you can push the button to communicate back to the control system. This fulfills all the criteria that were originally stated (there weren't any).

Packaged MMI software, conventional programming languages, programmable operator interface panels, and push buttons are all valid, reasonable, economic, and responsible MMI solutions. They just happen to each be best used for different applications.

--

************************
Michael Griffin
************************

R

#### Rufus

matt,

That statement was meant as a joke, as it is self-referential and self-nullifying. I could have added "... including this one!" after it, but that would have been too obvious.

It's kind of a zen thing...

Rufus

V

Hello automation,

If the number of the devices is large (we deal with mass-production), if the UI is simple, if there is no need to modify it at all...

And there is the problem to extend the functionality of the market available HMI, and there is the upgrade problem, and there is the vendor dependence problem... as we undrstand large vendor can dead as well as small one.

Every case demands an analysis and a unique apriory unknown solution.

--
Best regards.

C

#### Curt Wuollet

It's interesting that this discussion is polarized, with strong feelings on both sides. Build or Buy. Each having it's own set of problems. I really like the statement that commercial software works with 99 percent of the platforms out there, when it works with zero percent of the platforms here :^)

Cost vs Cost arguments are offered, and partisan generalizations aside, all of the arguments have merit, yet all are flawed.

For example, the "support down the road" argument has merit in that it is a significant committment to support an inhouse package going forward and you might have to be nice to your programmer. It is flawed in that this list spends the majority of it's bandwidth talking about commercial software (and hardware) that is no longer supported. And about issues that shouldn't exist if the commercial model were even half as great as it's passionate supporters firmly believe.

And the time argument similarly ignores the time lost on bugs, work arounds and the universal upgrade headache. And of course, the vast waste of time keeping the base platform running and virus free, which is an 800 lb gorilla that is utterly and most conveniently ignored yet is another major bandwidth item here. But, it is a large undertaking to replace the functionality of the popular packages by rolling your own. And is perhaps economically unfeasable in the general case, this coming from someone firmly in the DIY camp.

Build or Buy, Buy or Build, pick your set of problems. But no one seems to consider that there could be a middle ground that mitigates all the arguments to a greater or lesser extent. In each case tending towards the practical and offering more advantages that either buying or inhouse building. That middle ground exclusively belongs to OSS user supported software.

What makes commercial software viable is that it is written once and used many times, thus spreading the development cost over many users. OSS works that way, but at lower cost, as you contribute a little and get a lot in return. And you don't pay for the tremendous overhead. It retains all the advantages of inhouse development as you can add and change things to suit your needs. But, the amount of work needed is little more than using a commercial package. And the time is also maybe a little more than out of a box, but far less than doing it all yourself. The "down the road" support issue for OSS, also offers the advantage of a community like this one and is easier than either Buy or Build. And it can never go unsupported or be obsoleted.

It's this sensible middle ground that we should be discussing as it reaches out to both sides and offers the advantages of both with the disadvantages of niether. Why is it so hard for folks to get behind the most sensible option and become a community to make this happen?

Regards

cww

J

#### Joe Jansen/TECH/HQ/KEMET/US

For the humor impaired, the "ALL generalizations are WRONG" comment is recursive humor. The statement itself is a generalization, thus, by it's own declaration is wrong, but, if it wrong, then some generalizations are
right, thus, it may not be wrong, but actually right, which would make it wrong.

HA HA HA....

Lighten up....

--Joe Jansen
ICQ# 39 182 450