Let’s say that you want to build your own HMI, because:
- commercial SCADAs are too expensive for your application
- you need more control over the code and VBA is not good
- you want to protect your know-how
- you need a better HMI and you can’t do it with a normal SCADA
and you choose to use .Net and C# or Visual Basic .Net.
Now the first and most important thing that you need to do is to Read and Write Data to your PLC, and to do this you have 4 choices:
- using Modbus TCP (or RTU)
- using OPC
- using open source drivers (gpl or lgpl licensed)
- using third-party libraries (activex, dlls and so on)
Modbus TCP and RTU
Modbus TCP is based on Ethernet TCP/IP connection from PLC to PC, there is no need for a custom card on PC, but most of the times you have to buy an additional Ethernet Card for the PLC that support Modbus. In the last 2 years many plcs are provided with ethernet integrated port that supports Modbus, let’s say for example Allen Bradley Micrologix 1400(ser. B) or Siemens S7 1200.
To communicate to a PLC with Modbus TCP you need a library called nModbus: download it on the google code site.
This library has been tested a lot and it’s almost a standard for Modbus TCP and RTU, because it uses the same methods for both protocols.
Modbus (especially TCP) is a good way to communicate with PLCs with C# and it gives you the most of flexibility, because you build your program and you can run it wherever you want without licenses to pay and so on.
If you need some examples, take a look at my article on how to use NModbus with C#.
All manifacturers support Modbus, in particular:
Siemens s7-300 and s7-400 support both Modbus TCP and RTU: read more about it in the official documentation. For Modbus TCP you need of course the Ethernet card or CPU Profinet version.
Allen Bradley CompactLogix and Controllogix do not support Modbus TCP and Modbus RTU, Micrologix 1400 ser. B supports both Modbus TCP and RTU.
If you need details about Modbus protocol you can check this site. It has a good video and an exhaustive explanation.
OPC: OLE for Process Control
OPC is the simplest, safest and easiest way to communicate with a PLC.
An Opc Server is basically a program that connects to the plc using closed source libraries, and exposes the data in a standard way that is not dependant from the PLC that you use.
To use the OPC with C# you need to write your own client using the libraries given by your OPC server vendor, by OPC Foundation or you can use third-party clients. Usually to write a client you just have to create a group and items that you have to read, and wait for the callback that notifies you when the data that you subscribed are changed. OPC permits also many advanced features, like “browse plcs online, browse all tags in a treeview, alarms and events management” and so on… I think that what you need anyway is simply reading and writing tags with different priority. You can find a simple c# client with a video in this article. The best way to communicate with C# and OPC is to use the OpcNetApi.dll and OpcNetApi.Com.dll; you can download those 2 libraries from OPC Foundation site or from some open source projects around the web, just run a search on google. You are free to redistribute dlls to your customers but you are strongly reccomended to get the documentation from OPC Foundation website.
So what’s bad about OPC ?
1) it’s not free, which means that you have to purchase a copy of the OPC Server for every pc where you will run your program.
2) it runs only on windows because is based on COM and DCOM… but no one cares because 99% of industrial panels are built with windows XP embedded or Windows CE.
OPEN SOURCE DRIVERS:
There are some drivers, for the most common PLC manifacturers, that have been developed with reverse engineering of the protocols.
The most common for Siemens is LibNoDave, a free library that is used the most with Ethernet cards (CP343-1). It’s a very common library to communicate with Siemens PLCs and it’s well tested because of being widely used. It supports also other interfaces (I think it supports MPI, Profibus and many Siemens PC-Cards).
A brand new library with many useful features is Snap7. It supports many languages (C++, C#, Pascal, LabView, etc). It’s quite easy to setup and has a great documentation.
Other libraries for Siemens PLCs are S7.Net (also based on Ethernet communication) and DotNetSiemensPLCToolBoxLibrary, that is a layer above LibNoDave to simplify the functions.
For Allen Bradley you should check 2 libraries written in VB.Net for Allen Bradley Plcs:
AB DF1 Protocol and Allen Bradley Slc 5/05 Ethernet Library.
Some other libraries written in C for Windows are the ones of Pvbrowser, famous is TuxEIP (ethernet IP stack for controllogix and micrologix) and TUX DF1. You can find some information on pvbrowser site or on the tux plc webarchive site; Leicht posted those libraries also on github. They are native for Linux but you can compile in windows using CygWin but please don’t ask how to.
A project that deserves special mention is an “almost open-source” project AdvancedHMI. It contains free drivers written in Visual Basic .Net. The drivers are not open-source, but they are free and the interface to them is open-source. To use these libraries you need to import them in your C# project (not in Visual Studio Express edition, you need at least Professional edition) or build the dlls and add them as reference in your C# project.
Advanced HMI anyway offers drivers for: Allen Bradley DF1, Ethernet/IP (both Micrologix and CompactLogix) and Beckoff Twincat. AdvancedHMI offers also good looking objects if you are using Winforms, and you can import them same as you imported the drivers. It’s really a good project and it’s easy to get results. You should check it!
There are some considerations about those drivers: they work well but you should consider that in case of problems you are alone with an “unkown dll” and the “quick support” is granted only if you pay.
I’ve already used those drivers with success, before switching to Modbus, and I wrote an article about AdvancedHMI that you can read.
What’s good about Open Source drivers? They are free and you can debug and improve the communication as much as you need for your plant. You can also write a standard interface (like the one provided by AdvancedHMI) to access to all PLC data in the same way.
The bad side of using this drivers becomes evident with the growth of the complexity because of integration of plcs of different manifacturers. When this happens, OPC is a must.
These libraries are custom dlls or ActiveX provided by the manifacturer or 3rd party companies. They are generally not free and they remind me of legacy applications, where every plc had its own library with its own code. Here is a video that explains why OPC has been made and why you should really consider to use OPC instead of third-party libraries: