This is the number one question that we receive so we created a web page that deals specifically with this issue.
Good news. It is very easy to create a computer - PLC communications application if you have some Visual Basic or C experience. To understand computer - PLC communications we suggest several things:
Granted this is a lot to do but if you successfully do all of this then you should have no problem understanding and developing computer - PLC applications.
There are several different types of connections between the computers and PLCs. For example, RS232, RS422, RS485, and Ethernet. Note that these are only the electrical connection and do not specify the protocol or language used on the connection.
The classical example is an American trying to talk to someone in France. There are several ways that you can connect to someone in France (telephone, e-mail, cell phone, fax machine, television, etc.) and these connections are the equivalent of RS232, RS422, RS485, and Ethernet. But just because you can call (connect with) someone in France does not mean that you can communicate. If the American does not speak French or the French person does not speak English -- you will not communicate. The language that PLCs speak is more commonly know as a "protocol". So it takes both -- a connection and a protocol.
NOTE that just because several PLCs all have Ethernet connections does not mean that they can talk to each other because they speak different languages (protocols)! It would be like saying you could talk to anyone in the world just because they have a telephone (although you do not speak their language). Likewise, PLCs with a RS232, RS422, or RS485 port cannot talk to each other unless they use the same protocol.
Each PLC manufacturer has their own protocol or language that the PLC speaks. For example, Allen-Bradley (Rockwell) PLCs talk DF1, Data Highway 485 (DH485), Data Highway (DH), Data Highway + (DH+), Remote I/O (RIO), Devicenet, Controlnet, and a few others. Talk about an identity complex! Modicon PLCs speak Modbus, Modbus Plus, and now Modbus TCP/IP (Modbus over Ethernet). AutomationDirect PLCs speak Directed and K-sequence protocols while some of their PLCs still communicate using their old protocols. The old GE PLC protocol was CCM but they now use SNP and variants such as SNPX. Siemens PLCs work mainly with the Profibus protocol which is considered more of an open, rather than proprietary, protocol.
The most common "standard" protocols we see are DF1, Modbus, and Profibus. DF1 and Modbus are popular since they have been around longer than many of the people using them. Profibus is popular because, in our humble opinion, combines the best of simplicity (daisy chain, twisted pair), industrial ruggedness (RS485), speed (12 MBaud), adaptability (you can select from many different speeds), scalability (from simple COM port up to communications controllers), and function (most automation devices can talk Profibus). Typically all PLC manufacturers will have a PLC module that will talk these protocols.
Now that Ethernet is becoming the "most hyped" capability in automation there are several protocols over Ethernet. But remember -- just because an Allen-Bradley and a Siemens PLCs are both put on the same Ethernet cable -- they cannot talk to each other because they do not use the same protocol.
Most industrial automation communications standards specify the connection and the protocol. For example if two devices both talk DF1 then you know that they (most likely) have RS232 ports and can both communicate with each other using the same language (the DF1 protocol). Likewise if two devices talk Profibus DP (there are multiple variations of Profibus: DP, FMS, etc.) then you know that they will talk using RS485 and they can communicate.
If you did an internet search and came to this webpage expecting some kinky stuff because of the phrase "masters and slaves" -- SORRY -- there won't be anything near that exciting here. We're not that desperate for web traffic.
If you only listen to a PLC it won't say anything. PLC's respond to requests for information -- they are not designed to just sit there and automatically spit out information. A computer must "poll" the PLC to request information and then the PLC will respond with the requested information.
Technically you can write PLC code to make the PLC continuously send data out of a serial port. But "out of the box" the major PLCs are not designed to send data.
The theory is the Master - Slave approach. Typically there is only one Master and multiple slaves. So a computer could be the master and several PLCs would be the slaves. OR the PLC could be the master and several flow meters could be the slaves. The point being is that the Master polls each slave for data. The slaves are quiet until the master polls them.
If there are five slaves then the master builds a table of all of the data it has to read and write. For example read words 10 through 20 from PLC 1, write words 22-25 to PLC 2, read words 34-39 from PLC 3, etc. Then the master starts going through it's table and sending the read and write commands.
With some industrial networks there can be multiple masters and the use of multiple masters differs so much I will leave it with you to explore multiple masters on your own.
TIP
In the PLC, group your data so that the master only has to do one read and one write. Instead of the master sending three read commands to read word 1 then word 6 then word 12, pack the data in consecutive memory locations in the PLC so the master can do one read command of three words (words 1, 2, and 3). Likewise with the write data. This increases the PLC overhead slightly but greatly reduces the communications overhead. It also reduces the number of requests that the PLC has to handle.
In some applications the efficiency of the communications needs to be considered. There are many ways to look at efficiency (see our tutorial). For example, serial protocols tend to place a heavy burden on your local processor. If I am reading and writing a PLC in Visual Basic or C# via the RS232 link then most likely some control (application or program) running on my computer is having to generate all of the read and write messages, send them out the serial port, wait for the response, etc. So my host computer processor is having to do all of this work. The tip we just gave you will greatly reduce this overhead.
Many protocols have special communications boards with their own communications processors that perform all of the messaging themselves. This relieves the host computer from having to do the time consuming tasks. For example an Allen-Bradley KT card implements the DH+ protocol. When using the KT card, the host computer simply configures the KT card to go read this PLC, go write that PLC, and the KT card takes care of handling all the communications overhead. All the host computer then has to do is read memory on the KT card to read the data (much less work). Whereas if you want to talk to an A-B SLC PLC, you could use a DF1 driver over RS232 and your host computer would handle generating all the read and write messages, sending them out the serial port, waiting for the response, checking the response, checksums, etc.
The fast communications boards typically reduce most of the communications overhead but their cost is in the $500 to $1,500 range.
If you buy one of the communications boards the software to interface to the board may or may not come with the board. In some cases it does -- in other cases it does not. Be sure to check with the supplier because if you have to pay $1,500 for the board and then another $1,500 for the software -- pretty soon you are talking real money.
For an example, let's consider Allen-Bradley's DH+. You can buy the A-B KT card for $1,500. If you want to use the A-B software called RSLinx then you have to pay another $1,500 for a total of $3,000 per computer. You could then buy their SCADA software for another $5,000 + per computer. So you could easily be looking at $8,000 to $10,000 per computer and you haven't done anything yet!
Or you could buy the KT card and buy the Automated Solutions KT driver for $600 and all the run-time licenses are free! Or if you have one computer per PLC and do not need to poll the PLC very fast, you can buy the Automated Solutions DF1 driver for $500 and all run-time licenses are free. You don't need the KT card with DF1 so now you costs per computer are $0 (zero dollars). Buy Visual Basic or C# instead of the SCADA software and you are still sitting at about $1,000 for the first computer and zero dollars for each additional computer. This is why we like the Visual Basic / C# solutions. You can do a lot more for a lot less $.
The difference per computer could be $5,000 to $10,000. For as small as five computers you could be talking about a difference of $50,000. We have competed on projects with 50 computers where they originally wanted another SCADA package and after we showed them a $250,000 savings -- even the training argument was dead.
For serial protocols such as DF1 and Modbus, you could write your own protocol. We use to do that all the time and it takes about four to six weeks to write a protocol, thoroughly test and document the software. Then you have to maintain it (it is not really tested until it has been used in many different real-world applications by different users). Or you can buy it from one of the well known developers and it is already tested, debugged and documented. If you want to save time, money, and all those headaches in the middle of the night, buy a good quality driver. You're already saving thousands of $ per computer -- don't cut out the quality.
There are several basic ways to interface to programs that implement protocols:
The major suppliers of these controls are:
Automated Solutions -- OPC servers and ActiveX controls for communicating with PLCs
ConsoliTech -- PLC communications using ActiveX controls
Ingear -- OPC servers and PLC ActiveX controls
Kepware -- OPC servers
Parijat Controlware -- PLC communication drivers, OPC servers, communications analyzers
SST -- industrial communications hardware & software
vHMI Automation -- PLC communications library, ActiveX DLLs only $100
Note that this book has a chapter where they write the DF1 protocol for an A-B PLC. Highly recommended for people that did not listen to us a few paragraphs back and insist in writing their own code. :-) Actually it is great training and exercise to reverse engineer the protocol and write this code yourself.
Using the protocol functions (ActiveX controls, DLLs, etc.) in Visual Basic or C# is very easy. You usually give it the PLC number (if there are multiple PLCs on the same network), the data file, the starting memory location, and the number of memory locations to read. BAM! It goes and does it and returns the data in an array to you. To write to the PLC you put your data in an array give it the same information and it's done. Many of these controls you can set-up to automatically poll a PLC for the same data on a fixed time base such as 100 milliseconds. So this involves setting a few numbers and it automatically takes care of it for you.
Most of the vendors listed above with have a demo version that you can try for 30 days. They come with good help manuals and example applications. It is a good idea to down load the demo to read their manual and test their examples before you buy.
Typically what we prefer to do is designate one computer as the "process server" where all data for a particular process is brought to in one place and then this computer updates other computers using the Winsock via Ethernet. Computers create Winsock connections over Ethernet which are very fast and efficient. For example one computer reading data from a PLC and then rebroadcasting that data to five other computers using Winsock can be much faster than all six computers beating on the PLC for the same data.
It starts to get ugly when several different processors need access to the same data in "real-time". Note that if several different processors need real-time data from some device, you might not have your control in the right place(s). You may want to reexamine how you have distributed your control. But in some rare cases you still have this problem.
Some industrial communications networks have multiple masters and allow two different masters to poll a PLC or other device for the same real-time data. Depending on the industrial network this can be anywhere from little additional overhead to causing significant slowness in communications response time.
One final tip. Some people want to use only a single communications channel. I guess they are thinking short term simplicity. You can add multiple communications interfaces to PLCs and computers so that dedicated channels can be provided between two devices for higher speed communications and to reduce communications errors. For example, if you decide to use Ethernet in your factory or laboratory -- don't use the "office" ethernet already installed. Create a separate network that runs in parallel. Likewise, if you have 30 PLCs to read data from, preferably use several computers (for redundancy) or at least several communications channels. I am not saying that using only one communications channel will not work. Depending upon the application and environment it could work without too many problems. What I am saying is that if you want something that runs 24/7/365 with a minimum of problems, downtime, interruptions -- use more communications channels. Think long term costs and simplicity.
We try to offer a fair and balanced opinion on every page of our website. We would appreciate more information from other industrial networking and communications users to express their opinions which we will then incorporate. If you have questions or comments please post them on our message board (see button in left hand column) so that others can read and benefit.
