Zenon Server crash potentialy because of high number of variables

[Szekelyhidi]

Hello, We are actively working on a Windrafm project that has been divided in several projects.
One of them has aprox. 330000 variables on active communication with S7 driver.
(what is the maximum suggested number of variables in active communication and logging for a snappy system??)
Because we use complex faceplates that include menu bars and several image templates, and the sheer number of variables, we activated the "Permanently read variable" option, in order to get a more responsive screen switch.
This, or maby another factor that I don't know about, has lead to huge "arx" and "aml" files that are used to retrieve hystorical data from the event list / alarm list and trend archiving.
The end result is that when the operator tries to retrieve archived events or trends, the Zenon proces becomes inresponsive, somtimes leading to "exceeded time cycles" witch in term lead to a crash of the system.
I am guessing that this has to do something with the sheer amount of data the processor needs to parse in these encrypted binary files containing historical events / alarms / trends.
(have seen files as large as 400mb)
My question is ... how does one improve performance?

Suggested from the top of my head :
a) .Decrease binary file's used for data and event storage sizes ex: .ARX files *** any way to achieve this ?
b). Partition the project into Several other smaller Projects ?, on several servers
c). Sensible answer from Copadata , if the above does not make sense.

[markclemens]

Hi Szekelyhidi,

Thanks for your post and welcome to the forum!

Best regards,
Mark

One of them has aprox. 330000 variables on active communication with S7 driver.
(what is the maximum suggested number of variables in active communication and logging for a snappy system??)

The maximum suggested number depends on a number of factors. The number of PLCs you have, the type of PLC driver you are using, the number of PLC drivers you are using and the number of connections in each driver. Whether you make use of the priorities in the driver for different polling rates, whether these variables are defined as alarms, or are for display purposes only, etc. etc.

Because we use complex faceplates that include menu bars and several image templates, and the sheer number of variables, we activated the "Permanently read variable" option, in order to get a more responsive screen switch.

When this option is activated for all variables, the drivers may also be reading variables every cycle that are not used anywhere in the project. You can look at using the option "keep update list in memory" option in the driver configuration, in combination with polling priorities for different variables to continue reading variables from the PLCs that are already used once before. Only the first time a screen is opened, it would take longer.

In general, you probably should also check out the log files of the diagnosis server to ensure that there are no communication errors. The communication details variables can give you an idea about the configured polling cycle and the actual polling cycle required to read all the variables for this driver from the PLC.

This, or maby another factor that I don't know about, has lead to huge "arx" and "aml" files that are used to retrieve hystorical data from the event list / alarm list and trend archiving.
The end result is that when the operator tries to retrieve archived events or trends, the Zenon proces becomes inresponsive, somtimes leading to "exceeded time cycles" witch in term lead to a crash of the system.
I am guessing that this has to do something with the sheer amount of data the processor needs to parse in these encrypted binary files containing historical events / alarms / trends.
(have seen files as large as 400mb)
My question is ... how does one improve performance?

Large .arx files may be caused by an incorrect archive configuration. When you are using archives recording spontaneous value changes and close the archive after a short time span, large .arx files could indicate many many value changes you probably did not even intend to record in this archive.

Large .aml files normally are the result of enormous amounts of alarms occurring. You would probably want to look into this.

The system of course should not crash but when it does it is important to look into the reason why this is the case.

Suggested from the top of my head :
a) .Decrease binary file's used for data and event storage sizes ex: .ARX files *** any way to achieve this ?
b). Partition the project into Several other smaller Projects ?, on several servers
c). Sensible answer from Copadata , if the above does not make sense.

These are all valid options, but without knowing more details, there is no single golden suggestion that will guarantee to solve all the issues.

Rather would I suggest contacting your local COPA-DATA support representative, to look into each of the issues, then from the sound of it, there could be multiple.

Best regards,
Mark

[Szekelyhidi]

Hi Mark,

The driver used si S7TCP23, and indeed the poll times - priorities are not being utilised to their full potential.
But , to my knowledge, this does not influence archiving and the size of ARX, CEL and ALM files, them being influenced by archiving cycle times(for ARX), and ... actual changes in boolean variable states(for AML and CEL).
(and no, there is no high speed toggling going on (filtered out by S7 PLC))
The poll time shall most likely bring some advantages to relieving the CPU of handling irrelevant Network communication.

But the fact remains that there are a lot of AlarmS messages that are recieved spontaneously, and as you might have guessed, we are in the commissioning phase.
Being new on the project, I now managed to do a thorough analysts and came to the realisation that the project needs to split.
The big AML and CEL files are inevitable because of testing.
Deleting them is not an option for the moment, but we will see how that goes.
This is a Sicam 230 Wind Platform project called Borwin, and to my knowledge, it has passed through your company for optimisation/consulting.

""When this option is activated for all variables, the drivers may also be reading variables every cycle that are not used anywhere in the project. You can look at using the option "keep update list in memory" option in the driver configuration, in combination with polling priorities for different variables to continue reading variables from the PLCs that are already used once before. Only the first time a screen is opened, it would take longer. 
In general, you probably should also check out the log files of the diagnosis server to ensure that there are no communication errors. The communication details variables can give you an idea about the configured polling cycle and the actual polling cycle required to read all the variables for this driver from the PLC. ""

^^ Thank you for the info above. must look into that.

Unfortunately, politics here do not allow me to reach out to the zennon consultant in charge. That is why I tried my luck in the Forum.
Best regards, 
Vili

[markclemens]

Hi Vili,

Thanks for the details. Considering the complexity of the topic(s), it is not something that is easily answered through the forum.

Specific questions of course, you can always ask here Please note however, that the forum is not an official support channel and there are no guaranteed answers. For this, it really is best to contact your local COPA-DATA / SICAM230 support representative.

If the runtime in fact crashes, of course this is something that should not happen at all and requires further analysis and investigation where your local support can help you best.

Regarding the .arx files, the size depends on a number of factors like the total number of variables per archive, the scanning type of archive (cyclic, spontaneous) and the closing cycle for the base archive and any aggregating (following) archives.

Alarm_S messages can be a reason for large .AML files, but to be sure, you would have to look at the unfiltered alarm list to see which alarms were generated for some of the larger files (time periods).

Splitting a project of course is always an option but not always simple and should be carefully considered, especially when you already are in the commissioning phase.

Best regards,
Mark