Removing trends on AC450 for Advant OS
We have a system consisting of an AC450 controller and 800xA top system.
Previously the top system consisted of Advant OSs connected to the same AC450 controller.
As the controller load has increased over time due to expansions etc. we are evaluating measures to decrease to controller load to a more comfortable number. Some measures have already been executed (increase cycle time for a number of control modules, and even whole PC programs), but still the controller load is above 90%.
The next step we've discussed is to remove trends from the controller itself since we no longer use advant stations, but 800xA which utilize the IM for trending. We've decided that the advant station trends no longer are necessary, and thus removable.
The questions is then: how does one execute such a task?
could one for instance just kill a corresponding task which runs in the controller, or
is it necessary to take a more cumbersome road (I'm thinking about the IMS/AEH and TTD logs in particular)?
Voted best answer
Very well spoken by Rob!
Comment: use "ACT DCTA100" (one hundred) to resume TTD operation after a temporary stop of the DCTA200, 500 and 600 tasks. The 100 task is a startup task that spawns the other and then abort itself.
Remember to set LOG_IMPL to 0 to prevent automatic startup (in case TTD tasks should remain stopped). This property can be FINS & MPRO:ed in runtime.
Use 9000, 3000 or 1000 ms when subscribing via OPC with 9000 being the leanest.
To quickly "convert" TTD logging into OPC logging in 800xA do as follows:
1) Stop Basic History service
2) Upload TTD logs (tasks must be running in controller)
3) Use BDM to bulk out the logs. Save .xlsx file.
4) Delete the logs (use the Delete button in the template, or the Log Summary aspect)
5) Delete the TTD log templates from the controller object
6) Create an OPC log template. Use 9s Min Time in primary log.
7) Modify the .xlsx sheet - replace all template name(s) with new OPC template.
8) Save sheet back to system to create new log configuration aspects.
9) Measure controller base CPU load (Idle + DCSAxxx tasks)
10) Start RTA Board maintenance tool - enable system messages to screen
11) Start Basic History service
12) Repeat controller load measurement - calculate difference from base load
System messages in RTA Board maintenance at startup of logging may advocate adjustment of Min Time (9000 being most lean to controller, do NOT go above this figure) and reduction in number of logs.
A 90% CPU load on an Advant 400 series controller is OK ! The controller is not overloaded.
When CPU load is consistently over 95 / 96% than the Online Builder becomes sluggish to use and online changes are slow, but the controller will continue to function quite well. If the CPU load goes much higher the the TTD logging tasks will die and need to be restarted occasionally.
So when you say CPU load is "over 90%" - by how much ? If it is spiking every so often at 100% because of TTD logging, then this is not usually a problem. You can probably help this by increasing the allowable sample delay (SA_DELAY on the TTD Log DB Element) in recording a value.
Before you go to a lot of work, first check what is the real CPU load without TTD logging active in the controller.
1. Briefly Kill the DCTA logging tasks (DCTA600, DCTA500, DCTA200)
2. Graph the CPU loads for around 1 minute
3. Activate the DCTA200 task again to turn on TTD logging
This will give you an idea how much CPU is being used by logging, or even if logging is mis-configured.
To permanantly deactivate TTD logging in the controller you need to deactivate the TTD_Logs (LOG_IMPL = 0 on the TTD Log DB Element) and INIT the controller.
Note that changing TTD logs to OPC logging can make things worse, not better. You MUST FOLLOW THE RECOMMENDED SUBSCRIPTION TIMES and only log properties that support cyclic subscription.
Sincerely, thank you guys for the in-depth answers!
The controller load was in average in the 94-96% range, and occasionally for short periods (of seconds) hitting peak at 100% load.
I did a task load analysis, which revealed that DCTA200, DCTA500 and DCTA600 combined comprised 11% task load.
I did like Rob suggested and stopped the DCTA tasks following a new task load analysis. The result was as expected; lowering the total load about 10-11% and depicting 0% load for all the DCTA tasks.
You certainly have a point about the future and further expansions. We'll look into that.
Another issue has surfaced after i stopped the DCTA tasks. The mentioned node (node 14) shares IMS with another node (node 10) which are running its DCTA tasks. Now we observe that trends above 2 hours are incomplete for node 10 since the time i stopped the DCTA tasks for the other node (node 14). An example of this is depicted in the attached figure.
For our node 10 the TTD logs seems to function since 2 hours trending works fine.
We believe that the misbehaviour for the longer trends is related to the IMS. Since we stopped the DCTA tasks on node 14 we've done nothing on the IMS end. Neither have we set LOG_IMPL = 0 (mainly since this is related to TTD logs as i understood).
Do you have any idea on what may cause this trend misbehaving?