The following notes offer best practices guidelines on how to efficiently use the CygNet global Facilities and Points objects to script facility and point data and caching of that data.
There is not a one-size fits all model. A good understanding of how the facility and point data is going to be displayed across your CygNet Studio screens is crucial in building the best usage method.
See the following subsections for more information:
The UpdateNow method and the ResolveNow method are two methods that can be used for updating CVS data. There is a limited set of PNT configuration data contained in CVS data records, while the bulk of all point configuration items are in the PNT configuration records.
| Method |
Function |
Usage Notes |
|---|---|---|
|
UpdateNow |
Updates all items in the cache. |
Calling UpdateNow is not always an indication that the entire cache needs updating. A check will be performed to determine if an update is necessary. See CxScript.Points.UpdateNow and CxScript.Facilities.UpdateNow. |
|
ResolveNow |
Updates all items in the cache that have not yet been updated. |
ResolveNow is more efficient than UpdateNow if the cache is partially updated, since already updated items will not be updated again. For example, issuing ResolveNow on a point that has already been updated will not update the CVS again. See CxScript.Points.ResolveNow and CxScript.Facilities.ResolveNow. |
Calling UpdateNow and ResolveNow against facility or point configuration data will essentially result in the same outcome.
In addition, you can force an immediate background refresh using the following enumeration constants:
Global objects are those objects provided in CygNet Studio and the HSS without the need to declare them. You can use global objects for situations where multiple screens are calling for the same data.
Although method calls to a limited Points object will be more efficient than that same call against the global Points object, there are three methods that are exceptions:
The above methods do not interact with the cache and are executed against the entirely of the specified point service. Since each query provides the full context for the requested information, the methods will not refresh data from services unrelated to the query being performed. There is no benefit in creating a separate Points object to issue these specific calls, so calling them from the global Points object is sufficient.
However, calling the UpdateNow method on the global Points or Facilities objects can have adverse effects:
A method that is useful but is often overlooked and under-utilized is TheView.GetPoint method. If a screen object has a point associated with it, it is more efficient to use TheView.GetPoint method than to use CxScript.Points.Point or a separate Points object call. This is especially true when requesting point data about a CygNet Studio tool explicitly from an event handler for that same tool.
Using TheView.GetPoint method is preferable to using the global Points or Facilities objects for configurations that do not share many points or facilities across screens. As an example, if a CygNet Studio screen contains various objects and you want to use those same points in a script on the same screen, you could use the global Points object or create your own local points object to get the data you want. You can also use TheView.GetPoint method. Since the screen has already done the work to resolve the point, using TheView.GetPoint method will not introduce additional messaging on the network. This method takes in a point tag as a parameter. If the object is configured to be a templated object (only the UDC is configured, while the Facility and Site.Service are configured at runtime), then using the Facility Tag String format for the tag string is recommended.
Alternatively, if there are many points and facilities used across screens but the system is divided into several sites, consider a caching approach that has one set of cache objects for each site instead of one per screen. See the Persist File section for more information.
When creating a points object or a facilities object in script, the default behavior is to cache the results to a common local persist file. The local persist cache file is created or updated when the object is destroyed and/or when CygNet Studio closes. The next time the object is created it will use the common cache file as a starting point. If this cache file has items in it already, calls for UpdateNow or ResolveNow will be based on more items than you may anticipate.
There are various scripting methods available to get point data that takes a tag string as a parameter. Examples include Points.Point, TheView.GetPoint, and CxHmiGrp.CxGrpGrid.GetPointAttributeForTag. The tag string format used matters greatly because the data is cached in the form in which it was requested and choosing the wrong one can negatively impact performance.
Since most of the CygNet Studio screens used are templated screens, various caches are using the Site.Service::Facility.UDC format in the cache. In order to take full advantage of that cache result, that format should be used when making any point requests. Otherwise, if a long tag string format is constructed from Site.Service, Facility, and UDC and used in requests, the cache is not being used in the most efficient way, which can slow performance.
As a good rule of thumb, use the tag string format that closely matches the data you have. For example, if you know the facility ID and UDC, then use the Facility Tag String format (Site.Service::Facility.UDC). If you know the LongID, then use the Long Tag String format (Site.Service:LongID). Conversely, do not construct a LongID from a facility ID and UDC and use the Long Tag String format.
|
|
|
