C# HMI vs. Commercial HMI - Which One Is Best

In this article we are going to look at some of the advantages and disadvantages of developing your own custom C# HMI versus going with a commercial-off-the-shelf (COTS) system. One of the biggest advantages of using a high-level programming language such as C# to develop your HMI applications is the granular level of control you will gain by using the .NET environment.

Couple the power of C# and the .NET programming environment with Ingear.NET class libraries and your C# HMI applications will have direct access to virtually any PLC hardware manufacturer on the market today. That means no middle-ware or OPC Server software will be needed to bridge the connections from your C# HMI application to your PLC contoller.

Why develop a custom C# HMI instead of using a commercially available off-the-shelf solution you ask? Keep reading and we’ll discuss some of the pro’s and con’s of opting for one solution over the other, and why it may make sense to develop your own custom C# HMI for a particular project!

C# HMI vs. Commercial Off-The-Shelf Solution

The question I’m often asked is why opt for a custom C# HMI versus a commercial-off-the-shelf type solution such as those produced by Rockwell or Siemens over some of the other “canned” type alternative. Well truthfully, it almost always boils down to cost! While these COTS systems are robust and well tried, they can sometimes lack the flexibility needed for a given project, and they are comparatively very expensive.

In some circumstance the cost alone can cripple your ability to be awarded a contract. Now I know I’m going to get some people that are going to say that all of these companies offer scalable solutions, and I say to that, yes that’s true, but…

Warning!

Governments and ISPs across the world monitor their users’ online activities. Currently, your IP [ipt_address] is visible to everyone. I strongly recommend that you get the and hide your identity so that your online activities remain anonymous.

I personally use and recommend you use one of , or . They are the fastest and most secure VPNs in the industry.

They would be nowhere near as cost effective as a custom C# HMI application that I could develop myself, especially when the system needs to do things like connect to a backend SQL Server database or send automatic notifications via email and SMS.

Want to skip the rationale and jump right into learning how you can develop your own custom C# HMI? Get started in this first video in our C# HMI video series on our YouTube Channel.

It’s capabilities such as these that really separate the canned “cookie cutter” type solutions from a custom C# HMI application that is designed from the ground up to provide these types of functions. The ability to take full control over your application through a high-level programming language such as C#, is by far a superior approach in circumstances such as these.

There are simply no constraints! The only constraint is your imagination and your ability to code a solution. I know you’re probably thinking, “but I’m not an expert coder”! Make no mistake, I don’t profess to be one either! That said, I should probably disclose that I do have a degree in Computer Science and Software Engineering so my background may be a little stronger than most in that regard?

Truth is, while the formal training I have gives me some additional insight into how to architect a software solution, make no mistake this is where Google can become your best friend. Websites like StackExchange and others are truly amazing and will help you to code just about anything you put your mind to!

C# HMI – Drawbacks

Of course, there are obvious drawbacks to creating your own custom C# HMI too. These drawbacks certainly cannot be taken lightly either. There are five major ones that I can see creating your own custom C# HMI, and they are:

Knowledge of high-level languages
Reliability
Supportability
Sustainability
Standarization

Knowledge of High-Level Languages

This is the obvious one, if you’re not part of an engineering house or software company who is developing these custom C# HMI’s, then the individual is taking on the challenge of develop their own custom solution.

This means that you then must possess the necessary background in high level programming languages such as C#, Java or VB. This can prove to be a major constraint because as controls engineers people we generally lack the high-level, object-oriented programming background.

In saying that, I think this is beginning to change. As time and technologies evolve, what we’re required, or even expected, to deliver as controls engineers is changing right along with it. Anymore, we are required to have more than just a basic knowledge of electrical and control systems. Now we need to possess proficiency with multiple programming languages, networks, SCADA systems, processes and the list goes on.

Reliability

The reliability or robustness of any custom C# HMI application that you develop is an important one. One of the overriding requirements for any production environment is reliability. Automation systems need to be designed such that production “uptime” is maximized and unexpected downtime is minimized.

The benefit of some of the commercial-off-the-shelf solutions discussed here is they are well-developed and well-tried. This means that they’ve undergone rigorous testing and are typically supported by teams of software engineers…this is what you are paying for!

Of course, this is a big one, and it may be a tipping point and well-worth the money you have to shell out to get this kind of support and tested solutions.

Supportability

This is one I hear over and over again, particularly from IT personnel. The old adage, “what if you get hit by a bus” routine. There is, however, validity to this statement. If you are an ambitious controls engineer with the depth and background in high-level, object-oriented programming languages, looking to take on a custom C# HMI project for your facility, that’s great!

However, what happens if you DO get hit by a bus or leave the company? Is there someone in your company that can take the baton from you in the event you leave? These are very real questions that need to be considered before embarking on a custom C# HMI solution.

Sustainability

This ties in closely with supportability described above and could just as easily been titled “Maintainability”. Sustainability is another big question to ask yourself. The allure of developing your own solution and saving the company money is a tempting one…but is it sustainable?

Consider this. Will your application easily lend itself to evolving technologies, or changing processes. This is especially important on those pieces of “Process Automation” equipment. The core infrastructure or central processing system of any given plant that have longer life-spans, typically 20-50 years. These core systems or those that you simply don’t just replace, but rather upgrade as technologies evolve.

It is important that if you decide to implement your own custom C# HMI type application for these types of systems that your solution has the ability to evolve along with them.

Standardization

Rounding out my last but certainly not least set of custom C# HMI application drawbacks is standardization. What is not desirable, particularly in large facilities and plants, is having all of these custom rogue software application floating around!

Standardization really ties all of these drawbacks together in my opinion. Without standardization things can go side-ways very quickly if left unchecked. When things go wrong, there is value in knowing that you can usually just pick up the phone and contact your local provider for the support you need. This is invaluable to controls engineers responsible for large scale systems with potentially 100’s or even 1000’s of end-point connections.

But I Still Want To Develop My Own C# HMI!

Okay, I haven’t deterred you…great! Developing your own C# HMI still has some merit depending on your particular situation. So without further ado, let’s get you started down this path by leveraging the Visual Studio IDE and Ingear.NET class libraries!

C# HMI – Why A Direct Connection Over OPC?

The biggest advantage of a direct connection to a PLC endpoint versus going through an OPC Server is speed. You are effectively cutting out the “middleman” by going with a direct connection from your C# HMI application.

How does it work? Most driver manufacturers on the market, such as CimQuest Ingear that I eluded to earlier, can make short work of the complexities of connecting your C# HMI application to a programmable logic controller. The basic workflow goes like this:

Add the class libraries to your new or existing C# HMI application.
Import the necessary references into your class.
Instantiate the objects and start making use of the pre-built methods included in the libraries.

If you watched the first video in the series, perhaps you’ll be interested in the second one here!

That’s basically all there is to it from a very high-level point of view. The complexities of building your own low-level drivers, or connecting to an OPC Server or an endpoint logic controller, is essentially gone. Provided you are comfortable in a C# object-oriented programming world this is a great alternative to expensive commercial-off-the-shelf solutions.

C# HMI – Adding The Required Ingear Class Library Files (.dll’s)

The process of accessing your PLC’s data directly from your C# application becomes extremely easy using Ingear’s driver packages. To add the required library files to your application follow these steps.

1. Open an existing or create a new C# application in Visual Studio.
  
  We are going to create a simple WinForms project titled “TestProject”.
2. Navigate to your Solution Explorer and right-click the “References” directory and choose “Add Reference“.
  
  We are interested in three Ingear reference files in particular:
  - INGEAR NET.LOGIX X.0
  - INGEAR NET.Interfaces X.0
  - DeployLX Licensing Runtime vX.0
  The “X” in the file names will be dependent on which version of Ingear you have installed.
3. Now that the necessary references have been added to your project. You’re ready to start using the libraries to connect to one or more Logix controllers.
  
  All that’s left to make use of these libraries is to it to your Class Namespace.

Below is a simple demo project using the Ingear drivers and Visual Studio 2017 Community Edition. It is the third video in our C# HMI playlist on our YouTube Channel .

C# HMI – Connecting To The Controller

If you watched the previous video, you’ll see that Ingear makes it extremely easy to get and running quickly with the variety of demo projects they include in there software. We did however glaze over some of the code behind necessary to actually implement it yourself.

In this section let’s carry on with our “TestProject” above to develop our own simple C# HMI and then implement the necessary code needed to connect to a ControlLogix controller. Let’s say the controller is at the following IP address: 172.16.10.10 with the following subnet: 255.255.255.0.

Let’s also create a two buttons, one to “Connect” and one to “Disconnect” from the PLC. Once connected we should get some kind of indication that we are connected to the controller.

Want to see how this works in action??? Check out this fourth video in our C# HMI playlist on our YouTube Channel. This “TestProject” application has two parts. This is first part that gets the main GUI (Graphical User Interface) components roughed in.

It should be clear that we are creating a very simple C# HMI application in this tutorial. We are making some assumptions too – we will assume that once we’re connected to the controller nothing will disconnect us other than by pressing the “Disconnect” button.

In reality and in a production environment, you need to consider every conceivable possibility that can arise and deploy the necessary logic. For checking the connection status, a Timer that periodically checks the connection status to the controller would be useful.

This is sometimes referred to as a “heartbeat” type check. This can be easily implemented by making use of the Timer() class and we are going to be implementing one in the next section when we attempt to read a tag continuously from the controller at some predefined sample rate.

C# HMI – Reading/Writing A Controller Tag

Reading and writing of tag data is snap using the Ingear class libraries. Simply instantiate a Controller object and then instantiate a Tag object. Once instantiated, simply make a call using one of the several overloaded read and write methods that are pre-built in the libraries.

In our “TestProject” example, I show you how to make use of the builtin Timer() class to continuously read the analog value of a tag residing in the ControlLogix PLC. By “forking” off a new timer thread we can read the state of this or any tag at some sample rate that we define.

This is perfect for reading tag values that you want to tie to a trend or some other continuous type display that requires a consistent tag update rates.

See how it’s done right now…

C# HMI – Final Words…

I hope you have enjoyed this article, and I do encourage you to become a member of our growing community of professional engineers, technicians and technologists, Register Here!

Also, check out our YouTube Channel to see some great videos…and don’t forget to like and subscribe to our channel!

If you enjoyed this article be sure to check out some of these good reads too:

Lastly, if you run into any problems in your day-to-day engineering activities please be sure to check out our Live and Interactive PLC Forum!

And if you so desire, assist other community members by replying or offering helpful information to the questions or challenges they may be facing right now!