Today is...
Saturday, February 24, 2018
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A tutorial introduction to programming using the QuickBuilder Programming Environment.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Centum VP
Upgrading from Centum VPR4 to R6.

Hi All,

we want to make an upgrade from Centum VPR4 to R6.

Are we obliged to change CPUs from AFV10 to AFV30? since we have the idle time of current CPUs too short.

what we should do to increase the idle time?

thanks in advance

One factor which significantly affects the idle time is the number of function blocks running on medium or high-speed scan period.

The Basic scan, which has a period of 1 second, is adequate and suitable for most applications. If you put too many blocks on high-speed scan, the idle time drops notably.

Thank you Mr.Mehmoud,

We have already tracked this way but it seems that most of our function blocks are tuned at basic scan time.

we have 15 FCSs, only three which are under 11 seconds.
more questions please:

Are long trem trends (1 second) affecting the Idle time?
Are daily report affecting also?
Are communication (remote nodes, other subsystems..) affecting?

thanks in advance.

1-second trends should not affect the idle time so much because each FCS is inherently protected by maximum number of high-speed trends (1 or 10 sec) it can support. So even if you specify large number of trends on 1-sec recording, only maximum supported number of trends will be recorded and pens beyond that number will be simply ignored (appearing blank in trend windows).

You can also rule this out by disabling trend recording temporarily. Just export the trend configuration files for backup and clear the trend blocks on all HIS fetching the trend data. If this is the real problem then the idle time should improve after disabling trends. But be careful, clearing the trends data will erase your trend history unless you back up the long term trend files. I wouldn't advise it unless you are proficient with the software or losing the recorded trend history is not a big deal.

As far as "Long-term" functionality is concerned, it doesn't affect the idle time because maintaining long-term history is a function of HIS, not the FCS. It is only the high-speed trends (1 or 10 sec) which may or may not affect the idle time, even if the HIS fetching the data does not have the long-term history package.

Daily reports don't affect the idle time. They also fetch the trend and closing data from HIS (not FCS) and usually run at a specified time or on demand.

May be your FCS is actually heavily loaded with IOs and subsystems. But still, 11 second idle time is too low. I have never seen it even on moderately loaded FCSes.

Gentlemen,

1. Yes the Long term trend of 1sec to be minimized.

2. Daily report usually takes the long sampled data, but if you have snap shot values of 1 sec definitely will load the CPU.

3. Many Sub system modules like ALE111/ALR121/ALP shall affect the AFV10D CPU Idle time. It is also true that many remote nodes too have impact on the idle time.

Remarks:
In all probability a better designed system will have improved CPU idle time. Nevertheless the current idle time of your AFV10D shows a real need of higher version CPU or Controller I.e.AFV30D WHICH ALSO WILL HELP YOU TO MEET FUTURE ADDITIONS ON applications S/W and h/w.

Good Luck!