Help get this topic noticed by sharing it on Twitter, Facebook, or email.

Esuite License runover; How to reduce the number of active view blocks.

The actual difficulty is the View License size which is 300 blocks.
If you run over the 300view blocks then you lose communication to the excess blocks which is only slowly restored.

The OPC maintains a count and a list off blocks actually viewed by the application.
The number is formed by the sum off blocks active in the alarming plus trended blocks plus the ones required on the user screens.
The adding of newly required view blocks on opening a user screen is almost direct.
Changing to another user page adds more required view blocks.
The view blocks which are no longer required remains active for a period of time in the active view list before they disappear and subsequently the counter is reduced.
The number you stated around 250 as being the lowest you could see is about correct.
More of interest is the maximum and the amount of run overs which you can detect using the Licence Utility.

Several methods or approaches can be used to reduce these;
1. Upgrade the license.
Next is 1000 blocks and can be expensive .

2. Reduce the number of alarm blocks
The number of alarmable blocks can be reduced.
The only blocks of interest here are the DigAlarm blocks
additionally some Diagnostic, PID and Totalizers.
For view only blocks to become readily available when the user page is opened I put these blocks also in an AlarmGroup.
But doing this increases the number of active view blocks.

There are 256 DigAlarm blocks with only one input alarmed whilst it can do 8.
Eg. I saw 2 blocks used for detecting either On or Off button pressed.
And 2 or 3 blocks for Level detection etc.
This could be handled by a single DigAlarm block reducing the number of blocks.
In order to do this and not to have an impact on any other view function;

In Lintools Copy the original block and rename it, wire the signals to In_1 to In_2 etc.
Set their Alarm Priorities to 6 or required level.
Rebuild the database.
Create a new Alarm Group and copy all the new blocks to this group.
Create a second new alarm group and copy/paste all other then DigAlarm blocks to this group.
(Easier to copy entire groep and delete the DigAlarms)

First we have to test if the system allows multiple alarms per block to show.
Set multiple inputs into the alarm state.
Check if you have multiple lines of the same block name in the alarm list.
If not manipulate the OneAlarmPerBlock variable in the Project configuration and re-deploy and retry.

This is important since there are quite a lot of alarms for level High and HiHigh and we do not want to miss the HiHigh Alarm!
One could also set the HiHigh alarm priority to a higher number than the Hi then automaticly the Higher priority alarm wins.
If you are happy with this then download the changed database and activate.

Next to do is to modify the alarm set.
Remove the originals group containing the digital alarms and move in the new create groups.
Deploy and check the impact on the view count figure.

3. Actively disable alarm groups.
This depends on the way of operation of your plant.
If sections are alternately in use or not then you can disable alarms from these sections if you group them
You can create buttons with actions to do this as shown in EnableAlarms.Jpg.

So you can check and try things out.

1 person likes
this idea