High speed data acquisition

[bhavna]

I have a general query.

If my hardware provides data at 1KHz, is it possible to acquire, process & archive data at that speed in WINCCOA for ~200 analog channels?

[leoknipp]

do you mean with data at 1KHz that 1000 value changes / second from the hardware are processed for every signal?
If you have 200 of these signals it will be an amount of 200.000 value changes / second.

Does this amout of data occur all the time or is it just a peak load for a few seconds?
Which hardware/PLC is used?
Whiich WinCC OA driver is used?
Is there are any smoothing of values made before they are send to the WinCC OA driver by the hardware?
Shall a smoothing be made in the driver before data is send to the event manager?

Best Regards
Leopold Knipp
Senior Support Specialist

[bhavna]

-Yes, that many changes per second.
- The data load is just for few minutes, where we wish to do post mortem analysis or study the behaviour of some power supply.
- Hardware can be (still not got one) embedded real time controller like CompactRIO from NI. There are multiple stations with 8-16 channels each.
- About WINCCOA driver: that is what my question is. Should I go for a WINCCOA system or think of something else to bring all data on a PC for analysis. The real-time system itself has some flash in it to store the data samples which may later be needed to transferred to PC.
- no smoothing involved anywhere.

My aim is to realize a high speed(of the order mentioned above) data acquisition with WINCCOA.

[Prasanth.m@siemens.com]

Dear

Can you please let me know the maximum allowed value changes per second when i am using S7 plus TCP/IP protocol.

With regards,
Prasanth M

[leoknipp]

The maximum number of value changes per second is not a fixed value for a WinCC OA system.

What data load your system is capable of depends on some factors:
-- WinCC OA version
-- Hardware
-- Operating system
-- Project configuration (single project, redundant project)
-- Configuration of the data model
-- Archiving
....

In case of a PLC connection also the PLC can be a limiting factor, e.g. if the defined poll/data rate connect be handled by the PLC.

Which amount of data (value changes / second) do you expect as constant load in your project?

Best Regards
Leopold Knipp
Senior Support Specialist

[roell.f]

dear forum,

below you will find what we experienced during our "high speed project":

PLC: Siemens S7 CPU 317

PC:

• Intel Core i7-4650 CPU @ 1.70 GHz 2.30 Ghz
• RAM: 8 GB
• Windows 7 64-bit

WinCC OA:

• version: 3.15

project configuration:

• single, non redundant project

S7-protocol: Time Stamp Push Protocol (TSPP):

• when using polling the minimum poll time is 100 ms.
• when using TSPP the time stamp is generated by the PLC
  if you use a DPE connection for writing into archives, that PLC time stamp is written into the archives.
  if you use a statistical function for writing into archives, a time stamp from the PC is written.
  in case you want see both in your trends, make sure that PC and PLC are in sync. for that purpose you can use an NTP server (e.g. https://www.meinbergglobal.com/english/sw/ntp.htm) running on the PC providing his time to the PLC (client).

signals:

• count: 1000 (total)
• type: bool and float mixed
• source: simulation generated by PLC
  • for floats: saw tooth signal
  • for bools: bit toggler

archiving:

• floats and bools: written unfiltered into value archive using DPE
  connection.
• floats: additionally written filtered with statistical function
  "average value" with interval 1 second.
• example from value archive:

• Code: Select all

  :_offline.._stime, :_offline.._value
  
  2017-12-05 15:35:46.001, 430
  2017-12-05 15:35:46.039, 434
  2017-12-05 15:35:46.085, 439
  2017-12-05 15:35:46.144, 444
  2017-12-05 15:35:46.232, 453
  2017-12-05 15:35:46.271, 457
  2017-12-05 15:35:46.317, 462
  2017-12-05 15:35:46.376, 468
  2017-12-05 15:35:46.463, 476
  2017-12-05 15:35:46.502, 480
  2017-12-05 15:35:46.548, 485
  2017-12-05 15:35:46.608, 491
  2017-12-05 15:35:46.695, 500
  2017-12-05 15:35:46.734, 503
  2017-12-05 15:35:46.779, 508
  2017-12-05 15:35:46.839, 514
  2017-12-05 15:35:46.926, 523
  2017-12-05 15:35:46.965, 527
  2017-12-05 15:35:47.011, 531

for a period of 60 seconds we found 1057 values in the archive, i.e. the average intervall between two samples was 57 milliseconds.

during our tests the CPU and disk load of the PC was always low.

we think the limiting factor was the PLC - not WinCC OA

best regards

frank

[leoknipp]

frank röll wrote:

if you use a DPE connection for writing into archives, that PLC time stamp is written into the archives.
if you use a statistical function for writing into archives, a time stamp from the PC is written.

archiving: floats and bools: written unfiltered into value archive using DPE connection.
floats: additionally written filtered with statistical function "average value" with interval 1 second.

we think the limiting factor was the PLC - not WinCC OA

I had a look at the description of the test setup.

If I understand it correctly you have used 3 dp elements.
1 dp element with the _address config to receive values from the PLC
1 dp element with a dp function copying the value received from the PLC (in your example called "DPE connection")
1 dp element with a statistical dp function to calculate a 1 second average for the value received from the PLC (in your example called "statistical function")

Why aren't you archiving the dp element with the _address config?
Using a dp function just to copy the value is not a common use case and produces extra load/messages.

What is the use case of a calculating a 1 second average value?

Best Regards
Leopold Knipp
Senior Support Specialist