Control.com - Nerds in Control

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

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
RufusVS@aol.com
http://members.aol.com/rufusvs

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.

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

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
London, Ont. Canada
************************

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

JP,

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

Rufus

Remember, ALL generalizations are WRONG!

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

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

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.

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.

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

> 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
London, Ont. Canada
************************

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

Hi All

Zen thing or no, its kind of a sense of humor thing for me and I would appreciate more of it around, way too heavy most of the time around here!!

Donald Pittendrigh

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

I think claiming that there are no disadvantages is not accurate. There are at least perceived disadvantages. I suppose you might argue that people's perceptions are wrong, but they are there nonetheless. Ignoring them won't change them. The average automation engineer that just wants to use a product will not consider an OSS solution that requires them to compile it first to be equivalent to an off-the- shelf commercial product that they just use. Many would consider the state in which an OSS product is delivered to be no different than a build-your-own except that the entry cost is lower. And, it doesn't surprise me that they would consider obtaining support from an amorphous "community" as more uncertain than contacting a well-known company for support. Granted, you have to pay for commercial support. But at least there you can make demands and have some expectations that they be fulfilled. I know it's not perfect and some companies are better than others. But, if no one solves your problem in an OSS discussion forum, what do you do next? Hire a consultant? How is that different from paying for support? As I said before, IMHO, you should make the case for OSS on its own merits without attacking commercial solutions. If the reasons for using OSS are always based on the supposed failure of commercial solutions, you are fighting a losing battle because the vast majority of people know, from first hand experience, that many commercial products they use have solved their problems successfully and cost effectively. Your assertions about the failure of commercial enterprises directly contradict the experience of most people. It will be hard to gain traction that way.

Regards,
Ralph Mackiewicz

<clip>
> The average automation engineer that
> just wants to use a product will not consider an OSS solution that
> requires them to compile it first to be equivalent to an off-the-
> shelf commercial product that they just use. Many would consider the
> state in which an OSS product is delivered to be no different than a
> build-your-own except that the entry cost is lower. <

This discussion has gone around before, and the problem is that people are comparing an "MMI toolkit" to products like WinCC. This is a red herring, because they are not comparable. However, there must be a market for MMI toolkits, because people (e.g. National Instruments and others) are selling them now. They are not competing directly against WinCC (and similar products) though. Most custom computer applications need an MMI, and the only way to have one is to use a toolkit or write your own.

> But, if no one solves your problem in an OSS
> discussion forum, what do you do next? Hire a consultant? <

Write a message to the Automation List and ask for help? We seem to get a lot of those for products which people have paid good money for. OEM support is not a panacea. However, if we are just talking about an MMI toolkit, then support should be a very low risk problem, as the different bits are independent of each other and there is very little which can go wrong with each individual one.

An MMI toolkit would be a small project that could be created piecemeal by various people working independently of each other. Since the main alternative to an OSS MMI toolkit seems to be the DIY approach, the barriers to acceptance of such a toolkit would be fairly low.

--

************************
Michael Griffin
London, Ont. Canada
************************

Hi Ralph

> I think claiming that there are no disadvantages is not accurate. <

I don't recall saying it was totally without disadvantages, just that it didn't ahare the disadvantages of the other two. But, your points are well taken, it is these perceptions that I seek to change. The support from the community _is_ very good, but it is different and takes some getting used to. When I first made the decision to use Linux for my ATE, I had some reservations and for quite a while, I tried to solve everything on my own. Since then I have found it much more efficient to ask for help if I have done my homework and I'm still stuck. Provided you do your part, I have found the support excellent, It takes very little time to email the author or search the newsgroups and it's always available. No time is wasted with people and procedures that can't really do anything. This way you either get the answer directly or you are dealing with someone who can actually solve the problem. That simply doesn't happen very often with commercial product support. If you have a lot of RTFM problems commercial support is ok, but if you have real problems, commercial support is often useless. "That'll get fixed in the next release" is not a very useful response.

> There are at least perceived disadvantages. I suppose you might argue
> that people's perceptions are wrong, but they are there nonetheless. <

I would prefer not to argue, but to educate and encourage folks to try it. Any change in how one does things requires learning and effort, the best that I can do is point to the fact that a very high percentage of those who make the effort consider it very worthwhile and many become evangelists.

> Ignoring them won't change them. The average automation engineer that
> just wants to use a product will not consider an OSS solution that
> requires them to compile it first to be equivalent to an off-the-
> shelf commercial product that they just use. <

We are past that for the most part, you can get RPMS or some other easy to install binary package for most things nowdays. In our sphere, most commercial packages require more than install and go, unless you are familiar already. I don't think mature OSS requires much more effort than commercial offerings. It's just getting past that first install. For example, many Windows users would bitch just about as much about installing Windows from scratch as recent Linux distributions, but many Windows users have never installed Windows, it came with the box. So if they try Linux, yes, it's much harder than getting a machine already loaded and configured. Yet, when I provide boxes ready to go, people do remarkably well with recent Linux. The problems are not unlike changing Windows versions.

> Many would consider the
> state in which an OSS product is delivered to be no different than a
> build-your-own except that the entry cost is lower. And, it doesn't
> surprise me that they would consider obtaining support from an
> amorphous "community" as more uncertain than contacting a well-known
> company for support. Granted, you have to pay for commercial support.
> But at least there you can make demands and have some expectations
> that they be fulfilled. <

Yes, you can make demands and have all the expectations you wish. My experience is that problems actually get solved with community support. That's much better than making demands and having expectations.

> I know it's not perfect and some companies
> are better than others. But, if no one solves your problem in an OSS
> discussion forum, what do you do next? <

I would contact the author or maintainer, politely. It's worked well so far.

>Hire a consultant? How is that
> different from paying for support? <

Well, it'd pay my bills :^) but it's seldom necessary unless you want to modify or customize rather extensively.

And if you don't get a solution from AB or GE, precisely what do you do now? If you read your license, they don't guarantee anything. So you find another way or a workaround. And most of the time you continue doing business with them because you can't afford not to. I much prefer having the ability to fix it myself or hire it done as a last resort. I think objectively, my options are better than yours.

> As I said before, IMHO, you should
> make the case for OSS on its own merits without attacking commercial
> solutions. If the reasons for using OSS are always based on the
> supposed failure of commercial solutions, you are fighting a losing
> battle because the vast majority of people know, from first hand
> experience, that many commercial products they use have solved their
> problems successfully and cost effectively. <

My bashing the commercial vendors has more to do with experiencing their concept of service and value and comparing it to what I can do with OSS. The question of cost effectiveness is a very relative thing. There are some jobs _I_ would use a commercial product for. Where the fit is good and no integration is involved. And when I can get the job at a price where I can make a profit. But, when the complexity reaches a certain point, I can do the job better and cheaper with a more versatile platform with serious comms and much cheaper horsepower. It's very, very, difficult to beat the cost effectiveness of Linux on a PC where the fit is good and you need what Linux does well. I started in automation doing things that PLCs simply can't and integrating it with PLCs. It wasn't much of an epiphany to discover that it's drastically cheaper to add PLC functions to Linux than to buy enough special hardware for a PLC to even begin to do poorly what Linux does well. And the factor that no one seems to consider is the vast number of new applications and simplifications that are possible with the combination. Those things that are licensed per seat tend to make the best comparison, it's hard not to save money with OSS there.

> Your assertions about the
> failure of commercial enterprises directly contradict the experience
> of most people. It will be hard to gain traction that way. <

Once again, perception. The way things are done is always adequate until something better comes along. And I've not opined on the failure of commercial enterprises, although there does seem to be some shake out going on. It's wonderful for them, high margins, zero liability, an upgrade money machine that people can't opt out of, and very low expectations from their customer base. Far from failing, the vendors have all the advantages. It's the people who build the solutions who could be doing better. The status quo is fantastic for a few large corporations, and pretty tough for the rest of us at the moment. I suppose if people choose to ignore that cooperation and commoditization hold the most promise for better productivity and profitability there's not much hope of changing things. But there are always those who embrace change as the way to move forward. And there are always those who are left behind. One could easily think of that as a difference in traction.

If you couldn't use a better way of doing things about now, by all means, dance with them that brung ya. If you suspect you could do better, try doing things differently. 99% of the companies who had a good enough way of doing things are now forgotten.

Regards

cww

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

Really, totally agree with your reply...............actually look at
TCO, interesting concept....hmmmmmmmm

Basic business 101....again hmmmmmmmmmmmmmm

Dave

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...

The answer is not simple.

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.
Vladimir E. Zyubin mailto:zyubin@iae.nsk.su

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

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............

Your Friend:

Dave

Hi Dave

On July 20, 2003, Dave wrote:
> 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........

Again, that bipolar thinking. It's either buy it or build it all yourself. Not the practical area in between. If you have a dozen companies or entities or more cooperating, these arguments are altered significantly.

> 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)

But if you only have to fund a small fraction of the whole, or perhaps none at all, your TCO could very well be more attractive than commercial offerings. Just as dividing the cost between many customers makes shrinkwrap software work, sharing the development between many "customers" makes OSS work. And the end result is lower TCO, better fit and more supportable software with much less ongoing expense. I'm not a starry eyed idealist, I'm doing this because of the way the numbers work. There's a lot of work out there that simply won't happen with current pricing structures and profit distibution.

> 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...........

And if you own and can control your solutions, it almost completely eliminates the risk, not only will what you need will be around, but you won't get unpleasnt and costly surprises.

>> 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..............

Most of the better tools are invented by tool users, not necesarily by tool companies. You have a very, very, substantial investment in these tools before they are of any use to you. In fact, I dare say that users have a far greater investment in packaged tools than the tool companies. Shouldn't you get more in return? And how many times should you have to pay for the same tool and yet never own it?

> 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..................

I'm afraid the simplistic comparison breaks down around here. You can pick up any hammer and use it immediately. It doesn't cost you a mint to switch from Stanley to Plumb, You don't have to keep paying so your hammer keeps working. No one throws away your favorite hammer and makes you buy a new one with all kinds of sharp edges on the handle so you bleed every day. And you don't have to buy all the rest of your tools fron the same company as your hammer. And surely, no one would put up with this kind of crap, for a hammer :^) or anything but automation equipment.

So, it must not be just a hammer.

> 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
............

Somehow, I don't think maintaining the status quo and falling further and further behind is going to cure this. I don't care how hard you work with a file, the guy with a mill is going to beat you. Yeah, it's an OK file, and you know how to use it, and it's simple enough, but I'd advise learning to use better technology.

> My 2 cents............
>
> Your Friend:
>
> Dave

And yours

cww

I am an automation engineer for a large steel producer. 3 years ago, one of our other in-house engineers upgraded one of our older HMI systems with a visual basic application he wrote himself. Initially, everyone was very happy with the conversion, as he made very elaborate intuitive screens and provided feature-rich diagnostic and summary displays.

The problem is that he left the company, and now we have to support this system with no development tools. He always said "I do not need any development tools, aznd if I do, I can just write one." That was cool, for a bragging rights point of view, but not a very wise application approach for a 24x7 progressive manufacturer. Now whenever we add or modify mechanical and electrical systems, we have to do alot of in-house development, with staff who have very rare opportunity to keep those skills sharp.

Problem #2 is that we will have to retest all of it when we want to upgrade to Server2003 and a new ODBC database driver and if we want to move up to Visual Studio Net.

So I agree that a canned product with continuos development and support is the way to go. For around 9-10K per node, it is very much worth it.

I suggest Intellution iFix or Wonderware.

- Jerry Lavoie
Nucor Steel Corp.

Is it still Intellution? I saw that GE took that name of the building lately. Is Ifix supposed to be used in the discrete world or the process world and what about GE Cimplicity. I thought they were pushing Ifix for the process world and Cimplicity for the discrete world. Too much confusion for me. I am not sure about Wonderware either. Who are they going to be next year. If I were you I would stick to a company with consistancy so your support headaches will not be there when the person or team who wrote the SCADA for you bolts. The two I would go with are Siemens WinCC or Rockwell RSView. Not too sure about the latter either but at least they are improving. I would venture to say that you will see those two battling it out for #1 in a couple of years.

Ron

Hi,

You can use Siemens WinCC, its very flexible and suitable for your application along with very easy development/configuration, I have personally worked on many HMIs & SCADAs but you will get good support for WinCC.

If you need any further help you can contact me at
usman_latif74@hotmail.com

Regards,

Usman

Rufus -- It was.

Matt -- Amen.

Curt -- basic math -- nothing is 'free'

PetersonRA -- My point exactly.

Matt -- Amen again.

Batchelor -- it still not worth writing your own. leverage what has already been done.

and Dave. . . .It took a lot of words -- but you hit the nail on the head!!

JP

Basic summary of stuff that I have learnt is this:

- The programmer in me loves doing things my own way, the SCADA engineer in me cries when it sees someone else's 'custom code'.

- Off the shelf HMI stuff CAN save you 100's (or even 1000's) of lines of coding. The problem is understanding how it work. Black box techniques on figuring out a system is required at all times.

- While customers state that they want fully configured systems, reality is that they want the opposite EVERYTIME. The more you reveal via a touch panel - the more pain you bring yourself. If that is custom pain - your a masochist. Some people restore cars as a hobby - very few people build their own car from iron sand......