I've been working on a project recently that involves reading values from PLCs. This is the first time I've worked with PLCs though I've long been aware of how prevalent they are for factory automation. The particular PLC that I'm working with is an Allen-Bradley Micrologix 1100. This is an inexpensive (~$200) PLC that can be connected to an ethernet network.
In the process of researching this project, I've learned a few things of interest. First, the protocol that the MicroLogix uses for communications over ethernet is a proprietary Allen-Bradley protocol. It's not a simple protocol, and to obtain the protocol specification you need to become a member of odva.org. The membership is not free, and to obtain the protocol you'll need to apply for and be granted a vendor id. Total cost is $850.
I suspect at least part of the reason for the cost is to discourage hacking. There's a lot of fear in the air now about having PLCs on ethernet networks where they can be the targets of unauthorized access. Some of this at least is worrymongering. To do anything with a PLC you need to know a lot about it, it's intended use and how it's hooked up. Then you need to break through various levels of network security (firewalls and such) to access it. Not the sort of task most script kiddies are up to.
There are vendors from which you can purchase libraries that encapsulate the EthernetIP protocol. Automated Solutions has a library, ASComm.NET, which in my preliminary testing seems to work quite well.
One issue with EthernetIP is that it can not be used to communicate with other brands of PLCs such as those from Siemens or AutomationDirect.com so if you write your app to use the A-B EthernetIP protocol then you're locked into A-B PLCs. One way around this is problem is to a driver library such as the one available from Kepware. These drivers use something called OPC to encapsulate the PLCs. An OPC server is responsible for actually polling the PLC and the driver (and your app) then communicate with the server, which may or may not be located on the same PC.
The problem as I see it with OPC is that it's based on COM/DCOM. I have concerns about the reliability and ease of support of DCOM based on prior projects that I've worked on that have used DCOM. At our factory we use wonderware products for monitoring and reporting, and it seems that the OPC server reports the last value gathered from the PLC regardless of whether or not the PLC can currently be contacted. In HMI applications this could be problematic. However, the ability to support multiple brands of PLCs has a lot of weight and lots of folks do use OPC for HMI application so there obviously are ways around this issue.
In the process of doing my research, I happened across a couple of very good PLC web sites:
Lynn's Industrial Automation has lots of great info. Lynn obviously puts a lot of effort into keeping his site up to date and authoritative.
www.plctalk.net is a forum for anyone working with PLCs. There is lots of great info here, too, and it can be quite interesting to read about other people's problems and experiences with various technologies.
In the process of researching this project, I've learned a few things of interest. First, the protocol that the MicroLogix uses for communications over ethernet is a proprietary Allen-Bradley protocol. It's not a simple protocol, and to obtain the protocol specification you need to become a member of odva.org. The membership is not free, and to obtain the protocol you'll need to apply for and be granted a vendor id. Total cost is $850.
I suspect at least part of the reason for the cost is to discourage hacking. There's a lot of fear in the air now about having PLCs on ethernet networks where they can be the targets of unauthorized access. Some of this at least is worrymongering. To do anything with a PLC you need to know a lot about it, it's intended use and how it's hooked up. Then you need to break through various levels of network security (firewalls and such) to access it. Not the sort of task most script kiddies are up to.
There are vendors from which you can purchase libraries that encapsulate the EthernetIP protocol. Automated Solutions has a library, ASComm.NET, which in my preliminary testing seems to work quite well.
One issue with EthernetIP is that it can not be used to communicate with other brands of PLCs such as those from Siemens or AutomationDirect.com so if you write your app to use the A-B EthernetIP protocol then you're locked into A-B PLCs. One way around this is problem is to a driver library such as the one available from Kepware. These drivers use something called OPC to encapsulate the PLCs. An OPC server is responsible for actually polling the PLC and the driver (and your app) then communicate with the server, which may or may not be located on the same PC.
The problem as I see it with OPC is that it's based on COM/DCOM. I have concerns about the reliability and ease of support of DCOM based on prior projects that I've worked on that have used DCOM. At our factory we use wonderware products for monitoring and reporting, and it seems that the OPC server reports the last value gathered from the PLC regardless of whether or not the PLC can currently be contacted. In HMI applications this could be problematic. However, the ability to support multiple brands of PLCs has a lot of weight and lots of folks do use OPC for HMI application so there obviously are ways around this issue.
In the process of doing my research, I happened across a couple of very good PLC web sites:
Lynn's Industrial Automation has lots of great info. Lynn obviously puts a lot of effort into keeping his site up to date and authoritative.
www.plctalk.net is a forum for anyone working with PLCs. There is lots of great info here, too, and it can be quite interesting to read about other people's problems and experiences with various technologies.
0 Comments:
Post a Comment
<< Home