Applies To:
  • CitectSCADA 7.0, 7.10
  • CitectHMI 7.0, 7.10
  • CitectFacilities 7.0, 7.10
Summary:

In v7.0, it can take 1-2 seconds (project / network dependant) to open a page for the first time. 
After this initial page load, it is much quicker to navigate back to the same page.

However, after applying Hotfix HF700R138169, when I change between pages it can take 1-2 seconds (project / network dependant) everytime I navigate to this page, not just the first time.  

Solution:

This is due to the fact that Citect will not finish displaying a page until values have been returned for all tags on the page (or timed out - #COM).

(Hotfix HF700R138169 ensures that no 'stale' values are mistakenly used. However, as part of this process a Tag's cache is invalidated on a resubscription. This means that the 1-2 second delay evident on a first page load is now noticed every time the page is navigated to.)

If you would like to improve the speed of navigating between pages, 'Background Polling' can be used.

This setting is found as the last option, in the 'Extended options' of the IODEVICE form:

'Background polling' essentially internally subscribes the IOServer to all tags of an IODevice on startup, at a reduced rate (default 30 seconds).
This ensure that the IOServer always has a valid cache for all tags, allowing Client's Subscription requests to be immediately responded to and allow pages to load instantly

When a tag is actually displayed on a page or used in Cicode etc, a client-side subscription is created as usual. This new subscription automatically promotes the tag's pollrate from 30 seconds to the default client subscription rate of 250ms.

This ensures that when the Tag value is actually required, that the data is up to date, and refreshing quickly.

Although this means you are retrieving data for tags that are not necessarily in use, the reduced rate should ensure there is not too much additional load on the system, and in most cases the graphical performance gains are well worth the IOserver overhead.

Note: as Citect uses a Publish/Subscribe method for Server > Client communications, the polltimes mentioned above are the rate at which the IOServer queries the IODevice. Information is still transmitted between the Server > Client by exception, as per the Pub/Sub model.

This is NOT the same as simply having a client subscribe to all tags on startup. Firstly, the polltime is a lot lower (30 sec, not 250ms). Secondly, the 30 sec poll is being done IOServer side only, so there are no additional Client > Server subscriptions, and no additional load on the network.

KNOWN ISSUE: (40339)KNOWN ISSUE: (40339)

 

KNOWN ISSUE: (40339)

 

 

There is one current known issue with using IODeviceControl with 'Background Polling', which has been rectified in v7.0 SPK 1 and v7.10.
The problem is that an IODevice that is disabled with IODeviceControl and that has 'Backgroung Polling' enabled, will not display #COM.
This is not widely used, and as stated, this is already resolved in v7.0 SPK 1.

 

How it looks in the Kernel:

Below is a screenshot of the IOServer's 'Page Table IODevices.Blocks' showing 2 optomised 'blocks', or this shows the internally subscribed tags requesting information from the PLCs.

The Screenshot below shows that there are no active subscriptions during this time.

However, once a subscription is requested, at a scan rate of 250ms:

We can see the IODevice promotes the optomised block to a 250ms pollrate:

 
Keywords:
 

Attachments