SIMATIC WinCC Open Architecture Forum

We are facing an application that will probably have 150.000 physical I/O values being read by a bunch of PLC's. Eventually all these values will end up on a scada screen.
We will need to optimize the communication to the PLC so that we reach the desired update times.

Our PLC (1500 series) will be using the S7+ protocol. This means that we have the following options to reach an optimal communication response:

* Use subscriptions
* 'Pack' the bits into (d)words and use dp functions to extract the bits from the word into dp elements

Does anyone have experience with a WinCC Oa database, running on one server, with (lets say) 200.000 dp functions ?? (Please note that only a low amount of signals will actually change. I'd expect a small amount of changes per second. We have smoothing and time-delays in the PLC's)

Thanks for your answer

share the fun
Frenk Mulder

A dp function itself is similar to a dpConnect.
As long as the input signals are not changing they are not causing any load. A high number of dp functions will only increase the memory usage of the Event Manager.

Best Regards
Leopold Knipp
Senior Support Specialist

Hello Frenk!

In fact the S7+ protocol driver was tested with a high throughput and is also able to handle more than 100.000 addresses. When considering subscriptions and bit-packing on PLC side, you should consider the number of addresses per PLC. The number of PLC variables, that can be subscribed to is limited and ranges from 2.000 (S7-1511) to 40.000 (S7-1518). Generally the subscriptions are a good idea for non-changing address-configuration and for lowering the data throughput from PLC to driver, if the subscriptions are configured as "only-changes".

If you face a lot of single-bit variables in the PLC, you might have to swap to WORD/DWORD variables in order to meet the limitation for subscription variables.

One important advice, especially during testing phase where not all PLCs can be connected online: avoid configuring one big subscription across all/multiple connections, because one not-connected connection disallows the activation of the subscriptions on all involved connections! It is better to use single subscriptions per connection, so that you can activate and deactivate them easily and without negative effects on other connections (concerning subscriptions). At the statistic values of connection you can easily check whether the input addresses are being retrieved via subscriptions ("Unsolicited values per second") or via active polling by the driver ("Read requests per second").

Best regards, Daniel