Looking for input from anyone who has written their own HMI in VB or VC++. I have extensive experience with RSVIew, CiTect, and Factory Link, and have dabbled with several others. Now I have an OEM application where the customer does not want to pay annual licensing fees and the associated headaches. The customer wants to own the HMI code, even if it costs a bit more up front. There is a potential for royalties for each unit sold. Has anyone here done such a project and what was your experience with it? Where did you go for symbols and active-x components? The less I have to create certain items from scratch the better. I looked at the products offered by softwaretoolbox.com. If you have used these what do you think of them?

 

We have been developing OEM App's for seome customers in Mexico, who won't pay for licence Fees.
Our development involves:

Recipe Management/Inventory Control (Access, DAO'S ADO'S)
Real Time and Historical Trending.
OPC based Integration.
Historic Alarms.
Analog Control.
Voice Modem Alarm Messaging.

I Think it is enough.

If you think we can be of your assistance, give us a chance to send you some sample screenshots.

direct e-mail.

[email protected]

 

I've developed several HMI packages. I've also worked with most of the major packages available now. I have done many applications in VB and VBA to interface to PLCs and RTUs.

I can't discuss much publicly about the project that I have worked on, but in general developing your own HMI will cost considerably more in the long run. Think about how many copies one of the current vendors must sell and how much each copy cost before they start to make a profit. You have to remember that after the development cost there is the cost of support. Another consideration is the user base. With a major vendor package, there are many people using it and they will be finding problem, which hopefully will be fixed or at least a work around will be available.

If you have any other questions, please contact me.

Lewis Bodden [email protected]

 

A better tool than VB for this kind of work can be Delphi. You get a real exe file (no dll's) to ship for a basic system and it is made for interface to real database backends if you want data logging in addition to a pretty face.

You can use ActiveX components if you like but there are many tools available native to Delphi. Check out http://www.torry.net for some examples of what is available. If your customer is interested in Linux as an OS (it is still free you know) there is a flavor of Delphi for Linux called Kylix. We have used both extensively for HMI applications where we wanted to reduce the cost to the user for license fees, etc.

Feel free to contact me if you have more questions. I am [email protected]

Regards,
Jerry Robertson

 

Take a look at a tool called DataViews from GE Fanuc.

 

STB products are good. IOCOMP instrumentation pak is good as well as the other ActiveX products.

Drivers can be fund in many spots including STB and Automated Solutions, Parajat, and others

I have used driver stuff from AS with good success. Many ActiveX components available of the web too.

Good alternative.

Cheers from: Jeremy Pollard, CET The Crazy Canuckian! Integration and Automation Training, Consulting, and Software

Control Design Column http://www.linkpath.com/index2gisufrm.php3?tempCode=CON&onlineIssue=true&mem _sess=d8734688500ceb501ce5610f4a530004&speed=high

On The Web - http://www.tsuonline.com

PLCopen North America - [email protected] http://www.PLCopen.org

Please note Address Change..............

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0 705.739.7155 Cell # 705.725.3579

 

Hello,

See http://www.vhmiautomation.com for a full HMI source code with no licensing fees or royalties. It is written in VB6. It will get you started.

Regards,

Phil

 

You should really check out Parijat Controlware at http://www.parijat.com/ They do VB-base HMI. I have never actually used their stuff, by I have always been impressed with their technical people that I have talked to.

-James Ingraham
Sage Automation, Inc.

 

Hi Lewis. Remember that there's a difference between developing the development environment and the application itself.

In either case you have to support the application. Just some thoughts

Cheers from: Jeremy Pollard, CET The Crazy Canuckian!
Integration and Automation Training, Consulting, and Software

Control Design Column
http://www.linkpath.com/index2gisufrm.php3?tempCode=CON&onlineIssue=true&mem
_sess=d8734688500ceb501ce5610f4a530004&speed=high

On The Web - http://www.tsuonline.com

PLCopen North America - [email protected]
http://www.PLCopen.org

 

IMO, the original question is more about vendor-independancy.

From end users' point of view the current situation looks like a train of endless upgrades and aimless expences...

--
Best regards.
Vladimir E. Zyubin mailto:[email protected]

 

Sorry... a couple of words after.

"IMO, the original question is more about vendor-independancy.

>From end users' point of view the current situation looks like a train of endless upgrades and aimless expences..."

And here I personaly see two things - an instrument (program to create HMI, kinda intouch, etc.) and a final product (user interface, UI, the concrete module of a concrete control system)

No need to create the instrument everytime, but everytime we need create (or modificate at least) the final product (UI).

So, one of the approaches could be:
a VB-library and a methodology for UI creation.

These two components allow us create vendor-independant UI.

Really I do not think VB is good idea for the language, but maybe just because I am fond of pure C. ;-)

etc.

Regards, Vladimir

 

IMHO this would be one of the most beneficial areas for a properly crafted OSS system, if the (artificial) interface problems can be solved. If one achieved reasonable uptake there would be widgets for almost any purpose and it would be extensible. None of the work would go to waste if contributed.

Regards
cww

 

Although Visual Basic has lots of output formatting options, it does a rather poor job at getting user input so you would be wise to either find a good set of third party input controls, or to spend a lot of time writing your own.

For example, VB has a "text box", but no "numeric box" which is astonishing when you consider what the product was intended for. A common problem seems to be having the program crash when someone enters a character when the program was expecting a number (it is common enough to be a classic VB text book example, and I've seen it happen as well). Writing user friendly numeric entry routines for VB which are truly bullet proof is not trivial, and you would have to be very familiar with all the quirks in VB (of which there are many) to make sure all the user interaction possibilities were covered.

The very weak data typing in VB adds to the problem as well. If you are not very careful, VB will automatically convert unexpected data into a different type than you intended. For example, you may declare a variable as an integer, but VB will change the variable to a string type if necessary, upon which you may find yourself dividing a number by a string - and crash goes VB. This means it is very important to filter the data before it gets to a vulnerable part of your program. VB is really quite primitive when it comes to data typing and facilities for structuring data.

I don't have a recommendation on a good third party library, but I hope the above gives you some things to think about when selecting one.

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

 

On February 5, 2003 02:10 am, Curt Wuollet wrote: <clip>
> IMHO this would be one of the most beneficial areas for a properly crafted
> OSS system, if the (artificial) interface problems can be solved. If one
> achieved reasonable uptake there would be widgets for almost any purpose
> and it would be extensible. None of the work would go to waste if
> contributed.
<clip>

You would have to target a particular GUI builder to add the widgets into wouldn't you? Actually, there is probably more demand for this sort of thing for test equipment than for conventional MMI systems. That sort of market also tends to be more computer literate (I assume you weren't suggesting targetting Visual Basic). There is a fair bit of overlap in the needs of both markets though.

This however brings up a point which may be of some interest to the originator of this discussion. Depending upon the type of machine and MMI you were planning on constructing, test and lab oriented widgets may be more useful than traditional process industry MMI ones. Have a look at National Instruments Component Works, and any similar products from their competitors. These generally include boxes for display, data input, push buttons, indicator lights, strip charts, graphs, bar indicators, etc.

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

 

Hi Michael

> From: Michael Griffin
> To: [email protected]
> Subject: Re: HMI: Roll your own HMI
>
> On February 5, 2003 02:10 am, Curt Wuollet wrote:
> <clip>
>
>>IMHO this would be one of the most beneficial areas for a properly crafted
>>OSS system, if the (artificial) interface problems can be solved. If one
>>achieved reasonable uptake there would be widgets for almost any purpose
>>and it would be extensible. None of the work would go to waste if
>>contributed.
>
> <clip>
>
> You would have to target a particular GUI builder to add the widgets into
> wouldn't you? Actually, there is probably more demand for this sort of thing
> for test equipment than for conventional MMI systems. That sort of market
> also tends to be more computer literate (I assume you weren't suggesting
> targetting Visual Basic). There is a fair bit of overlap in the needs of both
> markets though.

Thank you for disassociating me from "VB for Automation", I'll sleep better. No, I was thinking of Glade or perhaps python with the right widgets. But I'm curious why you see this as more towards test and measurement than MMI's. People seem to do well with canned drag and drop MMI products even when they have to force their application to fit the rather limited options. Why wouldn't a more universal MMI with more and varied scope do as well? Not everyone has to be a contributor, most folks could just use it like the existing products. And it would be a blessing to be able to know (or possibly tweak) how the doodads work.

> This however brings up a point which may be of some interest to the
> originator of this discussion. Depending upon the type of machine and MMI you
> were planning on constructing, test and lab oriented widgets may be more
> useful than traditional process industry MMI ones. Have a look at National
> Instruments Component Works, and any similar products from their competitors.
> These generally include boxes for display, data input, push buttons,
> indicator lights, strip charts, graphs, bar indicators, etc.

Imagine a free product, usable anywhere, with a much better selection of widgets. A whole plant with consistant MMI on inexpensive commodity panel PC's or even normal Linux boxen. Lotsa bucks to be saved if the product can be made as easy to apply. And I don't see why it couldn't.

Regards

cww

 

Curt Wuollet and Michael Griffin have been discussing "free" HMIs. As someone who makes a living by selling packages that are not free, of course I have, perhaps, another view. As ever, the best solution depends on many factors. The desire for process improvement is one possible requirement. This is achieved not just by giving the operator a better interface to work through, but also by giving maintenance engineers and process engineers historical data that actually tells them what has gone on and is going on in the system. This usually means data rates that are considerably faster than the standard historians can manage and often data that is all over the place and difficult to gather, let alone plot on one graph.

And then there is maintainability! If the system is to last, then it needs to be maintainable. We have all seen systems whose lives have been cut short because of this and certainly I do not want to be responsible for the organization who trusted me to provide them with a long-lived system having to shell out more capital dollars prematurely. Too many custom systems are maintainable for as long as the author is still available. This is bad system engineering.

The systems we are talking about should generally develop in further capability through their lives and last, perhaps, 15-20 years. Of course, there will be computer upgrades in that time, but hardware is cheap, software packages are cheap, it is the time and expertize that turns packages into custom systems that takes the time and is often 90-95% of the cost. How many hours will you work for the price of a good PC?

I would suggest that integrated products with good technical support can save their costs many times over, even just during installation, compared to the roll-your-own approach.

Peter

Peter Clout
Vista Control Systems, Inc.
176 Central Park Square
Los Alamos, NM 87544-4031
(505) 662-2484
FAX (505) 662-3956
[email protected]
http://www.vista-control.com

 

On February 9, 2003 12:29 am, Curt Wuollet wrote:
<clip>
> But I'm curious why you see this as more towards test and
> measurement than MMI's. People seem to do well with canned drag and drop
> MMI products even when they have to force their application to fit the
> rather limited options. Why wouldn't a more universal MMI with more and
> varied scope do as well? Not everyone has to be a contributor, most folks
> could just use it like the existing products. And it would be a blessing to
> be able to know (or possibly tweak) how the doodads work.
<clip>

I believe I did say there was quite a bit of overlap in the two markets. An "MMI system" though can be many things. Many (perhaps most) of the people who are using "WinCC" or similar products though want more than just a GUI builder. A set of widgets alone wouldn't do what they want, and so wouldn't be a direct competitor to these products.

However, for people writing test and measurement systems, a set of GUI widgets is exactly what they want for the MMI aspect of their application. Their problem is that the standard GUI widgets which come with typical general purpose programming packages (e.g. VB) are not enough. They want different push buttons, indicator lights, strip charts, graphs, bar indicators, etc. They also want better user input options (like a "numeric box" instead of just a "text box").

This is not however "typical" for production machinery. Very little of this market is served by custom MMI applications which run on a PC (as opposed to special operator panel hardware). Keep in mind that a widget set alone is *not* comparable to what Citec or WinCC provides. This is why I think there is a bigger market for a just a widget set in test systems than in ordinary production machinery.

Test systems are also often written by people who have more knowledge of computers and software development and would be more inclined to use something which didn't come pre-packaged for them. However, the point may be moot, as I did mention that the most of the same widgets can be of use to both markets (which is why I suggested that the originator of this discussion have a look at what test software companies offer).

I think that someone did propose an open source project for an MMI widget set called ";Graphite" several years ago. However, I don't believe that he actually pursued it to the point of writing any software. If anyone is looking for a project to keep themselves busy, the field is open.

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

 

I just started to write our MMI using GTK+.
Originaly our MMIs were written with curses.
But GTK+ will allow us to do some more diagnostics on the screen (and make it pretty).
I am in initial stages how to best port GTK+ libraries to our existing code with minimum frustration.

 

On February 10, 2003 01:46 am, Peter Clout wrote: <clip>
> Curt Wuollet and Michael Griffin have been discussing "free" HMIs. As
> someone who makes a living by selling packages that are not free, of course
> I have, perhaps, another view.

We haven't been discussing "free MMI" systems in the sense you are speaking of. We (or at least I) have been talking about GUI widgets - quite a different thing on quite a different scale from process industry "MMI systems".

The discussion started off with someone looking for a recommendation on a good GUI widget set for a special application in a conventional programming language (alas - I don't think he ever got a straight answer from anyone). Data historians and large scale systems developing over decades were never part of the discussion.

An "MMI" can be something as simple as a pilot light or a push button. Perhaps you ought to think of a different name for what you sell. The actual "MMI" bit of it is only part of the story.

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

 

On February 11, 2003 12:29 am, Rokicki, Andrew wrote: <clip>
> I just started to write our MMI using GTK+.
> Originaly our MMIs were written with curses.
> But GTK+ will allow us to do some more diagnostics on the screen (and make
> it pretty). I am in initial stages how to best port GTK+ libraries to our
> existing code with minimum frustration.
<clip>

GTK+ will certainly look spiffy. However, I suspect that you will need a complete re-write of the operator interface portion of your code to accomplish what you want. That's not surprising, as the reason you wanted to change was to improve it.

I'm not familiar with what sort of GUI builders (or screen painters, or whatever you want to call them) are available for GTK+. KDE now has K-Develop, which is an entire IDE. I've also been doing some preliminary research into using TK and Tix, which is another alternative. However, as you said, you are using GTK+ so this isn't reall very relevant.

A couple of days ago I did an analysis of an existing test system application which I am looking at updating. I counted the lines of 'C' code and classified them according to function. Approximately 40% was for operator interface purposes. Only about 25% was directly involved in acquring data and crunching numbers (there is some very intensive math involved).

This application by the way used a very good (and expensive) commercial GUI builder to reduce the work involved. The 40% figure only counts the human generated code - not the automatically generated GUI code and constant declarations. I suspect that in more typical systems, the proportion of operator interface code is even higher.

What this means is that it is worth while doing a good deal of research into how to create the MMI portion of the program. This is often an area where the amount of work involved is greatly under estimated.

I would by the way be interested in hearing how your work with GTK+ turns out.

--

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