Making an HMI with borland delphi


Thread Starter


how to make a HMI using borland delphi 7?

i am in researching and development division at my university, and now i was searching for thesis topic..
i got a topic to make HMI using borland delphi, can u elp me?

my contact:
[email protected]
Why Delphi (as opposed to some other language), what is the HMI supposed to do, and what sort of PLC will you be trying to talk to?

James Ingraham

This has so many issues I barely know where to start.

1) Are you (a) trying to write a one-off HMI for a specific task, (b) trying to create a framework for general HMI development in Delphi, ala Parijat Controlware's VB stuff, or (c) trying to create HMI builder & viewer software that would go up against something like Wonderware's InTouch? The three are very different goals.

2) Delphi? Really? I mean, Delphi is cool and all, and it was certainly a game-changing product when it came out, but it is very niche these days. I actually had to go to the Wikipedia entry to learn if it was still in use. I haven't heard anything about it in ages. Delphi 7, in particular, was released in 2002! That's 7 versions, 3 companies, and 9 years ago.

3) One of the things you'll notice about Delphi XE (the latest version) is that it has lots of buzz-wordy features like cloud deployment, gestures, etc. A Delphi 7 app would be really old-school. Where's the mobile version? The Web version? The enterprise integration? You're talking about a dead-end project. If you're going to do an HMI, you want something modern and flexible. M Griffin's MBLogic is a vastly more interesting take. He uses standard, open technologies like JavaScript and SVG. That's cool. It can run across platform's. It's scalable. It leverages lots of other technologies rather than having to re-invent the wheel for things like e.g. security.

4) Delphi is certainly capable of communicating with industrial equipment, but it won't necessarily be easy. A quick goggle search for "delphi opc" turned up a surprising number of hits that looked promising. Direct communication with say ProfiNet or EtherNet/IP looked a little less promising. At any rate, there's not a lot Delphi work going on in the industrial / process space, meaning there are a lot fewer resources than if you were using C++ or VB.Net.

5) Traditional programming languages aren't necessarily a great fit for HMIs. Connecting each widget to a data source can be a time-consuming and error-prone process. The symbol set is designed for business apps, not process abstractions. Of course, you can ultimately do whatever you want to, but you might have to put in a lot of work to get things lined up right. On the flip side, there are a ton features that won't be at all useful to you.

6) No one will want this. There's no track record for Delphi in the automation world, and none of the engineers, technicians, or operators are familiar with it. The trend has been AWAY from unique hand-coded applications and toward off-the-shelf solutions, usually from integrated suppliers like Emerson, Invensys, Siemens, Honeywell, or Rockwell Automation.

7) What's the value here? Sure it can be done, but why? There's not anything really new going on; HMIs on Windows in a "traditional" programming language have been done to death. There's nothing inherent about Delphi (especially 7) that makes it interesting. Who is your target audience? What's the need you're fulfilling?

I realize I'm being very negative here. I really feel like effort would be better spent elsewhere. Help out on MBLogic or pvbrowser, for example. Usually I close with "Hope that helps," but in this case, I think "Hope you find a different path" is a better fit.

-James Ingraham
Sage Automation, Inc.
In reply to James Ingraham: Thanks for the kind word about my project. University students have based projects on MBLogic (and HMIServer) in the past. One student for example sent me screen shots of a very nice looking simulation of a dairy which used HMIServer for the HMI.

As for Delphi, there are Modbus libraries for it including free ones. I don't know how many people are doing new projects with Delphi though, as opposed to just maintaining old ones. It's been at least 10 years since I've heard of anyone writing a new program using Delphi. There's no money in the compiler business anymore because the big platform owners (Microsoft, Apple, Oracle, IBM) don't care if their compilers make money (they use them to support sales of other more important software), and all the "cool" languages these days (Python, Ruby, Erlang, Javascript, Lua, Go) are free and open source anyway.

In reply to David: As James Ingraham has said, it might not be a bad idea to make your project at least sound a bit more cutting edge. Is your thesis topic about using existing software to do something or is it about creating something new in terms of software? That is, how much programming background do you have? A little bit? Quite a bit? What programming languages do you know something about? I can make some suggestions about what you could do, but I don't want to pitch something that is either off topic, too easy, or too challenging. There are lots of things you can do for zero cost.
Hi David,

Don't get too discouraged about the comments here about Delphi. The latest tools may be "cool" in some ways (I'm a fan of Python too) but many folks aren't very familiar with Delphi (or the closely related C++ Builder).

If there is something off-the-shelf that meets your needs then I would agree with the other comments that you should consider those options. But if you have Delphi experience and have reasons to use it don't be discouraged by the comments here.

Every heard of Skype? The Windows version is written in Delphi.

Ever heard of C#? The fellow who created most of C# is the same fellow who developed Turbo Pascal and Delphi. I guess I could turn things around and say I've been productively using a Win32 native version of C# (with Pascal syntax) since 1995! :) This page has a bit more information:

Maybe Delphi isn't used much in factory automation, but it is used a lot in many engineering fields with major data acquisition systems.

And Free Pascal and Lazarus offer a lot of native cross-platform options to those familiar with Delphi. Those free open-source tools are being used for significant real-world projects. Here are some testimonials:

Since Free Pascal is open-source it is easy to provide 2-3 MB zip files that contain the compiler, source code for a widget set, and everything needed to give it a test. The "EasyfpGUI" page at this educational project site shows how easy cross-platform coding can be:

Best regards,
Paul Breneman

for email address see:

curt wuollet

To do this in Delphi is truly and purely an academic exercise of the highest order. No easy cop-out with shoulders to stand on and all that. It should be nearly as rigorous as writing a language to do your HMI with. But even an academic exercise can do great good in a community where there is little illumination. Wouldn't it be better, socially, to write in a free and open language? It seems expending all that effort could further the cause of OSS in automation as well as your education. You might even gain a few points with the typically liberal profs.

I think that Paul Breneman has a point, in that we should try answering your question instead of saying what we would do in your position. Here's a few points.

1) Find out what protocol your HMI will need to use to talk to whatever it is your HMI will be talking to.

2) Find a driver for that protocol that you can use. If you don't have any money to spend, then forget OPC, as that's expensive. What you might really need to do is find a driver first and then let that decide what device your HMI will be able to talk to. There is a free Modbus/TCP driver for Delphi on SourceForge.

3) Your HMI will need to run in a fairly conventional event loop. Read data from the field device, update the screen with the data, write any data from the operator back to the field device, wait some period of time, and repeat. This is assuming that your HMI follows the normal relationship and is a client (master) rather than a server (slave).

4) Expect to spend a lot of time debugging the system. Design your system so that you can simulate the IO while you are writing and testing the software.
thanks for all the answers..
(sorry i've bad english language:))

so..using delphi for making HMI like wonderware is so hard,isn't it?

then how about using to make HMI like wonderware intouch?

any idea??

best regards,

electrical engineering student at Atma Jaya University in Indonesia
Back to your original question, 'i got a topic to make HMI using borland delphi, can u elp me?' You also mentioned VB.NET.

ActiveX Controls can be used in Delphi. To keep things fully managed in .NET you should consider using .NET components/controls.

Communications, instrumentation, and process visualization components are available for Delphi and .NET

Communications (A-B, Modbus, GE, Automation Direct, etc.):


Many components are runtime-free, but you'll need to review each product's license agreement to verify.

Whether you're using Delphi or VB to write it, there's a big difference between writing an HMI program for a single machine and writing a general purpose HMI package comparable to Wonderware. For the former, you're just writing a conventional program that happens to include the ability to communicate using industrial protocols. That is something that could take anywhere from a week to several months to write, depending on the features you implement.

Creating something comparable to Wonderware however would take years. Programs like Wonderware are a lot more than just another programming language. They provide large parts of the HMI application in a ready to use but still flexible form. They're not general purpose packages, so you wouldn't use Wonderware to do something like write a point of sale cash register program. It's focused on a very specific task, but it does that taks very well.

You're not going to create something comparable to Wonderware (that is, a program that can be used by other people to create custom HMI systems) in the time you probably have available for this project.

On the other hand, your original idea is not bad, provided you want to write a simple HMI for a specific machine. Somebody who was familiar with Wonderware could probably create the same program much faster than you could writing it in Delphi or VB. That is why HMI packages exists - they let you create HMI systems faster than you could using general purpose programming languages.

We should perhaps forget some of the suggestions made previously (including some of mine). A lot of people are looking at this from the perspective of their own knowledge, where they already know how to do something like this and are suggesting something that they would find challenging. You're starting without their experience, and are looking to learn how to do this.

If you're familiar with Delphi, then by all means go ahead and use it. The principles would apply to any programming language and you probably don't want to be spending the time learning a new programming language as part of this project. Switching to VB isn't going to gain you anything in that respect unless you happen to be more familiar with it than you are with Delphi.

To start from the basics, I assume you are familiar with the idea of an event loop in a GUI program? The user clicks on a button or enters text into a box and your event loop is activated and calls a handler to do something.

Most GUI toolkits also have some sort of time based call-back, where you can ask for a function to be called after a set period of time (or in some cases, called every 'x' seconds). Sometimes this works through the event loop, or sometimes not, depending on the GUI toolkit. What you would want is to have a function called every second or so which would poll the PLC (or whatever) for data, and use that to update the screen. For user input you can either send it immediately when they click on a button (or whatever), or you can buffer it up to send it as part of the next regular communications cycle.

The same principle by the way also applies to a lot of other programs besides HMIs. Automated production test equipment can do the same thing, except you are doing more than just updating the screen. The basic idea is that instead of just reacting to operator events (mouse clicks, key presses), you are using the time based call-back to wake the program up and do something even without any operator input.

You could by the way decide that your project is to create an automated test system for an imaginary production process and have quite a realistic project, as languages such as Delphi, VB, or Python are often used to create these.
If considering VB.NET, take a look at AdvancedHMI. It is a set of tools, including drivers, that are designed to make HMI building as easy, if not easier than the common off the shelf solutions. Since it is based on VB.NET, anyone with some skills in the language can extend and add onto it.

You can find it by Googling AdvancedHMI
I'm an automation expert and a programmer analyst (30+ years). I'm a Delphi programmer and believe it is still the best RAD development tool period (I've tried many). There are libraries for VCL objects to easily create HMI's (button, gauges, trends, etc). There are a number of libraries for PLC comm's. Can it be done ...absolutely. Should it be done...depends.

If need to develop a unique, simple and cheap solution that only you are going to maintain then it may make sense. If you are building a system that tradesmen or engineers will inherit and maintain or if the application is complex then I would use an commercial HMI package such as Wonderware. The big HMI packages allow you to do the complex huge tasks easily.
Delphi is still being used, though it is now marketed under CodeGear, i.e.

lots of help from the players on hand from the Borland days, and affordable. Go for it, what you learn under pascal/c++ is easily transported to other systems.
I use Delphi almost exclusively and that has included several automation projects requiring Modbus, Ethernet, RS-485, and even running an FTIR via OLE/ActiveX. It is a very capable programming platform, and seeing as one can develop new components, such as fancy buttons, LEDs, and analog gauges, fairly easily, you should be able to put something nice together. You can also write threaded applications, and drag-and-drop apps, plus you have access to the all of Windows resources, and the language is rich, and the Delphi IDE is by far better than WindowMaker.

I'm assuming you are not talking about writing something like Wonderware's WindowMaker, but rather the runtime version of your HMI app.
Delphi (especially 7) is as good as any new language. java and all those new language use the dynamic allocation used by Delphi. I use Delphi to create my automation project using AB, WAGO, TURCK & AUTOMATIONDIRECT plc's with modbus rs232 & tcp, df1 & ethernet/ip, DB connection with Oracle & SQL, and about the screens that I can made. I like to use opengl to create 3D robots or geometric shapes that really like to everyone. my applications run in windows xp, 7 & 8, and the main thing why you have to use Delphi is because you can create multithread applications very easily.
> Delphi (especially 7) is as good as any new language.

Had to read the date twice. April 17, 2013, correct?
So I'm not alone, there are other living beings still using that evergreen Delphi version ;-)
Delphi has been used in some interesting engineering stuff!

On 26-Sep-2004 Kristofer Skaug wrote: "You want mission critical? Consider the infrastructure for the Rosetta comet chaser, that will need to stay operational until 2014-2015."

That is in the news a lot today (10-Nov-2014).

Over ten years ago, Kristofer Skaug wrote in a post in delphi.non-technical:

"I would like to thank the Borland Delphi team for giving me the ideal tool to create ground test equipment software in support of the Rosetta comet-chaser mission, which launched successfully today. I can only guess that without Delphi, the years of work I put into that project would’ve been considerably less fun!"

If you want to read some of the more interesting technical programming talk check this out: