The primary role of a PLC is to perform the control logic and communication with its I/O modules. Communicating with Citect or any other application is of secondary importance. Because of this the communication is normally given a lower priority. Also it is quite common that the PLC will only service the communication module at the end of its PLC scan. However this is not true for all PLC's. Other PLCs also limit the amount of data transfer to the communication module to a few words per scan, so it can take several PLC scans to complete a single request. All these limitations will degrade the communication performance of your system.

For example lets assume that your PLC has a scan time of 50ms and it can service all of the communication module requests at the end of the scan. The following timing will occur when Citect communicates to the PLC. Citect will send the request to the PLC communication module over 10Mb Ethernet, this communication time will be very small due to the high data rate of transfer (so lets assume 0ms). The PLC communication module will receive the request and then wait for the PLC to finish the Ladder logic scan. It may wait between 0 to 50ms, on average it will wait 25ms. Once the PLC has completed its scan it will service the communication module request, this will normally be very fast as only a matter of sending data over the PLC backplane to the communication module (so lets again assume 0ms delay). Once the communication module has the data it will send it back to Citect over Ethernet (again assume 0ms). So the entire time will be around 25ms. If Citect is asking for 512 bytes of data you will there for get 1000/25 = 40 packets per second, eg 20k per second transfer (which is 10,000 registers per second).

As you can see the major overhead in this type of system is the PLC scan time. If your scan time is longer your system performance will greatly degrade. In the past with slower serial communication, there was a limitation on how fast you can communicate data to and form the PLC so this tended to be a major factor. However even with serial communication the PLC scan time can have a significant effect on performance. From our experience with developing over 100 PLC drivers we have fount that around 50% of the communication overhead is due to this time. So with a 19,200 baud RS232 link you could get the equivalent of around 9,600 baud of real data (say 1000 bytes per second). As Ethernet is much faster you now see that the PLC scan time is about 99% of the communication overhead.

Another problem you should be aware of is that some PLC have a major restriction communicating over Ethernet or their own propriety network. With a high performance network Citect can send out may requests on the network at the same time. For example in the above example while Citect is waiting for the first PLC to respond it may send many more requests to other PLCs (or the same PLC if it allows this). This allows greatly improved performance as all the delays occur in parallel. However the network and the PLC software must support this type of operation. Some propriety network don't allow this, so while you are waiting for one PLC to respond you cannot send a request to another PLC. So in this case the high performance network bandwidth sits idle. In this case, plain old RS232 can give higher performance than a high speed network. This is the case because if you have RS232 you can setup individual serial channels to each PLC. So Citect can communication to all PLCs at the same time and so get very good performance. Several customer have been shocked in the past after changing their communication method from 19,200 baud RS232 to 1Mb propriety network to find that the performance is slower.

What is the answer:

1. Complain to your PLC manufacture and get them to fix the problem. If they don't want to fix the problem find another PLC which does not have this limitation and buy that one.
2. Some PLCs allow you to provide extra services to the communication module. You can setup the modules to provide more data at the end of scan. Other PLCs allow you to place special logic into the ladder program to service the communication module. By placing this logic in various places in you ladder program, eg a few evenly spaced throughout the program you can improve performance.
3. Some PLCs allow you to setup more than 1 communication module. This may or may not improve the performance. If the PLC gives more service to each new communication module then the system will be faster. If the PLC shares service between each module then it will be the same performance or slightly slow due to extra overhead.
4. If your PLC has serval communication modules then try changing your communication method. If your PLC supports Ethernet or propriety network and RS232 don't think that RS232 is the slow option. In a large number of cases RS232 is the fastest option. This is especially true when you have lots of PLCs, for example over 10 PLCs. This is the case as Citect can communicate to all the PLCs at the same time. Remember a Citect I/O server can support up to 64 serial ports (even under Windows 3.x), and so talk to 64 PLC's at the same time. So at 19,200 baud you can get 1000 bytes per second over 64 PLC will give 64kbytes in total which is faster than some Ethernet PLCs can handle.
5. Some Citect drivers also support separate ports for each I/O device. You should check the Citect online help to see if your protocol driver supports separate port for each I/O Device. With separate ports Citect is trying to work around the limitation of only sending one command at a time as described above. By opening another port on the same communication card, Citect can send another command to a different I/O device while it is waiting for the first one to respond. If you have many PLC's this can greatly increase the performance of your system. This feature is only supported by some drivers, as most drivers don't need this feature or with other drivers it is impossible for Citect to support it (see item 1. above)

So don't be fooled, just because it's Ethernet does not mean it will be fast (it can be fast). The only way to be certain is to test the system with all PLC's attached and running at their required scan times.