Performance issues for the SIX driver

Support | Order Placement | ProScada Home Page | Download Demos

Performance Issues for SIX Driver

The SIX Driver, uses a Multi-Tasking IO system which means that all the PLC devices are polled simultaneously. Because the Ethernet network has a much higher bandwidth than the PLC's are capable of using, the PLC's themselves are the limiting factor NOT the SCADA or the network.

The SIX Driver Communicating to a S5 Series PLC

Before describing the performance that this driver is capable of and how to achieve it we must state that the Siemens H1 system is extremely sensitive to the configuration of all the Communication jobs in the CP143. The bottleneck (limitation) is the CP143 itself, not the SIX driver or the Ethernet network

On a test PLC (135u 928b) configured with a minimal PLC program the peak throughput is 26 pollrecs per second (block length < 240 words). If another connection is configured and another device is created in the SIX config with the same Ethernet address we get upto 32 pollrecs per second. The 32 messages per second appears to be the limit of the CP143 card. Of course this does not limit the SIX driver - if you configure another PLC similarly you will get 64 messages per second in total.

The following are some tips on optimizing comms

If you have PLC to PLC send & receive jobs being processed every scan cycle You will Kill Your SCADA comms to the SIX Driver !! I have seen systems with three or four jobs being processed every cycle and the poll rate in the driver is LESS that 1 pollrec per second ????. You must slow down your PLC - PLC comms to give the SIX driver more of the limited resources on the CP 143.

It is recommended that you put the PLC - PLC send & receive pairs in the timed OB’s (OB 10 - OB 16) e.g. if you have 3 send receive pairs use the 100ms OB and increment a counter every OB scan, if the Counter = 1 perform job 1 etc. reset counter to 1 when C = 3.

Call the Send all , receive all blocks for the SCADA every cycle.

We have observed that if the COM 143 configuration software is using the CP143’s serial port, your pollrate will roughly halve. It is assumed that programming the main CPU via the Ethernet network will have the same effect. This is another indication that the CP 143 cannot handle very heavy loads.

Do not use data blocks longer 240 words if you are not using 241-255, the CP 143 is fragmenting the data into 512 byte Ethernet packets, regardless of the TPDU size setting.

The driver tick period should be set to 1 (10 ms) the default is 5 (50 ms), you can perform this manually in Mission control or set the driver to start with this setting by adding the following string to the IOCTRL.EXE command line in SCU->startup

/SSIXP1

The other major effect on the comms is a noisy network which causes Re acks & data retries, you can see these by using the ST pollrec & the SIX debug Graphic dynamo provided. If you use an AUI-UTP(10 base T) Transeiver in the CP143 and 2m of UTP cable to a UTP hub in an office environment you get almost no retries, on site with Siemens fanout boxes , & long cables I have seen upto 20 % retries.

The SIX Driver Communicating to a S7 Series PLC

The S7 Series is far easier to configure & is slightly faster than the S5 being able to achieve 30 pollrecords per second per PLC. If you configure two devices to the same ethernet address performance reaches 40+ pollrecords persecond (to one PLC).

The maximum pollrecord size on the S7 is 220 bytes. Usually a Analog takes 2 bytes so we can read 110*30 analogs per second. Digitals are packed 8 to a byte so you can read 8*220*30 digitals per second. Of course If you have several PLC's theses figures will be much higher.

Like the S5 the S7's performance deteriorates when several PLC-PLC operations are performed each scan cycle.

The Driver will go a little faster if you add another device with the same ethernet address & split your pollrecords in 2 between these two.

the S7-300 PLC is quite slow, especially if it has a large program. We have seen poll rates as low as 3 pollrecords per second. This is easy to test, just put a "BE" command at the top of OB1 & the pollrecs per sec in mission control will go up. The S7-400 is not so bad. A solution to this is to speed up the OB1 cycle time of the PLC by splitting the program into smaller pieces & every piece executes every alternate cycle. Also move code that is not cycle sensitive into the "Backround" priority OB90.

See Tips on Optimising Most Drivers