General Configuration
- Last UpdatedJul 05, 2023
- 7 minute read
Use the General tab to configure general aspects of the ViewEngine object, such as startup options, historian options, and scripting options.
|
Editor Option |
Associated Attribute |
Description |
Run-Time Access (Supervisory, User, Read-Only, None) |
|---|---|---|---|
|
Engine startup type |
Engine.StartupType |
The Type of startup for the object the next time startup occurs: Auto, SemiAuto, or Manual. For an automatic startup, the ViewEngine starts automatically in the last check-pointed scan state. A semi-automatic startup is the same as an automatic startup, except that the Engine starts in an offscan state. For a manual start, the ViewEngine must be started using the System Management Console. |
Supervisory, User |
|
Restart the engine when it fails |
Engine.RestartOnFailure |
If enabled, the ViewEngine object will automatically attempt to restart if a failure occurs. A failure to start is defined as a ViewEngine object failing within five minutes of startup. Therefore, if an engine operates longer than five minutes and then fails, and this option has been selected, three subsequent attempts will be made to start the engine. If an engine fails to start three times in a row, within five minutes, no more attempts are made to start it. |
Supervisory, User |
|
Scan period |
Scheduler.ScanPeriod |
The period of time, in milliseconds, in which the ViewEngine object executes all onscan hosted objects in a sequential order. This is a single thread of execution that represents the desired rate of execution for each of the hosted object. If the time to execute all objects is shorter than the scan period, the remaining time is used by the ViewEngine object to process outgoing requests, incoming requests, and checkpoint snapshots. If the time to execute all objects extends beyond the scan period, a "scan overrun" occurs, and the next execution period will not start until the beginning of the next scan period. You may want to use a short ScanPeriod to minimize the latency of the values displayed by the hosted ViewApps. |
Supervisory, User |
|
Enable storage to historian |
Engine.Historian.Enabled |
If enabled, the values for attributes that have historization enabled will be stored to the specified historian. |
None |
|
Enable Tag Hierarchy |
Engine.Historian.EnableTagHierarchy |
If enabled, the model view is automatically replicated to the Historian node associated with the Galaxy. You can control this behavior at run time without undeploying and redeploying the engine of any affected objects. |
Supervisory, User |
|
Historian |
Engine.Historian.Connection |
The string to use for the connection to the historian. For the Historian, this is the node name. If two Historian Servers are configured as partners, the node identified by this string becomes the primary historian for this engine. The partner information is configured and maintained on the Historian Server. Click the ellipse button to browse for the historian on the network. |
Read-Only |
|
TCP Port |
Engine.Historian.ConnectionTCPPort |
The TCP port on the Historian Server node to which history data will be sent. The TCP port is configured when the Historian Server is installed. The default is 32565. |
Read-Only |
|
Enable compression |
Engine.Historian.CompressionEnable |
If enabled, history data is compressed before it is sent over the network to the Historian Server. This is used to reduce network utilization, but enabling this setting will increase the CPU load. |
Read-Only |
|
Throttling network bandwidth |
Engine.Historian.BandwidthLimit |
Specifies limit of bandwidth usage, in kbps, for network communication used by HCAL when communicating with the Historian. A value of 0 disables this feature (default). For more information on estimating your bandwidth needs, see the performance and sizing recommendations for the Historian Server in the System Platform Installation Guide. On networks with limited bandwidth (for example, 256 kbps) you may want to keep half of the bandwidth available for other traffic, so you would set this value to 128 kbps. Consider when the historian connection is lost, and store-and-forward data has accumulated on AppEngine nodes. When the connection between an AppEngine node and historian is restored, all the store-and-forward data is sent at once, and may use the entire network bandwidth (on a slow network) and cause the AppEngines to again lose communication with the Historian and go into store-and-forward data again. By setting a limit here of 2/3 the total bandwidth, this problem of AppEngines going in and out of store-and-forward can be avoided. This limit applies to all history-related communication, including tag creation, sending real-time data, sending late data, and sending store-and-forward data. |
Read-Only |
|
Wait to send incomplete packets |
Engine.Historian.BufferAgeLimit |
Specifies the maximum time, in milliseconds, for keeping a partially-filled Historian Client Access Layer (HCAL) buffer before sending it to the Historian Server. If the buffer is full, then it is sent immediately, regardless of any value configured in this field. If you have fast-changing data, this setting is irrelevant. If you have slow-changing data and limited network bandwidth, you might want to increase this value so that you have less "chatter" on the network. The default is 1,000 milliseconds. Valid values are between 1,000 and 30,000 milliseconds. |
Read-Only |
|
Pre-processing buffer size |
Engine.Historian.BufferSize |
The total size, in MB, of all buffers used by Historian Client Access Layer (HCAL). The default and minimum value is 8. If you have very high data bursts, then you should increase this value. If this is too low, data loss occurs and error messages related to buffer overflows appear in the ArchestrA Logger. Increase this value in increments of 10 MB. |
Supervisory, User |
|
Store forward threshold |
Engine.Historian.StoreForwardDeletionThreshold |
The size, in MB, of free space to reserve on the HCAL store-and-forward disk. The space designated will not be used during store-and-forward. This value cannot be a negative number. |
Read-Only |
|
Store forward minimum duration |
Engine.Historian.StoreForwardMinDuration |
The minimum duration, in seconds, for HCAL to function in store-and-forward mode. HCAL will function in store-and-forward mode for this length of time even if the condition that caused HCAL to function in store-and-forward mode no longer exists. |
Supervisory, User |
|
Maximum time for scripts to execute |
Engine.ScriptExecuteTimeout.Limit |
The time, in milliseconds, allowed for any synchronous script primitive to execute before an alarm is raised on that script primitive. This timeout applies to script primitives attached directly to the AppEngine object, as well as to ApplicationObjects hosted by the AppEngine object. Note that configuration security means that this attribute can only change when the AppEngine object is offscan, thus allowing the optimization of the script engine, since it only needs to read the attribute once when going onscan. The maximum value is limited to the Scheduler.ScanPeriod for the AppEngine object. |
User |
|
Maximum asynchronous thread count |
Engine.AsyncScriptThreadMax |
The maximum number of asynchronous script threads that can be executing simultaneously. |
Read-Only |
|
Checkpoint period |
Scheduler.CheckpointPeriod |
Checkpointing saves run-time attribute values. The checkpoint period is the time, in milliseconds, at which checkpointing is performed. The default checkpoint period is 10,000 ms. If set to 0, the checkpoint period defaults to the scan period, but may occur at a slower rate (it is done as fast as possible as a background task). The minimum checkpoint interval for retentive attributes is 10,000 ms. Retentive attributes are defined as those attributes configured as calculated retentive, or object- or user-writeable. If the checkpoint period is set to less than 10,000 ms, retentive attributes will not be saved at every checkpoint. For example, if the checkpoint period is set to 4,000 ms, retentive attribute values will only be saved at every third checkpoint (4,000 x 3 = 12,000 ms). Retentive attributes retain the last value set during run time, and the run-time value is saved across redeployments. Non-retentive attributes revert to their configured values at redeployment. |
Supervisory, User |
|
Checkpoint directory location |
Engine.CheckpointPath |
The path where the checkpoint files will be located. If you do not specify a location, the system default path will be used. If the specified location is not accessible, a warning will be logged. If the location you specify does not currently exist, it will be created. You cannot use a virtual drive or a UNC path for the checkpoint directory location. |
Read-Only |
|
Alarm throttle limit |
Engine.AlarmThrottleLimit |
The limit for the number of alarms per second that can be raised by the object before throttling occurs. If set to 0, alarm throttling is disabled. |
User |
|
Statistics average period |
Scheduler.StatsAvgPeriod |
The frequency, in milliseconds, that averaged attribute values are updated. This value must be greater than or equal to the scan period. The average is a running average; that is, values are accumulated for an attribute over the period of time set for this attribute. The value of this attribute affects the run-time values at any given time of all other attributes of the same type of object that are averaged and can be used to "slow down" the updating of the cycle-oriented statistics. |
Supervisory, User |
|
Maximum input queue size |
Scheduler.InputQueueSizeMaxAllowed |
The maximum size for the object input queue. The default is 16 MB. An object's input queue receives all system level messages, such as publish packets, heartbeats, gets, sets, and so on. These messages are then processed by the system. The input queue size grows and shrinks over time. Should the input queue grow to its maximize size, messages are not queued until messages in the queue are processed, making room for additional ones. Valid values are 2 through 128. |
Read-Only |
|
Engine failure timeout |
Engine.EngineFailureTimeout |
The amount of time, in milliseconds, that the engine can run without notifying the bootstrap of its health. After this time elapses, the EngineFailureAlarm attribute is set TRUE in the WinPlatform object. Be sure that you specify a time long enough to accommodate the completion of any engine-related actions that might prevent or delay the bootstrap notification (for example, cascade deployment of objects with a large number of scripts). The minimum timeout the system allows at run time is 55000 ms. If a shorter timeout is configured, the configured value is ignored and the object will use the 55000 ms minimum when it is deployed. |
Supervisory, User |
|
Maximum number of consecutive data notification failures allowed |
Engine.DataNotifyFailureConsecMax |
The number of consecutive data change notification failures that will be allowed before the subscription is stopped by the publisher engine. |
Supervisory, User |
|
ViewApps are Read Only |
ViewAppsReadOnly |
Boolean value to set whether or not a ViewApp will be read-only at run time. This value can only be changed from within the Object Editor. To change the value, you must first undeploy the ViewEngine. If false, users will have the ability to change attribute values in the ViewApp at run time. If true, the ViewApp and its attributes are read-only. The ViewApp must be assigned to a ViewEngine for this attribute to affect the writeability of the ViewApp. |
Writeable at config only |