HMI Softwares

C
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
 
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
 
D

Donald Pittendrigh

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
 
R

Ralph Mackiewicz

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
 
M

Michael Griffin

<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
************************
 
C
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
 
J
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.
 
P
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
 
L
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
[email protected]

Regards,

Usman
 
S
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......
 
Top