Let’s say that you want to build your own HMI, because:
- for your application a commercial SCADAs are too expensive
- 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 the 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 support 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 use the same methods for both protocols.
Modbus (especially TCP) is a good choice to communicate with PLCs with C# and 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, i wrote an 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 support both Modbus TCP and RTU.
If you need details about Modbus protocol you can check this site, that has a good video and an exaustive explanation.
OPC: OLE for Process Control
OPC is the simplest, safer 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 used.
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 on this article. The best choice 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, this 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 has been developed with reverse engineering of the protocols.
The most common for Siemens is LibNoDave, a free library that is used for the most with Ethernet cards (CP343-1). It’s a very common library to communicate with Siemens PLCs and well tested, because has been used widely. It supports also other interfaces (i think it support MPI, Profibus and many Siemens PC-Cards).
Other libraries for Siemens PLCs are S7.Net, based on Ethernet communication too, and a library based on LibNoDave called 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 special mention is deserved for an “almost open-source” project,AdvancedHMI that contains free drivers. Those drivers are written in Visual Basic .Net and they are not opensource, but they are free and the interface to them is open-source. To use this 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 consideration about those drivers: they works good but you should consider that if you meet problems you are alone with an “unkown dll” and the “quick support” is granted only if you pay.
I 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 driver? 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 happens when the complexity grows because of integration of plcs of different manifacturers. When this happens, OPC is a must.
This libraries are custom dlls or ActiveX provided by the manifacturer or 3rd party companies. They are generally not free and they reminds me legacy applications where every plc had his own library with his own code. This is a video that explains why OPC has been made and why you should really consider to use OPC instead of third-party libraries: