Any solution for ethernet communication between PLC and PC?

[ridgemao]

I need to read or write several bytes to PLC from PC's VC program, this VC program is written by myself. I knows it's easy to use RS232 to communicate between PC and PLC. But it is not a reliable communication compared to TCP over ethernet. These days I was trying to use OMRON's CP1L PLC and CP1W-CIF41 ethernet option board, but finally I found the CP1W-CIF41 doesn't support basic TCP socket operation, it only support FINS/TCP, which is a more higher layer protocol in application layer. I don't want to study FINS, because I thought it was not a popular protocol in industry. what is the common solution in industry to communicate between PC and PLC over ethernet? Especially communicating with the PC's VC program written for special application. Any ideas? thanks. Edited March 2, 2011 by ridgemao

[RussB]

Try UDP. If you do not want to learn the details of all the different protocols, I suggest you purchase OPC drivers. There are many sources for these, one of the more popular ones is www.kepware.com And if your time is worth anything it may even be cheaper. Edited March 2, 2011 by RussB

[paulengr]

Some PLC's do support socket communication natively. As a general rule, EVERY PLC brand has a slightly different protocol over Ethernet (and often serial for that matter). You have two choices. Each PLC out there has drivers written for it that support the OPC protocol which gives you a common API to talk to it from the PC side. OPC was specifically created to overcome the problem that every PLC vendor has a different protocol for their PLC, whether serial, Ethernet, or something else. All PLC vendors (or third parties) offer OPC drivers that give you a consistent API on the PC side. There are problems. OPC is based on COM/DCOM that has been officially abandoned by Microsoft. The new protocol (OPC-UA) is so new that drivers are still in development, but there are also OPC/OPC-UA bridges to fix that. If I were writing something new, I'd probably try to support both. The second solution is using Modbus, more specifically Modbus/TCP. This protocol is the universal protocol for PLC's. The protocol is unbelievably simple to understand and write code for, and the specification is completely free...www.modbus.org. The serial version has been out there since the 1970's. Combined these explain the popularity and support you get. Most "oddball" hardware devices iwill support Modbus or Modbus/TCP as a bare minimum in addition to one or two additional protocols (Ethernet/IP and Profinet, the native protocols for the two most popular PLC vendors). Every PLC available either can communicate Modbus (or Modbus/TCP) natively, or has some sort of interface card that can do it. As to the assumed reliability of serial vs. Ethernet...that's very questionable. By nature Ethernet is somewhat ephemeral and makes no assumptions about communications. The whole reason for the TCP protocol is to hide these details and make it look like a "serial port". Over the last month or so I've been fighting a freak network problem where once in a while, one or more PLC's drops communications to it's IO and causes everything to come to a crashing halt before instantly restarting...serial doesn't do this but serial also doesn't do 100 Mbps. Serial is only "unreliable" in the fact that few people acttually follow all the rules (no more than 10 meters of cable at 9600 bps or less), few implement any sort of error checking/correction in their protocols, and that both devices and end users do a very poor job of understanding and labelling "DTE" vs. "DCE" devices (most Ethernet equipment does this for free these days with auto MDI/MDI-X). If you want "Ethernet grade" communication over serial, consider using some sort of error checking/correction. With Ethernet nothing is taken for granted so the virtual circuit interface (osckets) does this "for free", and Ethernet pushes the limits on communication so hard that essentially it either works or it doesn't. UDP (another suggestion) is not the answer. It might work for a particular PLC but not all.

[ridgemao]

Explained very thoroughly, thank you so much.