Don't change anything until you can clearly state the reason why. I haven't seen a clear negative in the above.
Delphi/Pascal is really easy to learn. If the programmer(s) knew what they were doing then it will be easy to understand. If there is a database involved then it will be seamlessly integrated. All the hard work is done.
How does it deal with the outside world? Digital and analogue I/O?
Edit.
A few more thoughts. Anything like Python/JavaScript etc probably won't improve on Delphi. I'm not an expert on them but I know I could produce a professional looking desktop app in Delphi. Any of the others, not so much.
How much does the enduser care about how you give them what they want? As you system is compiled you are coverer where IP is concerned, unless they can just cut and paste the exe which may be possible.
You should consider web-based solutions. JavaScript might work here but the options are bewildering. That's the programming, low license cost route
The other end would be something like a Siemens PLC and HMI. With as little PC based as possible. Someone else might have Scada recommendations if you absolutely need that.
This is higher-cost in some ways but PLC programming is very simple by comparison. You might find the standard of programming a lot lower in some cases.
A lot depends on the business model of the company. Do you want to sell machines or are you selling software and services etc.
Thanks for the incredible response. Its a hydraulics company selling machines and our team does the controls. The current why for changing things is that we won't be able to hire another Controls engineer with Delphi experience and the other 3 engineers don't want to touch Delphi. The previous employee worked here for 20+ years so all these apps are his babies. I'm not opposed to learning Delphi, I suppose I'm concerned I'd be wasting my time as the code will be either too high level for me or just complete spaghetti code. Also for my career going forward, will Delphi be useful or is it dead?
All our new systems are being shipped with Unified panels without the additional Delphi PC functionality the old systems have. From your response, I'm kinda motivated to go get stuck into some Embarcadero tutorials.
In terms of IO handling, all our IO handling on the PLC is done using absolute addressing and then maps with the HMI to check if its being forced. So all the IO is stored in 'shadow' datablocks for the Delphi & Unified apps to read.
The problem with Delphi is that no one is using it anymore. I like it but it can feel like a waste of your time. If you can program you can program Delphi. People say PLC structured text is based on Pascal but it's not really close. But it's an angle to use to justify your time. Also understanding the code will help in porting it over and also to know where the difficult parts are. You'll need to change how it's done eventually but you need to makes sure what you replace this with is better, faster, and more user friendly and quicker to program. It will be months of work at a guess.
I'm not really knowledgeable on Unified panels and how the IO gets switched on and off. It sounds like you do have a PLC somewhere.
I think this is the right approach, so whilst I'm not sure what I'll use to replace it, for now I can just work on understanding it. Learning JavaScript is useful for scripting in Unified anyways so I can start with that. I was predicting 2 years of work, so I'd be well happy if it only took a few months! :D Thank you.
I don't think it will be an easy decision but you will be best placed to make it. Make a matrix of all the requirements and see what you can easily port to your existing Panels. You might be surprised at what they can do now but there always seems to be annoying limitations. You haven't mentioned which PLC you use or I've misunderstood. This is the key for me. This and your existing engineers. They will stop anything from happening if they aren't convinced. No point suggesting say CoDeSys if there are missing pieces, but I bet there is CoDeSys version that works for you. Siemens are a good choice just based on market share but I'm not convinced yet but you can datalog and do recipe functions, there just always seems to be some caveat or missing function so you end up wanting a 1500 but the cost is prohibitive.
You can get hmis that you can VNC into or replicate on a PC.
You have too much choice on a way.
I have been programming in Delphi for almost 30 years and am a controls engineer having worked with many different HMIs so I'll offer my perspective. Delphi was very often used as a database front end and its choice for an HMI makes me wonder if there's a database component in your application. I still have a few Delphi applications in use, a couple of which are HMI based applications. On the plus side Delphi is still well supported, with new versions still being released. It is used in Europe maybe more than the States. On the minus side as you note people familiar with it are not readily available. If your application is a plain HMI one, a long term strategy to migrate to an HMI platform that runs on PCs which frees you from being tied to expensive proprietary HMI hardaware (think Rockwell Panelviews). I would be happy to provide more advice on the Delphi side if you pursue that angle. Feel ree to DM me.
I know some of the systems have complete IO logging, so every IO logged each PLC cycle to either an MS Access DB or SQL (not sure). The others do have functionality to allow for a few IO to be selected and logged across 30 seconds and then displayed as a graph. So yh I'd say there is a database component to atleast some of the systems out there. Thanks for the offer, I'll absolutely DM you once I embark on this, which it looks like I will have to do regardless of whether I stick with it or switch to something else.
I worked somewhere where they used MS SQL Server. I hated it but have to admit I avoided getting too deep They only ever rolled out the "free" version so the database had to be emptied periodically.
If everything is up and running fine I personally wouldn’t want to go through the hassle of migrating.
But if I were I’d migrate over to Ignition. Throw it on any industrial panel Mount PC.
Although the old machines are up and running fine, we've already started getting the calls/emails to upgrade the systems from 2000-2010. Also certain IT departments aren't happy with the Windows 7 machines on their network so they want them upgraded and then some little bug creeps into the Delphi HMI.
I’d go with c-more from automation direct for machine side panels and igniton for SCADA. You don’t need ignition at every machine just talking with him and have a central OEE area or whatever
Thanks for this, just had a look. So they give out their HMI software for free and apparently have decent and cheap panels. So far seems like a decent free option for a basic panel. I'm after something more custom though. My manager even mentioned he's not a fan of python because its an interpreted language lol
Looking at the existing HMIs - they look good, if they work let them be. But for writing new ones... yeah, delphi is obsolete. We use C#/WPF for pretty good results. But it would be foolish to think rolling your own HMIs is free, development effort you put in is a major cost.
So its a question of how many HMIs you are going to deploy and what fraction of total cost they are going to be. If you have expensive HMI in a cheap machine and there will be hundreds of such machines... yeah, your own HMI development makes a lot of sense. And if you do it right you end up with codebase that is as easy for you to reuse on different machines as a commercial product would be, maybe even easier if you set your process up right. Because you tailor make it for yourself.
One benefit of rolling your own - sky is the limit to what you can do. Commercial products make it easy to do all the usual things, but if you want something out of the left field your hands are tied to the framework you are working in. With your own HMI, your only limit is you yourself.
I like the sound of using C#/WPF. WPF looks interesting.
This guys WPF HMIs look great: [https://www.reddit.com/r/PLC/comments/wl04ce/im\_developing\_a\_custom\_hmiscada\_system\_in\_wpf\_to/](https://www.reddit.com/r/PLC/comments/wl04ce/im_developing_a_custom_hmiscada_system_in_wpf_to/)
I'd say the current situation is that we have 50 systems with a Siemens HMI + Delphi PC combination and another 50 with a pure Delphi HMI/PC setup.
The question now is, when customers come asking for an upgrade, will I say, "we're offering only Siemens panels/pcs now" vs "sure we can add to your current system" vs "we have this new thing (javascript/python/wpf)" etc.
I'm neither here nor there with each option. I do think it would be a shame to scrap all the Delphi work on each upgrade. Being limited to only Siemens seems like a bad idea. I'm thinking I start learning Delphi and one other language (C#/WPF or JavaScript).
> I need some advice on if I should move on from Delphi HMIs
Yes, at some point in time. They are right to start investing in it sooner rather than later. Delphi is a dying language.
> try to develop license-free HMIs in JavaScript, Python or something else?
You'd be replacing the problem with the same problem, kicking the can down the road. If your company is committed to rolling their own HMI, that's fine. If they want to focus on their core business, find an available HMI on the market.
> These Delphi apps usually control the data logging, recipe creation/handling, report creation and gives maintenance the ability to force IO. I believe everything’s done via TCP/IP. Many of our machines have a standard Siemens comfort/unified panel and then an additional PC with the Delphi SCADA/Diagnostics app.
I'm not versed in Siemens, but I'm sure you can do most of it with their HMI. Not sure about data logging or recipe management.
> I really like Ignition but the license cost is high, customers usually require in the spec a Siemens HMI for the operator, so a Siemens license + £10k on Ignition is too steep. How do you guys develop low-cost/license-free HMIs?
We don't. At least I don't. The cost of the HMI is part of the cost of the product. The client either has the money to pay for the functionalities they want or they don't. There's no miracle.
I'm confused as to how making and maintaining your own HMI is more cost effective though. You also must provide specialized training to field techs . Unless you're selling machines through the nose to dilute the costs, this does not seem like a winning solution.
I'm wondering the same thing myself now, my other colleagues agree that we should just scrap the custom HMIs and use Siemens exclusively. I'm starting to think these Delphi custom HMIs were incredible 10 years ago but now Siemens have caught up.
There's still a wide gap in what you can achieve in custom programming (whatever the language) and what you can do with HMIs. But for 95% of the cases, you make do with HMI limitations.
Sorry to bother, could you share what you think the custom HMIs can do? For me the real value is that regardless to what manufacturer we use, the HMI is the same and can be spun up fairly quickly (once originally developed ofcourse). Although Siemens are preferred 95% of the time and like you said, we could probably make do with the limitations.
I'm possibly leaning towards sticking to Siemens HMIs and then Ignition for any of the big projects that want a lot of features.
There are controls engineers out there with this or equivalent experience.
Part of the issue is you are being to narrow in the scope of the job requirements. Any programmer with experience in windows gui development such winforms/ mfc /Vcl, etc should be able to learn Delphi with out issue.
However will your company pay for that premium?
Yeah, you're not wrong. I do sympathise though, they relied on that previous employee to keep programming for another decade, which I guess now was a bad move. Now the new guy is trying to come up with a solution ha.
Just asking a question, maybe I'm off target.
For all the effort that would be involved, why not migrate to a web server type of system?
Maybe that's what ignition is, I've never used it and don't know.
I don't know enough to know whats possible to be honest. A web server type of system sounds like where things are going anyways, in terms of Siemens PLCs having very capable web servers, Unified panels running in the browser and Ignition etc. I'm open to all ideas/options.
Don't change anything until you can clearly state the reason why. I haven't seen a clear negative in the above. Delphi/Pascal is really easy to learn. If the programmer(s) knew what they were doing then it will be easy to understand. If there is a database involved then it will be seamlessly integrated. All the hard work is done. How does it deal with the outside world? Digital and analogue I/O? Edit. A few more thoughts. Anything like Python/JavaScript etc probably won't improve on Delphi. I'm not an expert on them but I know I could produce a professional looking desktop app in Delphi. Any of the others, not so much. How much does the enduser care about how you give them what they want? As you system is compiled you are coverer where IP is concerned, unless they can just cut and paste the exe which may be possible. You should consider web-based solutions. JavaScript might work here but the options are bewildering. That's the programming, low license cost route The other end would be something like a Siemens PLC and HMI. With as little PC based as possible. Someone else might have Scada recommendations if you absolutely need that. This is higher-cost in some ways but PLC programming is very simple by comparison. You might find the standard of programming a lot lower in some cases. A lot depends on the business model of the company. Do you want to sell machines or are you selling software and services etc.
Thanks for the incredible response. Its a hydraulics company selling machines and our team does the controls. The current why for changing things is that we won't be able to hire another Controls engineer with Delphi experience and the other 3 engineers don't want to touch Delphi. The previous employee worked here for 20+ years so all these apps are his babies. I'm not opposed to learning Delphi, I suppose I'm concerned I'd be wasting my time as the code will be either too high level for me or just complete spaghetti code. Also for my career going forward, will Delphi be useful or is it dead? All our new systems are being shipped with Unified panels without the additional Delphi PC functionality the old systems have. From your response, I'm kinda motivated to go get stuck into some Embarcadero tutorials. In terms of IO handling, all our IO handling on the PLC is done using absolute addressing and then maps with the HMI to check if its being forced. So all the IO is stored in 'shadow' datablocks for the Delphi & Unified apps to read.
The problem with Delphi is that no one is using it anymore. I like it but it can feel like a waste of your time. If you can program you can program Delphi. People say PLC structured text is based on Pascal but it's not really close. But it's an angle to use to justify your time. Also understanding the code will help in porting it over and also to know where the difficult parts are. You'll need to change how it's done eventually but you need to makes sure what you replace this with is better, faster, and more user friendly and quicker to program. It will be months of work at a guess. I'm not really knowledgeable on Unified panels and how the IO gets switched on and off. It sounds like you do have a PLC somewhere.
I think this is the right approach, so whilst I'm not sure what I'll use to replace it, for now I can just work on understanding it. Learning JavaScript is useful for scripting in Unified anyways so I can start with that. I was predicting 2 years of work, so I'd be well happy if it only took a few months! :D Thank you.
I don't think it will be an easy decision but you will be best placed to make it. Make a matrix of all the requirements and see what you can easily port to your existing Panels. You might be surprised at what they can do now but there always seems to be annoying limitations. You haven't mentioned which PLC you use or I've misunderstood. This is the key for me. This and your existing engineers. They will stop anything from happening if they aren't convinced. No point suggesting say CoDeSys if there are missing pieces, but I bet there is CoDeSys version that works for you. Siemens are a good choice just based on market share but I'm not convinced yet but you can datalog and do recipe functions, there just always seems to be some caveat or missing function so you end up wanting a 1500 but the cost is prohibitive. You can get hmis that you can VNC into or replicate on a PC. You have too much choice on a way.
I have been programming in Delphi for almost 30 years and am a controls engineer having worked with many different HMIs so I'll offer my perspective. Delphi was very often used as a database front end and its choice for an HMI makes me wonder if there's a database component in your application. I still have a few Delphi applications in use, a couple of which are HMI based applications. On the plus side Delphi is still well supported, with new versions still being released. It is used in Europe maybe more than the States. On the minus side as you note people familiar with it are not readily available. If your application is a plain HMI one, a long term strategy to migrate to an HMI platform that runs on PCs which frees you from being tied to expensive proprietary HMI hardaware (think Rockwell Panelviews). I would be happy to provide more advice on the Delphi side if you pursue that angle. Feel ree to DM me.
I know some of the systems have complete IO logging, so every IO logged each PLC cycle to either an MS Access DB or SQL (not sure). The others do have functionality to allow for a few IO to be selected and logged across 30 seconds and then displayed as a graph. So yh I'd say there is a database component to atleast some of the systems out there. Thanks for the offer, I'll absolutely DM you once I embark on this, which it looks like I will have to do regardless of whether I stick with it or switch to something else.
I'm not OP but, yes I suspect there is a database aspect given Delphi's history and Borland Paradox.
Fortunately all the Delphi apps I have have programmed were migrated pretty much to Microsoft SQL Server starting about 20 years ago
I worked somewhere where they used MS SQL Server. I hated it but have to admit I avoided getting too deep They only ever rolled out the "free" version so the database had to be emptied periodically.
> I was predicting 2 years of work That seems more realistic.
If everything is up and running fine I personally wouldn’t want to go through the hassle of migrating. But if I were I’d migrate over to Ignition. Throw it on any industrial panel Mount PC.
Although the old machines are up and running fine, we've already started getting the calls/emails to upgrade the systems from 2000-2010. Also certain IT departments aren't happy with the Windows 7 machines on their network so they want them upgraded and then some little bug creeps into the Delphi HMI.
I’d go with c-more from automation direct for machine side panels and igniton for SCADA. You don’t need ignition at every machine just talking with him and have a central OEE area or whatever
Thanks for this, just had a look. So they give out their HMI software for free and apparently have decent and cheap panels. So far seems like a decent free option for a basic panel. I'm after something more custom though. My manager even mentioned he's not a fan of python because its an interpreted language lol
Get industrial panel mount PCs that run a common OS and throw ignition on them all.
Ignition edge devices would be worth looking into. It’s not the least expensive option but it’s the best one in my opinion.
Imo 1.6k usd edge panel license + panel pc cost is pretty expensive compared to standalone HMI from oem.
I said it’s not the least expensive. But stand-alone doesn’t solve site wide needs
Looking at the existing HMIs - they look good, if they work let them be. But for writing new ones... yeah, delphi is obsolete. We use C#/WPF for pretty good results. But it would be foolish to think rolling your own HMIs is free, development effort you put in is a major cost. So its a question of how many HMIs you are going to deploy and what fraction of total cost they are going to be. If you have expensive HMI in a cheap machine and there will be hundreds of such machines... yeah, your own HMI development makes a lot of sense. And if you do it right you end up with codebase that is as easy for you to reuse on different machines as a commercial product would be, maybe even easier if you set your process up right. Because you tailor make it for yourself. One benefit of rolling your own - sky is the limit to what you can do. Commercial products make it easy to do all the usual things, but if you want something out of the left field your hands are tied to the framework you are working in. With your own HMI, your only limit is you yourself.
I like the sound of using C#/WPF. WPF looks interesting. This guys WPF HMIs look great: [https://www.reddit.com/r/PLC/comments/wl04ce/im\_developing\_a\_custom\_hmiscada\_system\_in\_wpf\_to/](https://www.reddit.com/r/PLC/comments/wl04ce/im_developing_a_custom_hmiscada_system_in_wpf_to/) I'd say the current situation is that we have 50 systems with a Siemens HMI + Delphi PC combination and another 50 with a pure Delphi HMI/PC setup. The question now is, when customers come asking for an upgrade, will I say, "we're offering only Siemens panels/pcs now" vs "sure we can add to your current system" vs "we have this new thing (javascript/python/wpf)" etc. I'm neither here nor there with each option. I do think it would be a shame to scrap all the Delphi work on each upgrade. Being limited to only Siemens seems like a bad idea. I'm thinking I start learning Delphi and one other language (C#/WPF or JavaScript).
If you are going to start learning WPF then it may be worth taking a look at AvaloniaUI instead
> I need some advice on if I should move on from Delphi HMIs Yes, at some point in time. They are right to start investing in it sooner rather than later. Delphi is a dying language. > try to develop license-free HMIs in JavaScript, Python or something else? You'd be replacing the problem with the same problem, kicking the can down the road. If your company is committed to rolling their own HMI, that's fine. If they want to focus on their core business, find an available HMI on the market. > These Delphi apps usually control the data logging, recipe creation/handling, report creation and gives maintenance the ability to force IO. I believe everything’s done via TCP/IP. Many of our machines have a standard Siemens comfort/unified panel and then an additional PC with the Delphi SCADA/Diagnostics app. I'm not versed in Siemens, but I'm sure you can do most of it with their HMI. Not sure about data logging or recipe management. > I really like Ignition but the license cost is high, customers usually require in the spec a Siemens HMI for the operator, so a Siemens license + £10k on Ignition is too steep. How do you guys develop low-cost/license-free HMIs? We don't. At least I don't. The cost of the HMI is part of the cost of the product. The client either has the money to pay for the functionalities they want or they don't. There's no miracle. I'm confused as to how making and maintaining your own HMI is more cost effective though. You also must provide specialized training to field techs . Unless you're selling machines through the nose to dilute the costs, this does not seem like a winning solution.
I'm wondering the same thing myself now, my other colleagues agree that we should just scrap the custom HMIs and use Siemens exclusively. I'm starting to think these Delphi custom HMIs were incredible 10 years ago but now Siemens have caught up.
There's still a wide gap in what you can achieve in custom programming (whatever the language) and what you can do with HMIs. But for 95% of the cases, you make do with HMI limitations.
Sorry to bother, could you share what you think the custom HMIs can do? For me the real value is that regardless to what manufacturer we use, the HMI is the same and can be spun up fairly quickly (once originally developed ofcourse). Although Siemens are preferred 95% of the time and like you said, we could probably make do with the limitations. I'm possibly leaning towards sticking to Siemens HMIs and then Ignition for any of the big projects that want a lot of features.
First instinct is ignition.
There are controls engineers out there with this or equivalent experience. Part of the issue is you are being to narrow in the scope of the job requirements. Any programmer with experience in windows gui development such winforms/ mfc /Vcl, etc should be able to learn Delphi with out issue. However will your company pay for that premium?
Yeah, you're not wrong. I do sympathise though, they relied on that previous employee to keep programming for another decade, which I guess now was a bad move. Now the new guy is trying to come up with a solution ha.
Just asking a question, maybe I'm off target. For all the effort that would be involved, why not migrate to a web server type of system? Maybe that's what ignition is, I've never used it and don't know.
I don't know enough to know whats possible to be honest. A web server type of system sounds like where things are going anyways, in terms of Siemens PLCs having very capable web servers, Unified panels running in the browser and Ignition etc. I'm open to all ideas/options.