Most developers that have worked in automated manufacturing plants have likely came across some Allen-Bradley programmable logic controllers (PLCs) at some point in their career. Allen-Bradley’s line of Logix controllers are one of the leading PLC brands. Their MicroLogix, CompactLogix, and ControlLogix products are very common in automotive manufacturing in my local area. I have seen CompactLogix controllers used in dozens of automated production lines over the years.
If you are reading this article, the chances are good that you have been tasked with communicating with an Allen-Bradley PLC from a computer network running Microsoft Windows. This is a very common requirement in manufacturing. Many automated, or even manual, production lines collect and track some amount of information on each part that passes through the production process. The data collected could be as simple as a serial number and a timestamp, or as complex as storing hundreds of measurments and capturing dozens of photos of each part. Depending on the speed at which parts move throught the production process capturing and storing this data can be either trivial or a monumental challenge. The speed of this production process, commonly measured in parts per day, parts per hours, or even parts per minute comes down to one thing: cycle time. Cycle time is the maximum amount of time that is available for any action at any point in the process.
Calculating Cycle Time
To calculate cycle time, you take the number seconds in a given period of time, and divide that by the target production rate in that period of time. For instance, 2500 parts per day on a production line that runs 24 hours a day works out to a cycle time of just over 34.5 seconds per part.
(seconds in a day) / (target parts per day) = (cycle time in seconds)
86400 / 2500 = 34.56 seconds per part
86400 / 10000 = 8.64 seconds per part
Why is this important? It is important because all data collection operations at any given point in the production process must be completed within that cycle time. Simply put, the shorter the cycle time, the faster you must collect and store the required data.
To OPC or not to OPC?
Naturally, there are several different methods available to communicate with Allen-Bradley PLCs. The most common method in my experience is by using the OLE for Process Control (OPC) protocols with an OPC server such as KepServerEx from KepWare. From KepWare’s web site:
KEPServerEX is the industry’s leading connectivity platform that provides a single source of industrial automation data to all of your applications. The platform design allows users to connect, manage, monitor, and control diverse automation devices and software applications through one intuitive user interface. KEPServerEX leverages OPC (the automation industry’s standard for interoperability) and IT-centric communication protocols (such as SNMP, ODBC, and web services) to provide users with a single source for industrial data. The platform is developed and tested to meet our customers’ performance, reliability, and ease-of-use requirements.
I used KepServerEX for a few years when I first started writing industrial data collection systems. While KepServerEX performs well in most environments, I have ran into some performance issues in facilities that have poorly planned network infrastructure in place. Here are some of the pros and cons of KepServerEX
- Compatible with a wide range of devices, brands, and protocols
- Very reliable in a well-designed network environment
- Licensing fees. KepServerEx must be licenses, in addition to licenses for KepWare drivers to communicate with different brands/models of devices.
- Server Model. I have problems getting OPC data collection applications to work with KepServerEx from remote machines. In production applications, I always run the data collection applications on the same system where KepServerEx is installed.
- Internal Tag Database. A tag needs to be created in KepServerEX for each tag you want to access in the PLC. If you have 300 tag values to read from your PLC, then you will have to create 300 tags in KepServerEX. This seems like an unnecessary step, and can take up a lot time. Another annoyance is that the tags in KepServerEX cannnot have the same name as the tag in the PLC, which means the tag names that you use in your data collection application will not match the actual tags in the PLC. I have seen this cause a lot of issues for some of my customers when they were trying to troubleshoot issues.
- Slow Tag Reading/Writing. KepServerEX acts as a man-in-middle between your application, and the PLC that you are communicating with. I have seen read and write times surpass 10 seconds per tag in some situations where there were tens of thousands of tags configured on multiple PLCs in KepServerEX. When you have a short cycle time and a large number of tags to read per cycle, this can become a huge problem. In those situations I have resorted to spawning separate threads for each tag I need to read so that the read operations can be performed in parallel. Once I standardized my KepServerEX libraries to be multithreaded by default, all of the slow read and write issues seemed to go away. The downside of this is that it adds a lot of code overhead to manage all of those extra threads.
What I Use
You can probably guess by the list of cons that I am not an advocate of KepServerEX. KepServerEX works well, but I consider it to be expensive and cumbersome. A few years ago, I stumbled on AdvancedHMI, which a free and open source human-machine interface (HMI) system. AdvancedHMI is a .NET application with source code. I immediately tried it out, and found it to work very well, even though we continued to use PanelViews for our HMI systems. What REALLY caught my attention, however, was that it could read Allen-Bradley tags by simply entering the IP address of the PLC, and entering a PLC tag name. Coming from KepServerEX, this was a huge change, and far simpler. I soon found out that AdvancedHMI sells their Allen-Bradley ControlLogix/CompactLogix communication driver separately for a nominal $200.00 fee. I immediately purchased the driver, and began testing.
What I found was that the driver is VERY fast. We found ourselves having to add some delays into some of PLC ladder logic because the AdvancedHMI driver was performing write operations in a few milliseconds instead of the 5-10 seconds we were seeing when using KepServerEX. The first version I purchased had some downsides though. It didn’t handle UDTs very well, and non-standard length strings (shorter or longer than 82 characters) were return as hexadecimal values, and had to be converted back to the actual string. These issues were fixed in the next release, however. Now, I use the AdvancedHMI driver for every Allen-Bradley project, simple because of the speed and the simplicity.
Here is an example of connecting to a PLC, and reading and writing a tag using the AdvancedHMI driver:
Imports ClxDriver.Common Public Sub Main() Driver = New EthernetIPforCLXCom() Driver.CIPConnectionSize = 508 Driver.DisableMultiServiceRequest = False Driver.DisableSubscriptions = False Driver.IPAddress = "192.168.1.42" Driver.PollRateOverride = 1000 Driver.Port = 44818 Driver.ProcessorSlot = 0 Driver.RoutePath = Nothing Driver.Timeout = 4000 Dim PartCount as Integer = 0 PartCount = Driver.Read("MES.PARTSLOADED.A1") Driver.Write("MES.PARTSLOADED.A1", 0) End Sub
That code, and a reference to ClxDriver.dll is all that is needed to read from and write to a tag. There is no software to install. The ClxDriver has a lot of functionality beyond just simple reading writing too, such as subscribing to PLC tags and firing events based on tag value changes (triggers), consecutive tag reading in a single operation, and some UDT features as well.
If you are interested in seeing the full source to one of my applications that use this driver let me know in the comments below.