Traditionally, industrial I/O drivers poll I/O devices sequentially. They ask a question and wait for an answer. Then, they move on to the next device on the polling list. This technique comes from the primitive software of the early PLCs and the fact that local I/O in a backplane can usually be interrogated quite quickly. When distributed I/O first came into use, this technique was carried forward for several practical reasons. First, most networks (and the interfaces that feed them), including RS485 schemes, Devicenet, Profibus and other similar technologies are only capable of handling one message at a time. They send a message and then wait for a reply in their incoming message buffer. Second, the limited bandwidths (polling speeds) put practical limitations on the throughput of the network itself. Putting multiple messages into a buffer would not have yielded higher throughput because the network itself is a bottleneck.

Enter Ethernet – a Mega-speed network controlled by hardware co-processors with multiple message buffers and sophisticated message handling algorithms. An Ethernet controller has the capability to accept a batch of messages and deal with their transmission independent of the main computer that is commanding it. In effect, this co-processor is conducting communications while the main processor is off working on other tasks.

Unfortunately, most industrial I/O drivers that work over Ethernet do not take advantage of this enhanced capability. The "tunneling" technique used by most software takes the message that would have been sent over a serial port or slower network and embeds it in an Ethernet packet. In effect, the Ethernet network is merely used as a high-speed serial port.

SIXNET offers several solutions to multiply the performance of your Ethernet I/O system. If the I/O driver software is written to take advantage of the parallel processing capability, speeds multiply because multiple stations are processing I/O requests effectively at the same time. Such a driver builds a list of questions and does the bookkeeping to track responses. The smarter the polling algorithms the higher the performance of the system. One such I/O driver that uses this technique is the SIXNET Control Room. The IOmap Shared Resource Database efficiently schedules I/O messages to multiple stations, carefully avoiding overloads to any one resource. The scheduler tracks responses and automatically generates timely retries in the event of errors. Software products from vendors such as Citect, Intellution, and of course SIXNET ISaGRAF take advantage of this performance enhancement.

What about network collisions?

There are two answers. In most systems, the required time response is long enough and the network loading is low enough that collisions do not significantly reduce the performance of the system. If your polling time is 50 mS or longer and if your network bandwidth usage is small (which is almost certainly the case with a dedicated control network), occasional retries will happen so fast that they will not be noticeable.

If you need higher performance the easy answer is to use a SIXNET Industrial Switch. By segmenting the network and avoiding collisions, very high performance can be achieved.

What if you are stuck with an inefficient polling scheme in an old style I/O driver?

Again SIXNET has a good answer. Add an ET-GT-ST-1 I/O gateway to the network. This intelligent I/O gateway can efficiently poll other I/O stations and build an IOmap of the collective I/O status. Then, the combined results can be passed to the master as a single block. In effect, this smart gateway looks like a large PLC to the master. Combined with an Ethernet Switch, remarkable real-time results are possible.