A bit of a rant here.

We got an RFQ to do some ongoing field support and modifications to an existing control system. It has a SLC5/05 and an HMI.

Further investigation of the HMI revealed it is a hacked together system of a bunch of off the shelf software products tied together with a VB program.

How the heck is anyone supposed to support something like that? It would be cheaper to rip it out and start over than to spend the 2-4 weeks it will take to become proficient in using what was done, assuming I can even get source code and that there are legal software licenses in place.

If you are an end user, beware of these kind of things. The low up front price can be attractive but the long term costs can be staggering, especially if the guy that put it all together in his basement goes out of business.

--
Bob
http://ilbob.blogspot.com/

 

Are you really ranting about poor engineering, or non off-the-shelf systems? The first is difficult to avoid, even using standard software. I admit using off-the-shelf software is most times more efficient and thus cheaper, but it also comes with it's own set of issues. Custom stuff is often somewhere interesting stuff may happen.

I would in many instances recommend the custom stuff if the total system is simple and the programmers know what they are doing. My five cents.

 

Now and then I am the guy who has to tell someone that the stuff they bought 4 or 5 years ago is not supported and probably is not supportable by anyone now that the guy that did it is out of business.

Even where more or less off the shelf building blocks are used, you often end up with something that would take me 2 or 3 weeks of work just to figure out and get up to speed on. And why would I want to do that unless the company gets paid for it.

Something like IFix, Wonderware or RSView has a clear upgrade path and on going support and plenty of talent to work on it. The stuff someone came up with in his basement never does, despite saving a few bucks upfront.

What do these people do when their home brew systems fail and there is no support available at all?

--
Bob
http://ilbob.blogspot.com/

 

Oh my, Yes!

It's much better to pay a staggering cost up front ($20k units come to mind), for a hacked together, buggy, primitive, bunch of crap that some guys came up with in their lab that's tied together with secret protocols and VB after the company has declared it obsolete and disavows any knowledge of it and do so without any source. You are then offered a change to pay another, more staggering cost and spend a few weeks to do it all again. But it must be better, because people do it all the time. So there's no point in warning them. I think a lot more of my gentle readers have seen this scenario.

Regards
cww

 

Do you think that a hacked together HMI from an obsolete SCADA system is any better? Maybe it is, not sure...

If someone were to use VB for an HMI, they really should provide source code. I would try to avoid third party components also, except maybe for proprietary PLC drivers.

 

You are talking about 800xA no?

 

What is "Home brew HMI" ?

There are plenty of commercial HMI packages.
But only some are popular.
Do you call the less well known packages "Home brew HMI" ?

A "Home brew HMI" may be a normal application written in a well known high level programming language. What is better for the future, if you have such a "Home brew HMI" with all the sources or if you have build on top of a "closed source" HMI software that reaches the end of it's life cycle ?

What about "open source" HMI frameworks ?
An example is our http://pvbrowser.org

What about web based HMI with Web 2.0 technology ?
I'm sure our solution is more easy and much more dynamic/faster.

In the recent past tablet computers and smartphones became popular.
Does your favorite HMI support these devices ?
Does your favorite HMI run on Windows only ?

Yours:
http://pvbrowser.org

 

I think any hacked together system is a bad idea. However, a hacked together system that has long term support and a relatively straight forward upgrade and replacement path is more tolerable, given that everything will eventually fail.

The problem I have with the stuff coming out of people's basements is that it is reliant on that single person.

If I buy something from a company that has been around for some time and will likely be around down the road, I have at least a good chance that there will be some level of support down the road.

The reality is that virtually all HMIs are and will continue to be hacked together. It is pretty much unavoidable whether it is some guy in his basement or AB in their R&D center in China. The difference is when the guy in his basement goes defunct in a few years, and that is what will happen, the people who use his product are just screwed totally. The guys that used AB's product are just screwed out of some money.

 

Bob,

I generally agree with your statement and see your point, but there are times when you can't just use one of the top tier automation vendors. Sometimes you need to use a PC or embedded PC to get added functionality with database systems or other complex setups and visualizations.

I've done HMIs using C#.NET for systems that didn't have a supported driver for a commercial HMI (Robots and certain motion contollers). I'd be willing to bet that my program running C#.NET/Winforms and interfacing to the device with dead simple TCP sockets will give many commercial HMIs a run for their money in terms of support. If the programmer insists on using bleeding edge tech and linking in 3rd party controls then it can get sketchy as these slowly become obsolete.

I've also supported systems that were seemingly hacked together and have all sorts of dependencies, like compiling in the ancient Visual C++ 6.0 IDE because some interdependent library can't be upgraded on a newer platform, so I know where you are coming from.

I think it all boils down to your comfort level and the expertise of your employees, how many machines you are deploying, etc.

KEJR

 

And I might point out that those collections of off the shelf apps glued together are often demanded by the IT people so they can actually do something with the data rather than have it trapped in the proprietary system.

Regards
cww

 

There is however a route to less hacked HMI software. When developers aren't forced to use whatever MS provides that's closest to something usable for their purposes. And when they can actually know what is behind the APIs and everything isn't shrink wrapped you can interface properly rather that get out the glue. And it can actually be documented and shared without an NDA. It can then be supported by any competent programmer.

Regards
cww

 

I tend to agree with you on this one Curt.

Open standards are really the way to go for this kind of application. I'm almost to the point where I will pick one product over another if it happens to support a simple ASCII TCP socket connection vs. "We have our own ActiveX control!".

Others may disagree.

KEJR

 

Some of the worst kludges come about because the producer is a closed binary blob.

If the only output is Sanskrit, you're gonna write a Sanskrit-whatever converter, if it's even possible to RE it. MOST interfacing is like this to some degree in the shrinkwrap world. It's very seldom made easy to _use_ _YOUR_ data. They cheerfully offer to let you pay for another binary blob to convert it so it's now trapped in the windows
shrinkwrap world.

Regards
cww

 

Or you could go with an "open standards" system like Ignition that encourages the use of open protocols and standard SQL databases...

http://www.inductiveautomation.com/scada-software/

I like all the insight to "homemade" proprietary systems, BTW

----
Nathan Boeger
http://notanotherindustrialblog.blogspot.com

 

Nathan Boeger wrote:
> Or you could go with an "open standards" system like ...

I agree with you.
Standards like SQL,SVG,JPG,PNG,OpenGL,HTML/CSS/WebKit,TCP/IP,IPv4/IPv6,ssh,XML,C/C++
should be used.

And the software should be portable (Win/Mac/Linux/Android/..)

Since our software is based on Qt it is relatively easy to do so.
All of the above standards can be used when developing on top of Qt.

PS: I think .NET is not a standard because it is tied to Windows (yes i know about Mono).