ACEReference ElkSP4

OASyS DNA®
ACE Reference
www.schneider-electric.com
Legal Information
The Schneider Electric brand is the sole property of Schneider Electric Industries SAS. Any
trademarks of Telvent Canada Ltd. or Telvent USA, LLC referred to in this guide are the sole
property of Telvent Canada Ltd. or Telvent USA, LLC. The Schneider Electric brand and
trademarks may not be used for any purpose without the owner's permission, given in writing. This
guide and its content are protected, within the meaning of the applicable copyright and trademark
laws and international conventions. Unless otherwise agreed in writing, you may not reproduce all
or part of this guide on any medium whatsoever without the permission of Telvent Canada Ltd. You
also agree not to establish any hypertext links to this guide or its content. All other rights are
reserved.
© 2016 Telvent Canada Ltd. All rights reserved.
ACE Reference Table of Contents
Table of Contents
1 ACE Introduction.....................................................................................................................................5
1.1 Product Description........................................................................................................................6
1.2 Product Pieces...............................................................................................................................8
1.3 Execution Model.............................................................................................................................9
1.4 Security.........................................................................................................................................11
1.5 Registry Variables.........................................................................................................................11
1.6 Error Messages............................................................................................................................12
1.7 Arbitration States of Multithreaded ACE.......................................................................................16
2 Aceconfig Table.....................................................................................................................................19
2.1 Aceconfig Row Edit: Main Tab......................................................................................................19
2.2 Aceconfig Row Edit: Trigger Configuration Tab............................................................................21
2.3 Aceconfig Row Edit: Input Tab......................................................................................................22
2.4 Job Scheduler Records................................................................................................................25
2.5 Record Fields and Flags...............................................................................................................25
2.6 Output Record Flags....................................................................................................................28
2.7 Types of Execution.......................................................................................................................30
2.8 Disabling and enabling an ACE record.........................................................................................31
2.9 Records Not Executing.................................................................................................................32
3 Using the ACE Summary Window.........................................................................................................33
3.1 Using the ACE Control dialog box................................................................................................34
4 Code Editor............................................................................................................................................36
4.1 Menu Bar......................................................................................................................................37
4.2 Code Editor Toolbar......................................................................................................................42
4.3 Output Grid...................................................................................................................................42
4.4 Using the Project Explorer............................................................................................................43
4.5 Tab Control...................................................................................................................................44
4.6 Intellisense....................................................................................................................................45
4.7 Using Simple/Complex Code View...............................................................................................46
4.8 Launching a debugger from the Code Editor................................................................................47
4.9 ACE Methods...............................................................................................................................48
4.10 ACE Code...................................................................................................................................53
5 Assemblies............................................................................................................................................69
5.1 Compiling from the ACE Editor with added assemblies...............................................................69
5.2 Referencing External Assemblies.................................................................................................69
5.3 Available Assemblies....................................................................................................................70
6 Examples...............................................................................................................................................73
6.1 Dual Inputs...................................................................................................................................73
6.2 Variable Parameters.....................................................................................................................74
6.3 Launching an executable..............................................................................................................77
6.4 Calculating a volume....................................................................................................................77
6.5 try-catch........................................................................................................................................77
6.6 fldget and fldput............................................................................................................................78
6.7 Changing a status point................................................................................................................78
7 Troubleshooting.....................................................................................................................................80
7.1 ACE disabled on failover..............................................................................................................80
7.2 BLT ACE crashes.........................................................................................................................80
3
Table of Contents ACE Reference
7.3 ACE Code aborts without warning................................................................................................80
4
ACE Reference ACE Introduction
1 ACE Introduction
What’s in This Chapter?
1.1 Product Description............................................................................................................................6
1.2 Product Pieces....................................................................................................................................8

1.3 Execution Model.................................................................................................................................9
1.4 Security.............................................................................................................................................11
1.5 Registry Variables.............................................................................................................................11
1.6 Error Messages................................................................................................................................12
1.7 Arbitration States of Multithreaded ACE...........................................................................................16
The Application Calculation Engine (ACE) is used to create custom calculations and controls for the
RealTime Service using .NET languages such as Visual Basic (VB).
ACE is run as part of the RealTime service and starts up automatically when the RealTime service starts
up and shuts down when the RealTime service shuts down.
ACE is designed to perform calculations given a set of input parameters. The input parameters can be
any numeric RealTime field, PubSub topic, or constant value. The results, or output, of an ACE
procedure can be written to any RealTime numeric field. When given a RealTime path as input, the
procedure results can automatically set the fresh/stale state of the output field based on the fresh/stale
state of the input parameters.
ACE procedures can be triggered:
• Periodically.
• Manually.
• Whenever there is a change to input parameter's numeric value.
• On alarm (if a path input point changes alarm state).
• On startup (going hot from standby state during startup or failover).
ACE is designed to work well with simple calculations that can be done quickly and easily by the server.
ACE optimizes access to the inputs and outputs associated with an aceconfig record, so using the input
and output configuration facilities is recommended. ACE can also support Fldget and Fldput inside
of the ACE routine, but these operations are more expensive.
In general, any operation that is likely to take more than a few milliseconds is not a good candidate for
ACE. ACE is designed to execute 1000’s of aceconfig records per second, thereby averaging less than
1 millisecond per routine. It is easy to see that any operation consuming a lot of time, anything more
than 0.1 milliseconds, has the potential to significantly impact ACE performance. For the most part
database operations are safe. However, something like Thread.Sleep is not safe because it takes a
minimum of 10 milliseconds. File operations should generally be avoided, as well.
It should be noted that these are only guidelines. In general, if you are trying to execute 1000s of
records per second, you do not want any long operations to be performed. However, if these operations
are only performed in rare cases, then it may be acceptable.
5
ACE Introduction ACE Reference
With the new capabilities of ACE, longer operations can be spun off into a different thread if needed.
Unless the user code is careful to manage the threads it is creating, it is possible that ACE will continue
to spawn threads until the ACE Engine has to shut down or the RealTime server fails.
NOTE: All thread management must be done by the user code as the ACE Engine is not aware of any
thread that is executing in user code.
CAUTION: Extreme caution should be used when spawning threads from ACE as the ACE Engine
does not monitor them and therefore it will not know which aceconfig record to disable if
there are problems.
ACE can be used to launch external executables or scripts for large operations. Simply launch them
asynchronously so that other ACE procedures are not affected.
NOTE: It is not possible to run more than one instance of an aceconfig routine at any given time.
Running an instance of an aceconfig routine refers to running both the user code and the
parameters fed into it from the aceconfig record at the same time.
NOTE: The ACE code and aceconfig tables should NEVER be locked or manipulated with the user
code. This will cause ACE to become unresponsive, as it will not be able to update records.
For example, if you added a lock to an aceconfig table in the user code and never removed it, the ACE
engine would be unable to lock this aceconfig table itself, and it would indefinitely wait for the lock to be
removed. The routine that is currently running would then time out and attempt to disable the aceconfig
record, but it would not be able to due to the lock that you had placed on the table. The ACE engine
would then restart, but with the aceconfig record still enabled, the same issue would occur. In this way,
using the user code to add locks to ACE tables will cause ACE to freeze.
1.1 Product Description

In order to better understand ACE, it is useful to understand the way that the product is built.
ACE is not intended to be used as a soft PLC engine for software routines that are better run in a station
environment. Indiscriminate use of ACE will significantly impact OASyS SCADA performance and may
require additional hardware to improve operating performance.
Equations
ACE allows the user to specify equations and logical expressions for database calculation and control
purposes.
Inputs and Outputs

There are three types of inputs that can be used in an aceconfig record: Constants, RealTime Paths,
and PubSub Topics. All three inputs require a numeric value to work in the ACE calculation. ACE uses
the last known value for Path and PubSub inputs.
The output point for an aceconfig record can be any database point where the table contains at least
one writable field.
6
Language
ACE supports equations and expressions written in:
• Visual Basic
• .NET
• C#
ACE VB is VB.Net, not a restricted form of VB.Net. You can use either VB.Net or C#.
Equation Operators
ACE supports the following mathematical operators and logical operations:
• equal
• less than
• less than or equal

• greater than
• greater than or equal
• addition
• subtraction
• multiplication
• division
• exponential
• logarithm
• minimum
• maximum
• boolean AND
• boolean OR
• boolean NOT
• logical AND
• logical OR
• logical NOT
Triggering Methods
ACE executes an equation under the following conditions:
• Periodically (specifiable in seconds).
• When any of the equation’s input variables has changed value numerically.
7
• On startup.
• On alarm change for a RealTime path.
NOTE: If the value of a PubSub topic is non-numeric it cannot trigger an ACE routine. Only use PubSub
topics that have associated numeric values.
Code Validation
ACE validates any equation for syntactical correctness and refuses to execute it unless it has passed
the syntax tests.
RunTime Errors
Any exception thrown by an ACE procedure is trapped by the ACE Engine process. After trapping the
error, the ACE procedure is disabled to prevent further errors from occurring and an alarm is issued.
Special Output Handling

ACE allows the output value to be processed by v_krunch as part of writing the equation result to a
database point.
Security
ACE Configuration and code tables are protected such that only DBconfig or higher authorities are
allowed to modify either ACE code or ACE Configuration.
1.2 Product Pieces

ACE consists of five main components.
The ACE product consists of the following parts:
• ACE Engine
• ACE Configuration
• ACE Editor
• ACE Databases
• ACE BLT components
The ACE Engine runs on the RealTime server as part of the RealTime service and is responsible for
executing the code configured in the ACE Databases. The ACE Engine process is not a critical process
and does not cause a failover if it fails. ACE Engine is designed to always be running and automatically
restarts if it fails. There are only three instances in which ACE Engine can fail:
8
• Startup failure - any problem affecting ACE startup causes RealTime to fail.
• Controlled shutdown due to ACE procedure errors - this is an expected shutdown and is used by
ACE to clean up runaway ACE procedures.
• PubSub engine failure - ACE Engine shuts down and restarts thereby trying to re-establish the
connection. If PubSub continues having problems, the RealTime service will shut down.
The ACE Editor no longer supports assigning security to acecode points, this is now done through ADE.
The ACE Editor is a windows form that is installed on ezXOS stations. The ACE Editor allows you to
input ACE code into the system. This editor provides the ability to type in the code, compile it, save it to
the database, load it from the database, and assign security.
The ACE ezXOS displays are used to support configuration of ACE equations. These displays include a
summary display, a database point and field selector and a configuration display.
There are two databases in the RealTime system to support ACE:
• The acecode database contains information about the ACE code that runs in ACE Engine and is
shown in the ACE Editor.
• The aceconfig database stores configuration related to execution ACE code. This configuration
includes an output point (if any), frequency of execution, group, dataset, name and the ACE code
record that contains the runtime code.
The ACE BLT components contain functionality that runs on the RealTime server but is meant to support
activities in the ACE Editor. These functions include saving, loading and compiling ACE code.
9
1.3 Execution Model

An illustration of the execution model for the ACE engine process.
Figure 1 - ACE Execution Model
The ACE engine operates using two databases: ACE configuration (aceconfig) and ACE code
(acecode). The ACE engine loads the information from the ACE configuration and ACE code databases
into its internal cache on startup. Any further updates are delivered through PubSub. Because of this,
changes to the ACE databases are always quickly reflected in the ACE engine. In addition to the
information storage, there are several threads that perform various functions inside the ACE engine.
The queueing thread reads the ACE configuration records from the internal cache and queues up any
that are ready to be run. This thread iterates through the array of ACE configuration records in the cache
once per execution cycle. The execution cycle is 5 seconds by default but can be configured using the
registry override, EXECUTION_CYCLE.
There are several execution threads, and this varies depending on the number of processing cores
contained on the hardware. These threads run in parallel allowing ACE to scale with hardware
upgrades. The execution threads read from the queue of runnable ACE procedures populated by the
queueing thread. When the execution thread retrieves an ACE procedure from the queue, it runs the
user code associated with that aceconfig record using the configuration retrieved from the queue. If an
output point is defined, the results are written when the code has finished executing.
10
Various statistics are kept by the execution threads which are monitored by a monitor thread. The
monitor thread tracks runtimes and thread health and determines when it is time to start or stop threads
or even restart the process. The ACE engine process will restart if an ACE procedure exceeds a
configured runtime timeout. This timeout can be overridden using the registry override,
RUNTIME_TIMEOUT. If an error is encountered during the execution of an ACE record, that ACE record
is marked as disabled. This prevents execution of this record until it is manually re-enabled. ACE
records should only be disabled if they show an exception during execution or if they exceed the
runaway timeout.
The checkin thread simply checks into the process monitor periodically and monitors status updates
from the monitor thread.
1.4 Security
Various security measures are used to ensure that only authorized users are allowed to configure and
modify ACE records.
Security risks are reduced by having group fields in the aceconfig and acecode tables to enforce
SCADA AOR security. To control access, group permissions can be assigned manually to the acecode
records at any time in their life cycle. Aceconfig records inherit their group permissions from their
associated output points. AOR security is also used during configuration to ensure that the user is only
presented with points that they are allowed to view, given their permission groups.
NOTE: A user cannot configure ACE outputs for a point that they do not have permission to view.
Operator AOR is used to filter the ACE points available in the ACE Summary. It is also used to manage
whether or not a user has control permissions for an ACE Configuration point.
1.5 Registry Variables

A list and description of the registry variables used by ACE.
Table 1 - ACE Registry Variable descriptions

Registry Variable Description
RUN_FREQUENCY This variable controls how often (in milliseconds) procedures
are checked for their ability to run. The default value is 5000
milliseconds (5 seconds). If the value specified is not between
100 milliseconds and 14000 milliseconds, the default value will
be used.
MAXIMUM_EXECUTION_THREADS This variable lets you specify the maximum number of threads
that can be used to run ACE procedures at any one time. The
default value is 5. The minimum allowed value is 1 and the
maximum is 20. If the variable is set to a value outside of that
range, the value will be invalid.
NOTE: ACE will only use as many threads as there are cores
in the machine, less one. For example, if the
MAXIMUM_EXECUTION_THREADS is set to 19, but
Table continued…
11
Table 1 - ACE Registry Variable descriptions (continued)

Registry Variable Description
the machine only has 8 cores, ACE will only use 7

threads. However, if the
MAXIMUM_EXECUTION_THREADS is set to a
value lower than the number of cores minus 1, this
value will be the maximum number of threads used.
PROCEDURE_TIMEOUT This variable controls the maximum time (in milliseconds) for
ACE to run an aceconfig routine. If this maximum time is
exceeded, ACE logs an error in the ACEengine error log, but
no alarm or event is generated. The default value is 2000
milliseconds (2 seconds). If the value specified is less than
1000 milliseconds (1 second), the default value will be used.
RUNAWAY_TIMEOUT This variable controls the time (in milliseconds) before ACE
disables a running record. ACE will then log an alarm stating
that the record has been disabled. Finally, ACE will log a
message stating that it is restarting due to a stuck procedure
and then close, causing the process monitor to restart it. The
default value is 90000 milliseconds (90 seconds).
IDLE_SLEEP This variable controls the time (in milliseconds) ACE will wait
before performing a HOT check while RealTime is in standby
mode. The default value is 1000 milliseconds (1 second).
DELAY_AFTER_HOT This variable controls the time (in milliseconds) that ACE will
wait after RealTime goes HOT to reduce contention. The
default value is 60000 milliseconds (1 minute).
RUN_TIMEOUT This variable controls the maximum time (in milliseconds) for
ACE to run all aceconfig routines in an entire run. If this
maximum time is exceeded, ACE logs an error in the
oasErrLog and the ACEengine error log. The default value is
5000 milliseconds (5 seconds). If the value specified is not
between 1000 milliseconds (1 second) and 60000 milliseconds
(1 minute), the default value will be used.
SHUTDOWN_TIMEOUT This variable controls the maximum time (in milliseconds)
between the detection of a runaway process (i.e., a process
that takes longer than the value of RUNAWAY_TIMEOUT to
run) and ACE restarting. This allows any other processes that
are running to complete normally. The default value for
SHUTDOWN_TIMEOUT is 10000. The minimum allowed value
is 1000 and the maximum is 90000.
1.6 Error Messages

ACE keeps a log of error message and handling errors.
ACE log messages are stored in: log\ACEEngine.log
When ACE points are automatically disabled, this file should be reviewed to determine the reasons why.
12
1.6.1 Configure error messages in OASyS DNA

Registry settings, stored in XML files, are used to configure some error messages that appear in the
™ ™
ACEEngine.log file. In OASyS DNA 7.6 and OASyS DNA 7.5 , the files are located in config\registry.
The following sets of instructions can be used to reduce/increase two common warning messages.
Procedure
1. Create a new XML file called ACE.xml.

2. Type data into the XML file as follows, to specify:
• Procedure timeout value (WARNING: ACE config <AceconfigName> procedure

<AcecodeName> execution time (<#> milliseconds) exceeds maximum (<#>)):
<OASYSDNARegistry>
<Product Name="ACE">
<Value Name="PROCEDURE_TIMEOUT">1600</Value>
</Product>
</OASYSDNARegistry>
• Run timeout value (WARNING: total ACE execution time for this run (<#> milliseconds) has
exceeded specified limits (<#>)):
<OASYSDNARegistry>
<Product Name="ACE">
<Value Name="RUN_TIMEOUT">1600</Value>
</Product>
</OASYSDNARegistry>
3. Save the ACE.xml file in config/registry.

4. Restart the RealTime Service.
1.6.2 Configure error messages in OASyS DNA 7.4

Registry settings are used to configure some error messages that appear in the ACEEngine.log file.
Before you begin

The ACE settings are local to the machine and are located in HKEY_LOCAL_MACHINE\SOFTWARE
\Telvent\OASySDNA\ACE. The utility "regedit" may be used to view and change the settings.
13
Procedure
1. To reduce/increase the frequency of the following message, modify the value for
PROCEDURE_TIMEOUT : WARNING: ACE config <AceconfigName> procedure
<AcecodeName> execution time (<#> milliseconds) exceeds maximum (<#>)
2. To reduce/increase the frequency of the following message, modify the value for RUN_TIMEOUT:
WARNING: total ACE execution time for this run (<#> milliseconds) has
exceeded specified limits (<#>)
3. Restart the RealTime service.
1.6.3 Enable logging

While executing ACE code, most errors are logged in the ACEEngine.log file. However, common
messages, such as failure to write a record in manual-override, are not commonly logged. To enable
these messages, the debug level must be elevated from the default.
The following example uses the toggledebug executable to elevate ACEEngine debug messages to
allow the writing of warning, informational and verbose messages to the ACEEngine log file. In this
example, the Process ID for ACEEngine is 1234. In practice, you will have to use the task manager or
the process list in NMC to determine the Process ID.
Ex: toggleDebug -p 1234
NOTE: As indicated in Logging debug levels (Table1‑2), the first toggle enables warning messages,
then info messages, and finally verbose messages. To turn off extra debugging, toggle back to
the default from verbose using the same command.
Table 2 - Debug Levels

Debug Level ACE Actions
Fatal Writes the given message to the OASyS DNA log file (oasErrLog.log),
then exits the program immediately and writes a stack trace into the
OASyS DNA log file
Exit Writes the given message to the OASyS DNA log file (oasErrLog.log),
then exits the program without a stack trace being written into the
OASyS DNA log file
Always (Error) Writes the given message to the OASyS DNA log file (oasErrLog.log). If
any messages have been written into the program specific debug log file
(programName.log), then this message will also be written there, and
will have a heading of 'Error'.
DebugLog Writes the given message to the program specific debug log file
Warning If the dynamic debug level has been set high enough through the
'toggleDebug' utility, then messages marked with this level will be written
out to the program specific debug log (programName.log)
Info If the dynamic debug level has been set high enough through the
out to the program specific debug log (programName.log).
Verbose If the dynamic debug level has been set high enough through the
out to the program specific debug log (programName.log).
14
1.6.4 Bad Code Detection

ACE is designed to monitor user code in order to detect problems that may impact the operation of ACE
and other ACE procedures.
If problematic code exists in the user code, ACE may take longer than usual to run a set of ACE
procedure records. If the ACE engine detects a delay (i.e., the user code has run longer than the time
value configured in the RUNAWAY_TIMEOUT registry variable), it will shut itself down and disable the
aceconfig record that is running the user code that is causing the delay. If several aceconfig records are
using the same ACE code, only the first one detected will be disabled. Subsequent iterations may result
in additional aceconfig records being disabled. An alarm and an event are generated every time a
record is disabled.
NOTE: Stopping ACE procedures before they have finished executing may cause problems as the code
will not have fully completed its processing.
ACE will wait up to the time value configured in the SHUTDOWN_TIMEOUT registry variable for ACE
procedures to exit on their own before terminating them. In the event of termination, some database
locks may not be removed from the terminated procedures. ACE handles this bad application state by
restarting the entire process. The database locks held by the ACE engine process are cleared out by the
periodic unlock process when it detects that the ACE engine has shut down. After the database locks
have been removed, the process monitor will restart ACE.
NOTE: When the ACE engine shuts itself down and an alarm is generated, it is recommended to check
the oasErrLog to see which routines have been disabled or prematurely terminated due to the
suspect code that caused the shutdown.
1.6.5 Exception handling

If the user code is directly using the HPDB (High Performance Database), it may encounter several
exceptions. The following sections list several categories of exceptions and how to handle them.
NOTE: In the event that an exception is thrown, ACE detects this and disables the routine, but the ACE
engine is not restarted.
Exceptions that do not disable aceconfig, but log a Warning level message
These errors are logged but do not cause alarms and do not disable aceconfig as they may occur as
part of normal system operations, and they will likely be cleared upon a future aceconfig execution.
Frequent messages that are logged at a Warning level in the ACEEngine.log file:
OASySDNA.RealTime.HighPerformanceDB.VDBException.NOT_MANUAL
OASySDNA.RealTime.HighPerformanceDB.VDBException.OFFSCAN
Exceptions that do not disable aceconfig, but log an error message
These errors are logged but do not cause alarms and do not disable aceconfig as they may occur as
part of normal system operations and they will likely be cleared upon a future aceconfig execution.
15
Infrequent messages that are logged at a DebugLog level in the oasErrLog:
OASySDNA.RealTime.HighPerformanceDB.VDBException.DB_LOCKED
OASySDNA.RealTime.HighPerformanceDB.VDBException.OWNING_SYS_NOT_AVAIL
OASySDNA.RealTime.HighPerformanceDB.VDBException.PNT_PRGM_COM_INH
OASySDNA.RealTime.HighPerformanceDB.VDBException.PNT_MMI_COM_INH
OASySDNA.RealTime.HighPerformanceDB.VDBException.PNT_TAG_CLS_INH
OASySDNA.RealTime.HighPerformanceDB.VDBException.PNT_TAG_INH
OASySDNA.RealTime.HighPerformanceDB.VDBException.PNT_TAG_OPN_INH
OASySDNA.RealTime.HighPerformanceDB.VDBException.REC_LOCKED
OASySDNA.RealTime.HighPerformanceDB.VDBException.REMOTE_SEND_FAIL
OASySDNA.RealTime.HighPerformanceDB.VDBException.RTU_LOCAL
OASySDNA.RealTime.HighPerformanceDB.VDBException.TAG_WARNING
OASySDNA.RealTime.ACE.ACEPubSubNoDataException
Exceptions that will disable the aceconfig record
All exceptions not covered in the previous two sections will disable the aceconfig record and cause an
alarm to be raised.
Exception workaround
ACE will assume that several types of the above exceptions are errors associated with updating the
output point, and it will not disable the aceconfig record when these errors are found. This may be
misleading if the code is directly manipulating database records as through fldput.
In this case, an exception can be thrown and the output point will not be updated, but the aceconfig
record will not be alarmed or disabled. In general, when doing these types of operations, a try-catch
block is needed so that errors can be handled appropriately in the user code. If the error should disable
the aceconfig record, a generic exception object can be used in a throw statement.
1.7 Arbitration States of Multithreaded ACE

ACE is part of the RealTime service and will therefore change how it operates based on the arbitration
state of RealTime. As a result, when we refer to ACE as running in HOT mode and STANDBY mode,
this is actually referring to the state of RealTime. Since ACE is part of an arbitrated service, it must
16
handle running in these two modes and switching between them during failovers, cold starts and
shutdowns. This section discusses how ACE handles arbitration states.
When RealTime starts up it will run the ACEengine process. During the ACE engine startup, PubSub
subscriptions are obtained for the acecode and aceconfig databases as well as for several other
RealTime tables. These subscriptions are used to inform ACE of configuration changes to ACE records
and to keep the input data consistent with the database. A checkin thread runs continuously and
monitors the arbitration state of RealTime. When RealTime has fully started up and has become HOT,
the ACE engine detects this and proceeds with starting up three groups of threads. One of these
threads is a scan thread that checks for ACE procedures that can be run and queues them up. Another
is a group of execution threads that read from this queue and execute the procedures. Monitoring
threads are also started to check for timeouts and deadlocks. While RealTime is HOT, ACE continuously
executes ACE procedures.
In general, enterprise systems have a dual-hosted service that contains a second server running in
STANDBY mode. As such, ACE must recognize when RealTime is running in STANDBY mode and act
accordingly. While operating in STANDBY mode, the ACE engine has most of its threads shut down.
ACE does not execute any ACE procedures while in STANDBY mode. While RealTime is in STANDBY
mode, only the checkin thread runs, which also monitors the arbitration state of RealTime. The ACE
engine sits idle, signalling to the process monitor that it is waiting for the system to become HOT. The
PubSub subscriptions are still active however, so the STANDBY ACE engine still remains up-to-date
with changes to the RealTime aceconfig and acecode databases.
When standing down, ACE checks the arbitration state periodically, at a frequency controlled by the
IDLE_SLEEP timeout. When it detects that the RealTime service is no longer HOT, the ACE engine will
request a shutdown of all threads and stops queuing procedures for execution. The shutdown waits for a
period of time (configured in the SHUTDOWN_TIMEOUT variable) for any running ACE procedures to
complete. Any procedures that are not completed are aborted and the following error message is logged
in the oasErrLog, where <name> is the name of the interrupted record:
aceconfig <name> interrupted during execution as a result of a shutdown

timeout
1.7.1 Arbitration Status

These icons pertain to the items that indicate an arbitration state.
For further information, refer to the Arbitration section.

MBX
Table 3 - Arbitration Status Icons

Ic Description
o
n
The Triangular Yellow D (Do Switch) icon contains a “D” to indicate that the system, service, or
machine items and all of their components are in a do state.
The Red F (Fail) icon contains an “F” to indicate that the system, service, or machine items and all
of their components are in a fail state.
The Green H (Hot) icon contains an “H” to indicate that system, service, or machine items are in a
hot state.
Table continued…
17
Table 3 - Arbitration Status Icons (continued)

Ic Description
o
n
The Green S (Standby) Icon contains an “S” to indicate that system, service, or machine items are
in a standby state.
The Triangular Yellow S (Switch) icon contains an “S” in a yellow triangle to indicate that system,
service, or machine items are in a switch state.
The Hour Glass (waiting to initiate) icon contains an “hour glass” to indicate that system, service, or
machine items are in a waiting to initiate state.
18
ACE Reference Aceconfig Table
2 Aceconfig Table
2.1 Aceconfig Row Edit: Main Tab..........................................................................................................19
2.2 Aceconfig Row Edit: Trigger Configuration Tab................................................................................21

2.3 Aceconfig Row Edit: Input Tab..........................................................................................................22
2.4 Job Scheduler Records....................................................................................................................25
2.5 Record Fields and Flags...................................................................................................................25
2.6 Output Record Flags.........................................................................................................................28
2.7 Types of Execution...........................................................................................................................30
2.8 Disabling and enabling an ACE record.............................................................................................31

2.9 Records Not Executing.....................................................................................................................32
ACE configuration is done through the Advanced Database Editor (ADE). The ACE Records option is
used to configure ACE procedures for execution on a RealTime database point.
Figure 2 - Aceconfig Table
19
Aceconfig Table ACE Reference
2.1 Aceconfig Row Edit: Main Tab

The Main Tab of the Aceconfig Row Edit table is used to set up the execution of the record.
Figure 3 - Aceconfig Row Edit: Main Tab
Table 4 - Aceconfig Row Edit: Main Tab description

Item Description
Open ACE Code Opens the ACE Code Editor dialog box (Figure 4.1) Refer to ACE Code
Editor... Editor (Module 4).
Code The name of the ACE code that is associated with the point.
Output Point A database point where is the result of an ACE function is written to. This
field can be blank.
Group A group is assigned to all points that are closely related.
Dataset This is the dataset that is associated with the ACE Configuration record.
Base Message This field contains the message record, which holds the appropriate
messages for the record being configured.
Update Fresh Select the checkbox to compute the output point’s fresh state based on the
fresh state of the input parameters. This allows for automatic update of the
fresh state of the output point.
Enable Run Select the checkbox to enable execution of this record. Deselect this
checkbox to disable the ACE Configuration record.
20
2.1.1 Output Point Path Selector

The ACE Output Point Path Selector dialog box gives the user the ability to select individual points in
any table in the database.
Figure 4 - ACE Output Point Path Selector
Table 5 - ACE Output Point Path Selector description

Item Description
Table The RealTime table to which the point belongs.
Record The record within the selected RealTime table.
Field A field within the table record.
Current Displays the current table, record and field.
2.2 Aceconfig Row Edit: Trigger Configuration Tab

Figure 5 - Aceconfig Row Edit: Trigger Configuration Tab
21
Table 6 - Aceconfig Row Edit: Trigger Configuration Tab

Item Description
Run Now Click this button to run the ACE procedure.When you click the button and
you have control of the point, the button deactivates and the text changes to
Running. When the calculation is complete, the button reactivates and the
text returns to Run Now. If you do not have control of the point, an error
message appears. Click OK to return to the ACE Control dialog box.This
button will cause the record to execute regardless of the trigger settings. It
will not cause execution if the record is disabled.
Trigger Interval Type the number of seconds desired between ACE Code executions.The
trigger interval is automatically synchronized with the top of the hour/day. If
the trigger is to occur every 3600 seconds, then the ACE Code executes at
the start of each hour (hh:00:00). If the trigger is to occur every 30 seconds,
then the ACE Code executes at hh:mm:00 and hh:mm:30. If an interval other
than seconds is required, the interval cannot be more frequent than the
execution cycle, which is five seconds by default.
Changes to Inputs Select the check box to trigger the record when changes to the inputs,
configuration, or code occur. Remember that all inputs must be associated
with a numeric value to be used in and trigger an ACE routine.
Alarm Triggered Select this check box to trigger the record when records configured as inputs
change their alarm state. The input must be a Path if you want an ACE
routine to be triggered by a change in alarm state for the point.
Startup Triggered Select the check box to trigger the ACE Code when the system goes hot.
Code Change Select the check box to trigger the ACE Code when there is a change to the
Triggered ACE code.
2.3 Aceconfig Row Edit: Input Tab

ACE Engine is an application that compiles code and uses it to perform calculations and operations
given a set of inputs. The code to run and the inputs to the ACEProcedure are defined in the aceconfig
database, with access through aceconfig records.
Aceconfig records have three types of input: constant values, PubSub topic strings, and RealTime value
paths. The Value field is used for entering either constants or PubSub topic strings.
The figure below shows the three different input types in an aceconfig record. Each row represents a
different input, which can result in a calculation or issue an event if the input's value changes. Row 1
uses a Path to a point in RealTime; the value of that point in RealTime can trigger an acecode routine or
be used in a calculation. Row 2 uses a PubSub topic string in its calculation; by subscribing to the
PubSub topic, the aceconfig record is re-run whenever the topic string is published to. Row 3 uses a
constant value in its calculation.
22
Figure 6 - Aceconfig Row Edit: Input Tab
Table 7 - Aceconfig Row Edit: Input Tab description

Item Description
Const? Selecting this checkbox will enable the row to use a constant value.
Selecting this checkbox will cause the Value field to be available. You can
type your constant in this field. If Const? is not selected, the input must be
either a Path or a PubSub topic.
Data Source When Const? is not selected, you must use this drop-down to indicate
whether the input will be a Path or a PubSub topic (which is entered in the
Value field).
Value When the Const? checkbox is selected, the number in this field will be
calculated as the constant input value. If you want to use a PubSub topic
string for input, select PubSub from the Data Source drop-down box. Type
the PubSub topic in the Value field.
Path Click the ellipsis button (...) beside the field under Path to open the Path
Selector dialog box. Select a path as an input value.
23
2.3.1 Input Point Path Selector

The Input Point Path Selector dialog box gives the user the ability to select individual points in any table
in the database.
Figure 7 - Input Point Path Selector
Table 8 - Input Point Path Selector description

Item Description
Table The RealTime table to which the point belongs.
Record The record within the selected RealTime table.
Field A field within the table record.
Current Displays the current table, record and field.
2.3.2 PubSub Inputs that Have No Publisher

ACE Engine keeps aceconfig records with PubSub inputs that have no publishers enabled because it is
not predictable when a PubSub topic will be published to. Similarly, if a PubSub topic has no publisher,
the record remains enabled because information can be published at any minute; however, execution of
ACE code will not happen until data arrives.
When a PubSub input is used, the record is Enabled. However, even though records are enabled, they
may not be ready to run. Some reasons the PubSub input can be missing information are:
• No publisher exists for the topic.
• The publisher is temporarily lost.
• The PubSub topic has not been recently published to.
Although an aceconfig record with a PubSub input could currently be missing data, the topic can be
published to at any time. The record is left enabled, and ACE Engine waits for the topic to be published
to. ACE code will not execute if there is not sufficient information, but aceconfig records resume
execution whenever the information for the PubSub input arrives.
When you are looking at the ACE Summary, the default color of the record will remain green because
the record is enabled. However, you will know if the aceconfig record is waiting to execute because a
PubSub input is missing data because:
• The aceconfig record will have the Stale icon on the left side of the display, and the colors will be
inverted (green writing on black).
• The output point will have an Error icon.
24
NOTE: The Stale icon overrides the Error icon. If the aceconfig record has been configured to Update
Fresh, the output point will show up as stale.
Alarms are not generated because of missing PubSub input data. However, events are generated for
the following circumstances:
• A publisher that previously existed has been lost for at least one PubSub input.
• All inputs now have publishers when previously this data was missing for at least one PubSub input.
2.3.3 PubSub Topics and Systems

Aceconfig routines can have PubSub inputs defined to run on a specific system, or on the system where
ACE is running.
To configure a PubSub input to run on a specific system, you can identify the system name in the
PubSub topic as shown below:
es.realtime.ace.singleruntime
In this case, regardless of the system that ACE is running on, it will subscribe to the PubSub topic on the
specified system, which is es in this case. The value associated with the topic string will be obtained
locally if ACE is running on es, or through ISPS if it is running on a different system.
You can configure a PubSub input so that it runs on whichever system ACE is running by using the
%system% flag. This flag works as a prefix to the PubSub topic string, and causes ACE to subscribe to
the local system. Here is an example:
%system%.realtime.db.analog.ana1.curval
If the system that ACE is running on is main, the string above, will cause a subscription to be made to
the topic main.realtime.db.analog.ana1.curval. When a mode switch occurs, the subscription
will change to the owning system because the system flag has been used.
2.4 Job Scheduler Records

ACE Configuration records can be configured to run through Job Scheduler (JSH).
JSH execution is independent of the trigger types. Thus, to strictly execute based on JSH, all triggers
should be unchecked. However, it is possible to use jsh and other triggers in combination.
To trigger ACE records through JSH, configure a JSH script record that toggles the doRun flag on the
aceconfig record. This can be accomplished by using the code below:
fnput aceconfig.<recordname> run
2.5 Record Fields and Flags

During the execution of ACE records several flags and fields in the aceconfig records may be modified.
This section describes these fields and how they are modified. All methods for affecting the updates to
these values through ACE code are also discussed. Most of these fields correspond directly to
configuration items contained on the ACE Configuration display.
25
Table 9 - Field and Flag descriptions

Field/Flag Description
Name The name of the aceconfig record. This is a unique field.
Group This field, the AOR Group field, specifies the permissions group that
governs which users can manipulate and view a record. If there is an output
point defined for this record then the group field is copied from the output
point automatically by the ACE Engine. If an output point is defined, then
the group field cannot be configured in the aceconfig record.
CodeSlot The database slot number of the acecode record containing the code that
will execute for this aceconfig record. If this is blank or invalid, the aceconfig
record will be disabled and an alarm will be thrown. This can be changed
using the configuration displays and ACE will automatically switch from one
code record to another when the change is saved. Changes to the
execution code counts as an input change and will trigger a routine that is
marked to run on changes to inputs.
Parameters The parameters array contains all of the inputs and the output that are used
by the ACE code. The output record is contained in slot 0 of the array.
Inputs may be either database records, PubSub topics, constant values, or
nothing. All inputs must correspond to a numeric value. The output can be a
database value or nothing. Each value in this array is a structure containing
the fields isConstant, dataSource, value, and paramPath. The value field is
a double that can contain a literal value to be used as a parameter to the
code, or a PubSub topic that corresponds to a numeric value. The
paramPath field contains a path that points to a database point containing
the value to be used as the input or output. The isConstant flag is a
Boolean indicating whether the input parameter is a constant or a variable
value. If it is a variable value, the dataSource field is used to specify
whether a Path or PubSub topic will be used. PubSub topic parameters are
stored in the value field, while Paths are stored in the paramPath field. The
isConstant flag is ignored for output points. Blank parameters are treated as
the value NaN in the ACE code, which triggers exceptions if they are used.
TriggerInterval The triggerInterval defines the number of seconds between executions of
an aceconfig record. The trigger interval can be set to any amount, but by
default ACE runs its execution loop every 5 seconds, therefore any interval
should be a multiple of 5 seconds. In addition, if the interval is 60 seconds,
the aceconfig record is run at the top-of-the-minute; where 3600 means top-
of-hour and 86400 means top-of-day.
Enabled This field is checked every time an aceconfig execution is attempted. If the
field is true, then the record executes, otherwise it does not and ACE
silently ignores the record. The enabled field can be manually set to either
value using SQL or the ACE Configuration display. If there is any problem
with the ACE record (such as a code exception) then this field is set to false
and the routine is effectively shut down until this flag is reset.
DoRun This field is used to trigger an immediate execution of the aceconfig record.
The field is checked on every execution cycle and if it is true, then the
record is executed regardless of any other factors. The field can be set to
true using the “run” function put command. Since function put commands
can scheduled using the Job Scheduler, this enables JSH scheduling of
ACE record execution. Once the record is executed, this field is
automatically reset by the ACE Engine. This field cannot trigger execution if
the record is disabled.
Table continued…
26
Table 9 - Field and Flag descriptions (continued)

UpdateFresh This field determines whether or not the fresh flag on the output point is
updated based on the input status. This calculation can either be an OR or
AND operation. In the AND case, the fresh flag on the output point is set to
true only if all inputs are either constants, database points without a fresh
flag, or are themselves fresh. PubSub inputs are ignored in this calculation,
similarly to constants. If any of these conditions fail for any input (except if
the input is the same as the output) then the fresh flag on the output record
is set to false. If the calculation is set to OR, then only one input has to
satisfy these conditions for the point to be set to fresh. If the calculation
fails, the output is set to stale. Similarly, the output point's fresh flag is set to
false if the input is a PubSub topic without a publisher.
ConfigChange This field is used to trigger a reload of the record by the ACE Engine
process. This is automatically toggled when certain fields are updated. In
addition, the ACE Engine directly triggers off of other fields.
LastRunTime This field indicates the last time that an aceconfig record has successfully
run. Every time the aceconfig record runs to completion, this field is
updated with the current timestamp. If the run is unsuccessful or the record
is disabled or the triggering conditions are not met (such as inputs changing
or a timeout expiring) the timestamp will not be updated. It is also not
updated if an execution cycle has passed but this routine was not
scheduled to execute.
Dataset The dataset of the record that controls distributed access to a record. The
dataset also controls where the code is executed, as only the owning
system executes ACE code. In the case where an output is defined that has
a dataset, this value is copied from the output record and cannot be
changed. In the case where no output dataset exists, it can be configured
manually.
AccessFlag The accessFlag field is used by ezXOS to track whether or not the record is
open in the ADE displays and which ezXOS station has the record open.
Several flags and fields on output records can be modified by ACE. The
most significant one is the output field itself. Since any numeric field in the
RealTime database can be written to with ACE, there are multiple scenarios
that can exist. An output field may be the RealTime krunch field for a record
or it may some other numeric field on such a record or it may be a numeric
field on a non-telemetered record. If ACE is not updating the telemetered
field on a record, then only the field written to is modified. As an example, if
ACE writes to analog.1.tolerance, then it is only the field that is
updated, even if updateFresh is configured to be true. If, however, ACE
instead writes to analog.1.curval, then other fields may be affected.
InputTriggered ACE records can be configured to trigger off changes to their input. Pubsub
inputs can only trigger on a numeric value change. Since ACE cannot
determine whether a change has occurred at startup, these records are
always run at startup and when RealTime fails over. Code taking action
based on value changes should do some sanity checking on the values
before determining what action they take. For instance, an ACE routine
monitoring a status point with two states should not assume that an
exception trigger indicates that the status point has flipped from one state to
the other. The previous values for inputs are available in an array of
doubles called lastValues.
Table continued…
27
Table 9 - Field and Flag descriptions (continued)

AlarmTriggered ACE records can be configured to trigger if an input point goes into or out of
alarm. This flag only applies to Path inputs and cannot be configured for
individual inputs.
SetupTriggered ACE records can be configured to trigger on a startup of the server. Startup
is considered to be the same as going HOT. Code changes and input
changes do not affect a startup triggered point. When such a record is
triggered, the RunBecauseGoingHOT flag gets set to true.
CodeTriggered ACE records can be configured to trigger if their code has been modified. In
the case where the point is also configured to trigger on changes to inputs,
this flag is redundant. However, there is no problem with having both
checked.
2.6 Output Record Flags

When ACE writes to a telemetered field, it has the ability to update the fresh flag and the error flag on
that record.
If the calculation fails, the record is put into error. If the ACE record is flagged to update the fresh status,
the output is set to stale when a calculation fails.
Flags can similarly be changed if a PubSub input has no publisher; the error flag is set to "yes" and the
fresh flag is set to "no". The ACE record needs to be flagged to update the fresh status.
28
When updatefresh is active, ACE examines all of the inputs and calculates the fresh flag for the output
record. The algorithm for each parameter is as follows:
If this parameter = output field
Continue to next parameter
Else
If this parameter is configured
If this parameter has a fresh flag
AndFresh = AndFresh AND parameter.fresh
OrFesh = OrFresh OR parameter.fresh
End If
End If
End If
End For Loop
If Using AND For Fresh
Output.fresh = ANDFresh
Else
Output.fresh = ORFresh
End If
2.6.1 Modifying Output Fields and Flags

Several flags and fields on output records can be modified by ACE.
The most significant field that can be modified is the output field itself. Since any numeric field in the
RealTime database can be written to with ACE, there are multiple scenarios that can exist. An output
field may be the RealTime krunch field for a record or it may some other numeric field on such a record
or it may be a numeric field on a non-telemetered record. If ACE is not updating the telemetered field on
29
a record, then only the field written to is modified. As an example, if ACE writes to analog.1.tolerance,
then it is only the field that is updated, even ifupdateFresh is configured to be true. If, however, ACE
instead writes to analog.1.curval, then other fields may be affected.
2.7 Types of Execution

Triggered execution occurs when the aceconfig record has its inputTriggered field set to true. When
configured this way, the ACE Engine still processed the record on every execution cycle. It is not truly
exception based execution. On each execution cycle, the ACE Engine compares all of the input values
with their previous values. If any differences are noted, the ACE code is executed.
There are six basic types of ACE execution:
• input triggered
• alarm triggered
• startup triggered
• interval
• JSH
• manual
These are not independent of each other and a single aceconfig record can exhibit all four types of
execution without reconfiguring.
Input, alarm and startup triggered execution are mutually inclusive tests. Any test that is satisfied and for
which the record is configured causes execution to proceed. In addition, this triggering is independent of
other ACE scheduling and can be combined with any other scheduling mechanism.
Interval execution occurs when ACE is configured with a time interval. As an example, if an aceconfig
record is set to execute every 15 seconds, then it executes every 15 second independent of inputs
changing. The 15 second intervals are set up so that they correspond with top-of-minute boundaries.
Assuming a 5 second execution cycle, every 5 seconds the ACE Engine checks this record to see if the
15 seconds have expired. If not, then the record is ignored. If the time has expired, then the record is
executed and any flag processing needed is performed.
JSH execution is scheduled through the job scheduler in an indirect fashion. The Job Scheduler is used
to schedule C programs of dataBASIC scripts to run at specified moments in time or at specific intervals.
To use JSH for ACE, you simply need to schedule the fnput command passing in the desired aceconfig
record name and the DoRun command string. This causes the DoRun field to get set at that time and
the ACE record will run on the next execution cycle.
Manual execution occurs when the ACE record executes only on user command. This is accomplished
by setting the interval to 0 seconds and clearing the inputTriggered flag. When a record is configured in
this manner, the aceconfig record is never executed. To get it to execute, you must manually set the do
Run flag to true. Whenever the doRun flag on record is set to true, that record will run if it is enabled.
The following chart shows the circumstances that will result in an ACE record being triggered. Note that
points that are triggered on input changes get executed in many different circumstances.
The purpose of an input triggered point is to ensure that the output state always corresponds to the input
state. Therefore, whenever the inputs change, the output must change as well, and any programmed
side-effects must also happen. When the actual code is being run is changed, the routine must be
30
executed to ensure that the current output state matches the inputs. A simple example is a procedure
that adds 2 onto an input. If this code is changed to instead add 4, then the output values for affected
aceconfig records are wrong until they are executed. A similar argument holds for changes to the
aceconfig records themselves.
Input triggered routines are also executed when a server goes HOT. This happens because the past
values are not recorded when a server is not HOT and therefore we have to assume that they might
have changed.
An argument is passed to each ACE procedure when it is run to flag startup situations rather than input
changes. This flag is the runBecauseGoingHot parameter. The chart makes note of when this flag is set.
If you do not want processing to occur in startup scenarios, then this flag can be cleared.
Table 10 - runBecauseGoingHot flag settings

Input Startup Alarm Periodic Not Triggered
Triggered Triggered Triggered
ACE Code changes X, Y
aceconfig record X, Y
changes
Input changes X
HOT after Startup X, Y X, Y
HOT after Failover X, Y X, Y
Input goes into X
alarm
Input comes out of X
alarm
Periodic time X
expires
doRun flag is set X X X X X
X - ACE procedure will execute
Y - runBecauseGoingHot flag will be set.
2.8 Disabling and enabling an ACE record

An ACE record is disabled when its enabled flag is set to false. This can happen either manually or
automatically. When an ACE record is disabled it does not execute when the ACE Engine runs it
execution loop.
ACE records are automatically disabled when an error occurs during their execution. Thre are three
types of errors: a thrown exception, a configuration error, or a runaway timeout. When the point is
disabled due to a thrown exception an alarm is raised indicating why the point was disabled. A log entry
is also produced for all disabled points.
ACE disables a record if an exception is thrown. Any exception causes the ACE record to fail. This is
usually indicative of a coding error. A prime example would be a division by 0 error.
A configuration error causes the ACE routine to be disabled as well. A configuration error is usually
something wrong with the parameter list. A database point that does not exist, a database point or
31
PubSub topic that is not numeric, or a constant value that is not numeric are examples of configuration
errors that can disable a point. Another error that can disable the ACE routine is using a PubSub topic
that exceeds 200-characters or contains |*|.
NOTE: Records that use a PubSub input that is not currently available are not disabled, but even
though the record remains enabled, it is not executed until new data is published.
When the execution time for an aceconfig record exceeds the runaway timeout, it is assumed that the
routine is stuck in an infinite loop or is doing some operation that has blocked. In this case, ACE takes a
very aggressive action to ensure RealTime calculations continue. First, the ACE record is disabled so
that it does not run again until someone manually intervenes hopefully fixing the problem. Next, the ACE
Engine logs an informative massage indicating that the routine has been disabled. Finally, ACE performs
a fatal error, stopping the process and causing it to restart. Since ACE is so aggressive, the runaway
timeout is quite large (set to 60 seconds by default.)
A record can be manually enabled or disabled by selecting or clearing the Enable Run check box on the
Main Configuration tab of the aceconfig row detail dialog box. It can also be done through SQL.
2.9 Records Not Executing

If an aceconfig record is not executing, it could be because of one of these reasons:
• The aceconfig record is disabled. Check the Enable column on the ACE Summary display in ezXOS
to determine if this is the cause.
• The aceconfig record is not being triggered. Check the Trigger Configuration tab on the aceconfig
Row Edit form in ADE.
• A PubSub input has no publishers. Check to see a Stale icon on the ACE Summary display in
ezXOS. Use multisubscriber to verify whether or not the topic has a value by subscribing to it.
• A Path input is not available. ACE Engine retries twenty times in case the ACE routine is running
before the RealTime Database points are available.
• The aceconfig record is missing a dataset field.
NOTE: When you create the aceconfig record with an output point, the record will inherit its dataset
from the output point. However, it is important to remember that you will have to set the
aceconfig record's dataset manually, if you create an aceconfig record without an output point.
Refer to "ACE Code aborts without warning" for another potential cause.
32
ACE Reference Using the ACE Summary Window
3 Using the ACE Summary Window

3.1 Using the ACE Control dialog box....................................................................................................34
The ACE Summary window provides information in a tabular format about the system’s points and their
associated ACE procedures.
The points displayed are determined by the current operator’s view area selections. The summary also
allows you to filter point information by code or group.
Procedure
1. Open ezXOS.
2. Expand the System Displays panel on the Navigation Menu.
3. Click ACE.
Figure 8 - ACE Summary Window
Table 11 - ACE Summary Window Description

Field Description
Name The pre-configured name of the ACE record.
Output Point Indicates the location where the system writes the data resulting from an
ACE code execution.
Last Run The last time the calculation or control routine ran.
Enabled ACE calculations are stored in aceconfig records in the RealTime
database. In each aceconfig record, there is an enabled field that
controls whether or not the ACE server executes that point. This flag
starts out as true for every point, and is set to false if there is a problem
in executing the routine. For example, the following conditions cause a
33
Using the ACE Summary Window ACE Reference
Table 11 - ACE Summary Window Description (continued)

Field Description
point to be disabled and will raise an alarm to notify the operator of the
problem:
• A parameter marked as a database point cannot be parsed, or if a
PubSub topic exceeds 200 characters or contains |*| .
• There is a constant or PubSub value that is not a number.
• There an exception in the routine itself.

The point remains disabled until an operator re-enables it (presumably
after fixing the problem). The Enabled check box on the ACE Control
dialog box allows the operator to monitor the ACE code execution, and
to verify that the routine is working correctly when the point is re-
enabled.The code may be disabled by the database administrator during
database creation/modification. The code may also be automatically
disabled if ACE configuration or code errors are detected. The ACE
Control dialog box can be used to enable or disable ACE code.
3.1 Using the ACE Control dialog box

The ACE Control dialog box provides an interface that allows you to enable and run ACE procedures,
as well as to view point alarms.
Procedure
1. Open the ACE Summary window.

2. Click the row header button of the desired record.
Result
The ACE Control dialog box opens.
Figure 9 - ACE Control dialog box
NOTE: The Stale icon can show in the ACE Control dialog box for two reasons: the record is disabled
or one of the PubSub inputs is missing a publisher. The output point's data quality is displayed.
The freshness of the output point can be affected by the execution of the aceconfig record if
34
ACE Reference Using the ACE Summary Window
UpdateFresh is selected for it. If there is a problem executing the ACE routine, or if PubSub
inputs are not available, the Error icon could also be shown.
Table 12 - ACE Control dialog box description

Field Description
Name The pre-configured name of the ACE record
Code: The name of the ACE code that is
associated with the point.
Group The group that the ACE record is assigned
to. This group is either pre-configured, or
was created because it contains many
points that are closely related.
Output Point Indicates the location where the system
writes the data resulting from an ACE code
execution.
Output Value This field contains the calculated value of
the point.
NOTE: This may not be the value from the
code. If the point is in manual
override, the manual value is
shown rather than the calculated
value. The point is not disabled in
this case (unlike with other ACE
errors) as the condition is likely to
clear under normal operating
conditions.
Run Now Click the arrow button at the bottom-left of
the dialog box to run the ACE procedure.
When you click this button and have control
of a point, the button deactivates and the
text changes to Running. Once the
calculation is complete, the Run Now text is
displayed again and the button is
reactivated.When you click this button and
do not have control of a point, an error
message appears. Click OK to return to the
ACE Control dialog box. The button
remains disabled.
Point Alarms Click the button with the image of an alarm
to call up the Point Alarm summary.
Enabled Select this check box to re-enable the ACE
procedure following an error condition.
Dismiss Click this button to dismiss the ACE
Control dialog box.
35
Code Editor ACE Reference
4 Code Editor
4.1 Menu Bar..........................................................................................................................................37
4.2 Code Editor Toolbar..........................................................................................................................42

4.3 Output Grid.......................................................................................................................................42
4.4 Using the Project Explorer................................................................................................................43
4.5 Tab Control.......................................................................................................................................44
4.6 Intellisense........................................................................................................................................45
4.7 Using Simple/Complex Code View...................................................................................................46
4.8 Launching a debugger from the Code Editor....................................................................................47

4.9 ACE Methods....................................................................................................................................48
4.10 ACE Code.......................................................................................................................................53
The ACE editor is an IDE that provides editing capabilities for the ACE code in the RealTime system.
The Code Editor dialog box displays a Visual Basic (VB) file that has been compiled with errors. There is
a popup hovering over the error that describe the error. The Code Editor is an intelligent editor with
syntax help, intellisense, and color coding. There are five control areas on the editor:
Menu Bar, Tool Bar, Project Explorer, Output Grid, and the Tabbed Control containing the files being
edited.�
36
ACE Reference Code Editor
Figure 10 - Code Editor
37
4.1 Menu Bar

The menu bar at the top of the Code Editor has all of the standard editing functions.
Figure 11 - Code Editor Menu Bar
Table 13 - Code Editor Menu Bar descriptions

Item Description
File The file menu contains New, Open, Close, Save, Save All,
Import, Export, and Exit. With the exception of Import, Export,
and Exit, all of the menu items deal with ACE code that is
registered into the system using the ACE code database. Import
and Export are used to interact with source files stored on the file
system.
Build This menu contains the Compile function that is used to compile
the code in the active editor.
Edit This menu contains the Standard editing functions.
View Contains the functions for enabling the controls and toolbars but
also contains a Simple View item. This function is used to show
only the user code.
NOTE: The intellisense is not as functional in the simple view,

but all other functions work the same.�
Help This menu contains the documentation help suite.
Debug This menu contains only one item that is used to launch a
debugger.
38
4.1.1 Creating a new file

You can create a new file.
Procedure
1. �Select File -> New to access the New File dialog box.
2. Use the File Types drop-down arrow to access all available file types in the editor. Choose a file type
and then enter a file name in the File Name field.
3. Click OK to open an editor tab with the code on it.
For either language a class and namespace is provided for the user code.�
Figure 12 - New File dialog box
4.1.2 Opening a file

You can open any existing file.
Procedure
1. Select File -> Open to open the Open File dialog box. The dialog box displays all of the ACE
procedures that are available in the system.
2. Click to select a file, or drag to select multiple files.
• To open a block of files, select a file and then hold the shift key down and select another file down
the list. This should highlight a block of files to open.
• To open a variety of files, select a file and then hold the ctrl key and select as many files as
required.
3. Click the Open button to load the files in the ACE Editor.
39
Figure 13 - Open File dialog box
4.1.3 Importing and exporting files

Files are saved on the RealTime server, then imported to the local machine for editing and exported
back to RealTime when finished.
Saving a file will upload it to the RealTime server. The RealTime server hosts the ACE code source as
files on its file system. Likewise, loading a file means the local machine will download it from the
RealTime server. The saving and loading of ACE code requires a HOT RealTime server that ACE can
connect to.
Exporting and importing can be done with any file system. Importing a file means reading the contents of
a file and then loading those contents into an editor panel. Exporting does the opposite; it takes the
contents of the current editor panel and condenses them into a file. The RealTime server is not involved
in exporting and importing. Thus, an imported file will not be integrated into the RealTime system until it
has been saved.
A file does not need to be exported in order to import it. Any file can be imported as any type, but better
results occur if the types match. For instance, a word document would not work well as a VB ACE
40
procedure, but one could be loaded into the editor if desired. Likewise, the editor can export any type of
file.
Importing a file
Importing a file means selecting a file from the file system, then determining how that file will be
interpreted by the editor. The contents of the file are then loaded into the editor, displaying syntax
highlighting and syntax errors.�
By choosing the file type, the syntax checker and compiler are also chosen for the editor panel.
Additionally, the database is checked for any existing files with the assigned name. If one is found, an
error message will appear, denying the file import. In the example shown in the File Import dialog box
and the New File dialog box, the readme file is being imported as a CSharp file.
The first time this procedure is completed, an editor panel is created with the contents of the imported
file (readme.cs would be created in the example). If the import command is repeated, the contents of the
file are simply reloaded into the panel. If you have saved the file between imports, an error message will
appear stating that the file already exists.�
Procedure
1. ��Click File > Import.
Step Result: The File Import dialog box opens.
Figure 14 - File Import dialog box
2. Select the file you wish to import. If required, use the Files of type drop-down arrow to filter any
known file types.
3. Click OK.
Importing a file as a template
Procedure
1. ��Click File > New.
Step Result: The Import as Template dialog box opens.
41
Figure 15 - Import as Template dialog box
2. Use the File Types drop-down arrow to select the type of the file that will be imported as a template.
3. Click the From Template button. A file selection dialog box will appear whose file types are limited to
the one that was selected in the popup from the Import As a Template dialog box. Select the desired
file to be used as a template.
4. After the file is selected, a new dialog box will appear that does not have the From Template button.
This dialog box allows the user to set the file name before the editor panel is loaded with the text
from the file.
The file type can be changed in this dialog box, but that is generally not recommended or useful.�
Exporting a file
Exporting a file saves a file to the file system without updating the RealTime database or causing ACE
engine to do any code compiling. This is useful for saving versions of the code or saving templates that
can be used for future development.
Procedure
1. Select File > Export from the menu. This opens the Save As dialog box.
2. Either choose an existing file to overwrite or provide a unique file name.
4.2 Code Editor Toolbar

This toolbar provides shortcuts to the same functions that are available through the Menu Bar.
Figure 16 - Code Editor Toolbar
42
4.3 Output Grid

The output datagrid is used to display compiling results. The compiling results can be clicked on to
highlight the line on which the error occurred.
Figure 17 - Output Grid
4.4 Using the Project Explorer

The project explorer contains the list of ACE code that are integrated into the system.
If there is no VB or C# code in the system these buttons disappear and the project explorer appears
blank.
Procedure
1. Click either the ACE C# or ACE VB buttons to view the files contained under either one.
2. Double-click on the desired name to load an ACE code record into the editor.
43
Figure 18 - Project Explorer
4.5 Tab Control

The Tab Control is a small menu in the upper right hand of the Code Editor that allows you to control the
files that are open.
The Code Editor work area is where the coding is done. The small Tool Menu in the upper right-hand
corner allows you to (in order from left to right): open files, go back to the previous file, go forward to the
next file, and close the code editor.
44
Figure 19 - Tab Control
4.6 Intellisense
Intellisense is Microsoft’s version of autocompletion, which allows a Code Editor to display a list of
methods and attributes for a class whenever it is followed by a period.
Intellisense provides both autocompletion and documentation when working within a code editor. Within
OASyS DNA, Intellisense functionality exists for the XE VB Code View and for the ACE Code Editor. For
commonly used objects, it will suggest matching variables or functions after you enter a period (.) as a
marker character. It will also offer a short description of the function in a pop-up window.
45
Figure 20 - Intellisense in ACE Code Editor
4.7 Using Simple/Complex Code View

The Code Editor offers both a simple and a complex code view option.
By selecting the Simple View mode from the view menu the user can choose to only see the user code.
This only works if the code in the source file, that the editor relies on to identify the user code, has not
been modified. If the required tags are modified, then the editor displays the complex code, even if
simple mode has been selected.
Procedure
• Click View > Simple View.
Result
The Code Editor will switch to the Simple View.
46
Figure 21 - Code Editor Simple View
4.8 Launching a debugger from the Code Editor

The ACE editor provides a menu option for launching a debugger based on the type of file loaded into
the editor panel.
The ACE editor will not attach the debugger to any process. This must be done manually using
whatever interface is provided by the chosen debugger. By default, the editor will simply launch Visual
Studio, but it can be customized to use alternative debuggers on a per-type basis. For instance, VB
could use Visual Studio for debugging while C# used something else.
The type of debugger launched for a file type can be specified in the language manager XML
configuration files. These are located in:
<InstallDirectory>\ACE\config\EditorTypes
47
An example is shown below where a path to a VIsual studio debugger is provided, this path may or may
not work on your system. Note that the debugger is identified by the tag DebuggerPath, and it is defined
in the EditorDefinition section of the file.
<EditorDefinition>
<DebuggerPath>C:\Program Files (x86)\Microsoft Visual Studio

9.0\Common7\IDE\devenv.exe</DebuggerPath>
</EditorDefinition>
Procedure
• Click Debug > Launch Debugger.
Figure 22 - Simple Debug Menu
4.8.1 Debugging the ACE Engine

Visual Studio can be used for debugging by simply attaching it to the aceengine.exe process.
WARNING: Debugging is very dangerous on a live RealTime system as debugging the ACEengine
causes the processing of all aceconfig records to stop while in the debugger. Normally the
ACEengine can execute thousands of procedures every 5 seconds. Debugging should only
be done on an engineering station.
The ACEengine will be restarted if left in the debugger for longer than the runaway timeout period. The
user configures the runaway timeout in the registry, as follows:
�RUNAWAY_TIMEOUT default = 60000
where the default is 60 seconds.
The monitoring code thinks that there is an infinite loop, and therefore restarts the ACEengine. As a
result, in-depth debugging can sometimes only be done on one execution cycle of an ACE procedure,
after which the ACEengine process has to be reattached, as is will likely shut down. This can be
eliminated by setting the runaway timeout to a very large value on the engineering station machine, but
this effectively disables runaway detection on that machine.
The ACE source files can be loaded into the debugger and breakpoints can be set in the code. The ACE
procedures by default are stored in Realtime\database\ACE\source. Once a breakpoint is set the
debugger can be used to step through the ACE code.
NOTE: The call stack, watch windows and other useful debugging tools are available while stepping
through the code.
48
4.9 ACE Methods

ACE allows public method calls from several OASySDNA assemblies.
An extensive list of methods can be found on any machine running OASyS DNA 7.6 or OASyS DNA 7.5
under the filepath: <InstallDirectory>\DNA\Documentation\HelpFiles\Realtime.chm.
The Code Editor methods table below contains only some of the commonly used methods. This table
does not include all methods that can be used with the code editor.
NOTE: When running an overload method, use the arrow keys to navigate the display instead of the on-
screen arrow buttons.
Table 14 - Code Editor methods

Method Description
AlarmDB (tableName, pointName, Used when non-baseline alarm generation is needed. It
fieldName, "alarmCategory", generates an alarm within the Alarm Summary.
"alarmMessage",
NOTE: Using Fldput to write a value to the current value field
persistentAlarmBool, flashingBool,
OASySDNA.Common.Severity, within a table, for example analog curval, generates
almPurgeTimeSecs) alarms when the current value moves into an alarm
condition.
tableName = the name of the RealTimeDB table, for example
analog. pointName = the name of the point, for example
stnXinputPres2. fieldName = name of field that is in alarm or
“”. alarmCategory = alarms are replaced within the same
category. If there are several alarm messages, but only one
should be visible in the alarm summary at a time, then give the
AlarmDB calls for those messages the same alarm category.
string.alarmMessage = the alarm message.
stringpersistentAlarmBool = a boolean that, when set to
true, indicates that the alarm should remain in the alarm
summary after it has been acknowledged. In this case, there
should be a return to normal alarm generated later that has
persistentAlarmBool set to false. flashingBool = a boolean
that indicates that the alarm should flash within the alarm
summary until the operator acknowledges it.
OASySDNACommon.Severity = an enumeration that sets the
severity level of the alarm (e.g.
OASySDNA.Common.Severity.LOW). The severity
enumerations include: HIGH, LOW, MEDIUM.
almPurgeTimeSecs = a short (i.e.16 bit integer) which defines
the time in seconds that the alarm should remain in the alarm
summary after acknowledgement when
persistentAlarmBool is set to false.
AlarmDB (tableName, pointNum, Similar to AlarmDB above, but it accepts a point number
fieldName, "alarmCategory", (ptnum field value) rather than the point name.
"alarmMessage",
persistentAlarmBool, flashingBool,
OASySDNA.Common.Severity)
AlarmAPP(string dbname, string Used to generate alarms for changes without having to directly
ptname, string fldname, string reference a database point. Instead of a point name, it accepts
description, string group, string any given string for the dbname, ptname, or fldname.
category, string almMsg,
Table continued…
49
Table 14 - Code Editor methods (continued)

Method Description
persistentAlarmBool, flashingBool, Refer to documentation on addAPPalarm in the BOR
OASySDNA.Common.Severity, short
Reference for more information on the individual parameters.
purgeTimer, string dataset, string
priorityDisplay)
AlarmSys ("Key", "alarmMessage", Used to generate a system alarm. The parameters are similar
persistentAlarmBool, flashingBool, to AlarmDB except that a user defined Key string is used to
"alarmCategory", differentiate the system alarms.
OASySDNA.Common.Severity,
almPurgeTimeSecs)
DNALog.WriteLog Used to write a message into the ACEEngine.log file within the
(DNALog.LogLevel, "LogMessage") Telvent\log directory.DNALog.LogLevel = the log level
enumeration to use (e.g. DNALog.LogLevel.Always) where the
supported enumeration values include: Always, DebugLog,
Exit, Fatal, Warning, Info and Verbose.LogMessage = the
message string. Always - Always logged to both error log files.
DebugLog - Always logged to the application file log. Exit -
Exits the application, not recommended for ACE. Fatal - Exits
the application, not recommended for ACE. Warning - Only
logged to application log file and only if debug level is toggled
Always and DebugLog. Info - only logged to application log file
and only if debug level is toggled Warning. Verbose - Only
logged to application log file and only if debug level is toggled
Info. To always log to both the oasErrLog and the ACEengine
log, set: DNALog.WriteLog(DNALog.LogLevel.Always,
logMessage). To log only to the ACEengine log, set:
DNALog.WriteLog(DNALog.LogLevel.DebugLog,
logMessage).
value = Fldget (tableName, Used to get a numeric value from a RealTimeDB point.
pointName, fieldName) tableName = the name of the RealTimeDB table (e.g. “analog”).
pointName = the name of the point (e.g. “stnXinputPres2”).
fieldName = name of field.
value = Fldget (tableName, Similar to previous Fldget, but expects a numeric point number
pointNum, fieldName) – the point’s ptnum field value, rather than a point name string.
value = FldgetString (tableName, Used to get a numeric value from a RealTimeDB point.
pointName, fieldName) tableName = the name of the RealTimeDB table (e.g. “analog”).
pointName = the name of the point (e.g. “stnXinputPres2”).
fieldName = name of field.
value = FldgetString (tableName, Similar to previous FldgetString, but expects a text point
pointNum, fieldName) number – the point’s ptnum field value, rather than a point
name string.
Fldput (tableName, pointName, Used to put a numeric value into the RealTimeDB point.
fieldName, value) tableName = the name of the RealTimeDB table, for example
analogpointName = the name of the point, for example
stnXinputPres2fieldName = name of field.
Fldput (tableName, pointNum, Similar to previous Fldput, but expects a numeric point number
fieldName, value) – the point’s ptnum field value, rather than a point name string.
It is recommended to place a try-catch block around the
method in order to trap exceptions that may occur during
normal operations (e.g. command failure due to remote offscan,
Table continued…
50

Method Description
writing new current value failed due to operator placing the
point into manual-override, command failure due to command
inhibit tag). If you do not use a try-catch block and an exception
is thrown, then the code following the method will not get
executed. If the exception is due to a temporary condition, then
the ACE code will execute again when the aceconfig record
execution is next triggered (see Types of Execution ). If the
exception is not due to a temporary condition, then the
aceconfig point is disabled, an alarm generated, and an event
logged.
FldputString (tableName, Used to put a numeric value into the RealTimeDB point.
pointName, fieldName, value) tableName = the name of the RealTimeDB table, for example
analogpointName = the name of the point, for example
stnXinputPres2fieldName = name of field.
FldputString (tableName, pointNum, Similar to previous FldputString, but expects a text point
fieldName, value) number – the point’s ptnum field value, rather than a point
name string.
Fnput (tableName, pointName, Sends a command to a point.tableName = the name of the
"command") RealTimeDB table, for example analog. pointName = the name
of the point, for example stnXinputPres2. command = the
command string. It is recommend placing a try-catch block
around the method in order to trap exceptions that may occur
during normal operations (e.g. command failure due to remote
offscan, writing new current value failed due to operator placing
the point into manual-override, command failure due to
command inhibit tag). If you do not use a try-catch block and an
exception is thrown, then the code following the method will not
get executed. If the exception is due to a temporary condition,
then the ACE code will execute again when the aceconfig
record execution is next triggered (see Types of Execution). If
the exception is not due to a temporary condition, then the
aceconfig point is disabled, an alarm generated, and an event
logged.
Fnput (tableName, pointNum, Similar to previous Fnput, but expects a numeric point number
"command") – the point’s ptnum field value, rather than a point name string.
Fnput (tableName, Execute an fnput command using a parameter's point number.
args(<parameterNumber>).PointNum Input parameter numbers start at 1. The output point is
ber, "command") referenced using a parameterNumber of 0.
value =GetEnumByName Get the numeric representation for an enumeration description.
("enumTypeName", This method is used to convert from a string description to an
"enumValueString") enumeration number.enumTypeName = the enumeration type
name, for example hilowstateenumValueString = the
enumeration descriptions, for example hi-hiExample:Dim
hiState as integer = GetEnumByName(“hilowstate”,”hi”)if
(input1 = hiState) Fnput(“status”,input2,”command stop”)End If
value = GetStatusByName Get the numeric representation of a status point state. This
("statusPointName", "stateName") method is used to convert from string to
number.statusPointName = the point name in the status
tablestateName = the status point’s state message text, for
example. Open.Example:Dim closeVal As Double =
Table continued…
51

Method Description
GetStatusByName(“myStatus”, “CLOSE”)Dim openVal As
Double = GetStatusByName(“myStatus”,”OPEN”)If (input1 =
closeVal) Then output = openValElse output = closeValEnd If
value = GetStatusByName Similar to previous GetStatusByName, but expects a status
(statusPtnum,"stateName") point number – the status ptnum field value, rather than a
status name string.
IsOutputFresh = True Used to directly set the output point's fresh state to the desired
value. In this case, "True".
Log ("LogMessage") Logs the message string to the Telvent\log
\ACEengine.log file.
value = Tnow () Get the current time in seconds UTC (formerly GMT) starting at
January 01, 1970.
value = UTCNowSeconds() Get the current time in seconds UTC starting at January 01,
1970.
SetFreshFunctionToAND() Used to control the ACE engine's calculation of the output
point's fresh state. This function sets ACE to use an AND
function (the default), which sets the output point's fresh state
to stale if any input database points are stale.
SetFreshFunctionToOR() Used to control the ACE engine's calculation of the output
point's fresh state. This function sets ACE to use an OR
function, which sets the output point's fresh state to fresh if any
input database points are fresh.
value = Parameter Property. True if the parameter has a dataset.
args(<parameterNumber>).HasDat
aset
value = Parameter Property. True if the parameter has a flag structure.
args(<parameterNumber>).HasFla
gs
value = Parameter Property. True if the parameter was fresh before
args(<parameterNumber>).IsFresh execution.
value = Parameter Property. True if the parameter was in error before
args(<parameterNumber>).IsInErro execution.
r
value = Parameter Property. The current value of the input point.
args(<parameterNumber>).Current
Value
value = Parameter Property. True if the parameter is a constant
args(<parameterNumber>).IsConst numeric value; false if it’s a database point.
ant
value = Parameter Property. The path to the database point (e.g.
args(<parameterNumber>).Databa analog.ana1.curval).
sePathString
value = Parameter Property. The key name for the database point (i.e.
args(<parameterNumber>).KeyNa ana1).
me
Table continued…
52

Method Description
value = Parameter Property. The database point number for this point.
args(<parameterNumber>).PointN
umber
WriteEvent (DNALog.EventType, Writes a message to the Windows Event Log.
"EventMessage.") DNALog.EventType = an enumeration which sets the event
type. The event types include: Error, Info, Success, Warning
(e.g.DNALog.EventType.Error). EventMessage = the message
string.
WriteEventSummary (tableName, Writes a message to the Historical Event Summary and the
pointName, "message") spool device associated with the point’s group. tableName =
the name of the RealTimeDB table, for example analog.
pointName = the name of the point, for example
stnXinputPres2. message = the event message
WriteEventSummary (tableName, Similar to previous WriteEventSummary but expects a numeric
pointNum, "message") point number, that is to say the point’s ptnum field value, rather
than a point name string.
4.10 ACE Code

ACE Code contains VisualBasic.net and C# coding language.
This section contains information on variables, subroutines, classes, execution, libraries and basic
syntax.
4.10.1 Variables
Table 15 - ACE Variables

Variables Description
output A numeric variable whose values are written into the ACE
output point.
input1, input2, ... inputX The value of the input parameters.
NOTE: The values of the constants, PubSub topics, or
database points defined in the ACE Config Editor
must be numeric.
args[0..n] The array of argument objects that correspond to the
output and inputs. Input parameters indices start at 1. The
output point is referenced using a index of 0. Each object
has the following properties that can be read, but should
never be written to:
• CurrentValueThe current numeric value of the input.
• DataBasePathStringThe database path to the input.
• HasDatasetTrue if this input is a database value and

the record has a dataset.
53
Table 15 - ACE Variables (continued)

Variables Description
• HasFlagsTrue if this input is a database value and the

record has a flag structure.
• IsInAlarmTrue if input alarm state is true.
• AlarmChangedInput alarm state has changed since

the last ACE execution cycle.
• IsConstantTrue if input is a numeric constant; false if a

database point.
• IsFreshTrue if this input has a fresh flag and is in a

fresh state.
• IsInErrorTrue if this input has and error flag and is in

error.
• KeyNameThe name of the database record.
• PointNumberThe database point number of this

record.
• SameAsOutputTrue if this input field and record is the
same as the output field and record.variable
input<parameterNumber> contains the value stored in
args[<parameterNumber>].CurrentValue.
Examples
Simple calculation:
output = (input1 / input2) + input3
Complex Procedure:
Dim pumpPtnum as integer = args(1).PointNumber
Dim pumpState as integer = input1
Dim tankLevel as integer = input2
If (( pumpState = GetStatusByName(pumpPtnum,"OPEN") ) and (tankLevel >

100)) Then
WriteEventSummary("status", pumpPtnum, "ACE: Turning pump off as the

tank level is too high")
Fnput("status", pumpPtnum, "Command CLOSE")
End If
54
4.10.2 Subroutines
New subroutines can be defined in the ACE procedure class.
This syntax shows how new subroutines can be defined in the ACE procedure class in VB.NET.
NOTE: The subroutines must be defined at the class scope.
NOTE: The ACE Editor must be taken out of simple mode to define subroutines.
Public Sub LogMessage(message As String)
DNALog.WriteLog(DNALog.LogLevel.Always, message)
End Sub
4.10.3 Classes
New subroutines can be defined in the ACE procedure.
This syntax shows how new subroutines can be defined in the ACE procedure class in VB.NET.
NOTE: Classes must be defined at the Namespace scope.
NOTE: The ACE Editor must be taken out of simple mode to define classes.
Public Class EnergyClass
Public Function GetEnergy( m As Double, v As Double) As Double
return m * v * v / 2
End Function
End Class
4.10.4 Execution of ACE Routines
aceconfig records with a dataset only execute on the HOT server owning that data.
aceconfig records without a dataset will execute, if triggered, on all HOT servers they are replicated to.
aceconfig records never begin execution on a non-HOT server, but they may complete execution on a
non-HOT server if it began while the server was HOT.
aceconfig records run under the following circumstances:
Triggered on changes to Inputs and input configuration changes: Execute�

Triggered on changes to inputs and input values change: Execute
Triggered on startup and server goes HOT: Execute�
Triggered on alarm and one or more inputs goes into alarm: Execute�
Triggered on alarm and one or more inputs goes out of alarm: Execute�
Manually commanded to run regardless of trigger settings: Execute�
Not enabled: Do Not Execute�
Trigger every X seconds and interval has passed: Execute�
55
4.10.5 Libraries
This is a list of libraries specific to OASyS DNA.
• "Interop.OASySDNA.CommonVB"
• "Interop.OASySDNA.Config"
• "Interop.OASySDNA.CPULib"
• "Interop.OASySDNA.FlagPackQual"
• "Interop.OASySDNA.ProcMon"
• "Interop.OASySDNA.RawCommonBase"
• "Interop.OASySDNA.RawCoreBase"
• "Interop.OASySDNA.Registry"
• "Interop.OASySDNA.UtilLib"
• "OASySDNA.Common"
• "OASySDNA.Common.Arbitration"
• "OASySDNA.Common.Config"
• "OASySDNA.Common.ProcessMonitor"
• "OASySDNA.Common.PubSub"
• "OASySDNA.Common.ServiceControl"
• "OASySDNA.Common.SQLEngineControl"
The following using statements are already pre-configured:
• "System"
• "OASySDNA.Common"
• "OASySDNA.Common.Config"
• "OASySDNA.Common.PubSub"
• "System.Runtime.InteropServices"
• "System.Collections"
• "System.Globalization"
• "System.Text"
4.10.6 Basic Syntax

This section describes some of the Visual Basic syntax that can be used for ACE programming. In later
versions of ACE, other languages such as C# are also available for scripting, but they will not be
discusssed here.
All ACE user code, whether it C# or VB, is embedded in a procedure inside a class. When editing in
™
simple mode, or on a OASyS DNA 7.4 system, this wrapping code is never seen. As a result, certain
™ ™
statements do not make sense in the user code. In OASyS DNA 7.6 and OASyS DNA 7.5 , simple
56
mode can be unchecked in the View Menu of the editor, allowing the full code to be viewed and all
keywords made available for use.
57
The wrapping code (shown below) is there so that the ACE programmer does not have to be concerned
about namespaces, classes, and so on.
Imports System
Imports OASySDNA.Realtime.HighPerformanceDB
Imports OASySDNA.Realtime.HighPerformanceSetDB
Imports OASySDNA.Realtime.ACE
Imports OASySDNA.Realtime
Imports OASySDNA.Common
Imports OASySDNA.Common.Config
Imports OASySDNA.Common.PubSub
Imports System.Runtime.InteropServices
Imports System.Collections
Imports System.Globalization
Imports System.Text
namespace OASySDNA.Realtime.ACE
Public Class ACE_MyProcedure Inherits ACEProcedure
Public Overrides Function Run(args As ACEParameter(), values As Double(),

runBecauseGoingHot As Boolean) As Double
Dim input1 As Double = values(1)

58
As a result of how the code is wrapped, the following keywords are not allowed:
• Module
• Class
• Function
• Sub
• Private
• Public
• namespace
• Imports
• End
• return
NOTE: Any keywords that are illegal result in a syntax error when compiled. ACE also does not allow
the use of theword “Static” as it causes strange behaviour when compiled in-memory.
Declaring Variables
This is the syntax for several declarations.
As shown by the wrapper code there are several input and output variables already declared in the ACE
procedure, but if more are needed, the syntax for several declarations is as follows:
Dim myInt As Integer = 0
Dim myInt As System.Int32 = 0
Dim myString As System.String = “”
Dim myDouble As System.Double = 0
Dim myUInt32 As System.Uint32 = 0
Dim myList As System.Collections.ArrayList = new

System.Collections.ArrayList(10)
59
If-Then-Else
This is the basic syntax for if-then-else statements.
A multiline if statement is shown below. This also shows the ElseIf construct.
If (input1 = input2) Then
input1 = input2
ElseIf (input1 > input2) Then
input2 = input1
Else
input1 = input2
End If
The If statements can also be single line as below:
If (input1 = input2) Then input = input2 Else input2 = input1
Looping
This is the syntax for several variations of looping.
The do loop is the most complex in that it has multiple forms. The first form is the Do While loop. This
loop is a typical while loop in that the condition is checked at the start of the loop and the loop
executes until the condition is false. The parentheses around the conditions are optional but aid
readability.
NOTE: This example also shows how to exit the do loop if desired.
Dim Check As Boolean
Dim Counter As System.Int32
Do While (Counter < 20 )
Counter += 1 ' Increment Counter.
If (Counter = 10) Then ' If condition is True,
Check = False ' Set value of flag to False.
Exit Do ' Exit loop.
End If
Loop
60
To ensure that the loop is run at least once, do the check at the end. This also applies to the Until
keyword which is discussed later.
Do
End If
Loop While (Counter < 20 )
To loop until a particular condition is true, instead of while it is true, use the Until statement as follows:
Do Until (Counter >= 20 )
End If
Loop
The for loop is another standard looping structure. With the for loop the variables are set forth at the
beginning of the loop and the loop auto-increments the variant until it reaches its goal. Most of the time
the loop variant is a numeric value, but this works for anything that support comparison operations and
the + operation.
Dim J As System.Int32
For J = 2 To 10 Step 2
Total = Total + J
If (J < 0) Then
Exit For
End If
Next J
61
Loops can be nested if desired. The following shows an example:

Dim J As System.Int32
For J = 2 To 10 Step 2
Total = Total + J
Dim Check As Boolean = True
Do Until (Counter >= 20 )
End If
Loop
If (Check = False) Then
Exit For
End If
Next J
62
Math Functions
The standard math functions are contained in the System.Math class.
63
The following commonly used operations are implemented as static methods of this class. They can be
accessed as shown and the double versions are shown by default.:
System.Double d = System.Math.Abs(value)
Returns the absolute value.
System.Double d = System.Math.Acos(value)
Returns the angle measured in radians whose cosine is value.
-1 <= value <= 1
0 d
Returns NaN if value is invalid
System.Double d = System.Math.Asin(value)
Returns the angle measured in radians whose sine is value.
- /2 d /2
System.Double d = System.Math.Atan(value)
Returns the angle measured in radians whose tangent is value.
-/2 d /2
Returns NaN if value is Nan.
System.Double d = System.Math.Atan2(value_x, value_y)
Returns the angle measured in radians whose tangent is the quotient of the
two numbers value_x and value_y where value_x and value_y are co-ordinates
on the cartesian plane.
- d
System.Int64 a = System.Math.BigMul(int1, int2)
Returns a 64-bit result from the multiplication of two 32-bit integers.
System.Double d = System.Math.Ceiling(value)
Returns the smallest integer greater than or equal to the input.
System.Double d = System.Math.Cos(value)
Returns the cosine of an angle measured in Radians.
System.Double d = System.Math.Cosh(value)
Returns the hyperbolic cosine of an angle measured in Radians.
System.Int32 d = System.DivRem(int1, int2, out int3)
Return the remainder of int1 / int2.
Remainder is also returned in int3.
All integers are either System.Int32 or System.Int64.
System.Double d = Exp(value)
Returns e raised to the power of value.

64
System.Double d = Floor(value)
the midpoint (i.e., x.5).
MidPointRounding = AwayFromZero means round to the next integer away from

zero.
MidPointRounding = ToEven means round to the nearest even number.
System.Double d = Round(value, precision, midPointRounding)
Returns value rounded to the desired precision using the midPointRounding

for values at the midpoint.
Round(3.45, 1, midPointRouding.AwayFromZero) = 3.5
Round(3.45, 1, midPointRouding.AwayFromZero) = 3.4
System.Double d = Sign(value)
D = -1 if value is < 0, 0 if value = 0, 1 if value > 0
System.Double d = Sin(value)
Returns the sign of the specified angle measured in Radians.
System.Double d = Sinh(value)
Returns the hyperbolic sine of the angle measured in Radians.
System.Double d = Sqrt(value)
Returns the square route of the value.
System.Double d = Tan(value)
Returns the tangent of the angle measured in Radians.
System.Double d = Tanh(value)
Returns the hyperbolic tangent of the angle measured in Radians.
Collections
Microsoft provides the collections namespace. This namespace is packed with useful collection classes.
�System.Collections.ArrayList
System.Collections.BitArray
System.Collcetions.Stack
System.Collections.Queue
System.Collections.Hashtable
For details on using these classes, see the Microsoft documentation.
65
Arrays
Arrays are a special type of primitive collection. Array methods can be accessed from the array class
and from an array object.
The following methods on the array object are useful for the ACE argument arrays.
Args.Count(0) = number of elements in the single-column argument array.
Args[index] accesses the element in the args array at position index.
High Performance Database

Even though access is provided to the high performance database classes, these operations can be
done more efficiently using the ACE mechanisms and code helpers.
66
Executing processes
It is possible to execute scripts and other executable processes from the ACE code.
This is accomplished using the OASySDNA.Common.ProcessUtilities class for which the following
static methods are defined:
bool DoesProcessExist(int processId);
int GetNumberOfProcessesRunning(string processName);
void KillProcess(int processId);
Binaries for the following must be in %OASySDNA%\bin:
void ExecuteBinary(string name, string parameters);
void ExecuteBinary(string name, string parameters, int maxWaitSecs);
void ExecuteBinaryAsynchronously(string name, string parameters);
The following executes an arbitrary file from a command shell:
void ExecuteCommandString(string commandString, int maxWaitSecs, bool

useShell);
Scripts for the following must be in %OASySDNA%\scripts:
void ExecuteScript(string scriptName, string parameters);
void ExecuteScript(string scriptName, string parameters, int maxWaitSecs);
void ExecuteScriptAsynchronously(string scriptName, string parameters);
Scripts for the following must be in %OASySDNA%\scripts\<serviceName>
void ExecuteServiceScript(string serviceName, string scriptName, string

parameters);
void ExecuteServiceScript(string serviceName, string scriptName, string

parameters, int maxWaitSecs);
void ExecuteServiceScriptAsynchronously(string serviceName, string

scriptName, string parameters);
67
4.10.7 Variables provided to ACE

ACE procedures have several bits of information defined that they can access. Some of these are
passed in as arguments to the method, and others are members of the enclosing class.
The following information is passed in as arguments to the method:

ACEParameter[] args
An array of ACEParameter objects that contain the parameter information

for the procedure. ACEParameter objects are described below.
double[] values
An array of doubles representing the inputs.

bool runBecauseGoingHot
This boolean value is true if the ACE Engine has just become hot. Otherwise, it is false. Routines that
are executed on exception are always executed when the ACE Engine goes hot because it is impossible
to detect whether a change has occurred during a failover.
The following methods are used by ACE internally and should not be called from within an ACE
procedure:
SetUpDBAccess()
GetDBData()
PutDBData()
UpdateFlags()
Dispose()
The following members are defined for the ACE procedure and can be accessed by the ACE routine.
DoRun As Boolean
The DoRun flag from the database. If true then this routine was triggered
by setting this flag in the database record.
CodeVersion As System.Int16
A version number for tracking code changes.
ExecutingTime As Integer
The amount of time in milliseconds that this procedure has taken to

execute.
IsOutputFresh As Boolean
The fresh flag for the output point that will be written to the database.
This flag can be changed to manually set the fresh value from within a
routine.
UseAndForFresh As Boolean
By default this is set to true meaning that an output record is marked as fresh if ALL of the inputs are
fresh. Changing this to false means that the output record will be marked as fresh if any of the inputs are
fresh.
68
ACE Reference Assemblies
5 Assemblies
5.1 Compiling from the ACE Editor with added assemblies...................................................................69
5.2 Referencing External Assemblies.....................................................................................................69

5.3 Available Assemblies........................................................................................................................70
ACE scripting, like scripting in other OASyS DNA products such as XE, relies on .Net assemblies to
provide the classes and the methods required for use by your scripting code. Some of the necessary
assemblies are loaded in automatically for the code to reference.
A list of the default assemblies available to ACE code can be found in Available Assemblies. In addition
to the default assemblies, ACEEditor and ACEEngine each have their own Assembly List files.You can
add new assemblies into either file to extend scripting support available to ACE code. Additional
assemblies are integrated into the system and all of the default assemblies and the assemblies that
appear in both files get loaded into the ACEServer and ACEClient, which provides Intellisense for a
greater number of assemblies.
Any assemblies used by ACE code must be installed on all RealTime servers running or compiling that
ACE code. Extending scripting in this way can give you access to assemblies that are not included by
default, in addition to access to third party assemblies. Modifying the available assemblies affects both
the RealTime operation of the ACE Engine as well as compiling and intellisense in the ACE Editor.
Related Information
Intellisense on page 45
5.1 Compiling from the ACE Editor with added assemblies

The ACE Editor uses an OASyS DNA BLT component to invoke the compiler on a RealTime host.
This means that the ACE code is not necessarily compiled on the same machine that the ACE Editor is
running on, but rather it is compiled on the RealTime host that the ACE Editor is connected to. In OASyS
™ ™
DNA 7.6 and OASyS DNA 7.5 this is determined through the DAL connection screen. In OASyS DNA
™
7.4 it is the local RealTime server associated with the ACE Editor host.
After an assembly has been added to the assembly list, ensure that the updated assembly list is on the
RealTime server where the ACE compile is to take place.
Attaching to a RealTime server other than the Engineering Station itself requires that the assembly list is
updated on the other server, otherwise the compile will fail if the new assemblies are used.
69
Assemblies ACE Reference
5.2 Referencing External Assemblies

Assemblies can be added to the ACE system by editing either the AssemblyList.xml file or the
EditorAssemblyList.xml file. Both files are located in <InstallDirectory>ACE\config
\EditorAssemblies.
The ACEEditor assembly file is called EditorAssemblyList.xml and provides assemblies that can be
used for Intellisense. It should only contain assemblies that will be available on the editing station and is
installed with an ACEEditor installation.
The ACEEngine assembly file is called AssemblyList.xml and provides assemblies that can be used to
affect the way ACE compiles code. It is installed with an ACEServer installation.
NOTE: RealTime has to be restarted in order to make the new assemblies available to code.
The XML file should be edited at the Engineering Station and then distributed to all RealTime computers
in order to keep available assemblies consistent.
NOTE: The assemblies can only be found in two places; either in the Global Assembly Cache (most
third party assemblies are located here ) or the .dll file that is located under telvent\bin (any
custom assemblies are compiled here). Before an assembly list can be used by the ACE Engine
it must be distributed to all RealTime servers.
70
ACE Reference Assemblies
5.3 Available Assemblies

The following assemblies are available for use in ACE code by default.
Interop.OASySDNA.Adodb
Interop.OASySDNA.CommonVB
Interop.OASySDNA.Config
Interop.OASySDNA.CPULib
Interop.OASySDNA.FlagPackQual
Interop.OASySDNA.ProcMon
Interop.OASySDNA.RawCommonBase
Interop.OASySDNA.RawCoreBase
Interop.OASySDNA.RawDB
Interop.OASySDNA.RawSecurity
Interop.OASySDNA.RawVDB
Interop.OASySDNA.Registry
Interop.OASySDNA.FlagPackQual
Interop.OASySDNA.Security
Interop.OASySDNA.SQLSchemaChange
Interop.OASySDNA.UtilLib
OASySDNA.Common
OASySDNA.Common.Arbitration
OASySDNA.Common.Config
OASySDNA.Common.ProcessMonitor
OASySDNA.Common.PubSub
71
Assemblies ACE Reference
OASySDNA.Common.ServiceControl
OASySDNA.Common.SQLEngineControl
OASySDNA.Realtime.ACE
OASySDNA.Realtime.Alarm
OASySDNA.Realtime.DistribuSys
OASySDNA.Realtime.HighPerformanceDB
OASySDNA.Realtime.HighPerformanceSetDB
OASySDNA.Realtime.Security
OASySDNA.Realtime.Spooler
OASySDNA.SQLEngine.DataStore
OASySDNA.SQLEngine.Security
System
System.Data
System.XML
System.Drawing
System.Windows.Forms
72
ACE Reference Examples
6 Examples
6.1 Dual Inputs........................................................................................................................................73
6.2 Variable Parameters.........................................................................................................................74

6.3 Launching an executable..................................................................................................................77
6.4 Calculating a volume........................................................................................................................77
6.5 try-catch............................................................................................................................................77
6.6 fldget and fldput................................................................................................................................78
6.7 Changing a status point....................................................................................................................78
A list of common code examples that can be used with the Code Editor.
6.1 Dual Inputs

Given two sets of inputs, you can determine which input is fresh and only use that value in the
calculation.
It is also recommended that you selectively update the fresh flag based on the fresh values of the
inputs. This code defines two variables, Primary and Secondary, to represent the inputs that can be
73
Examples ACE Reference
selected. The fresh flag is used to determine which value is the active one. In this example, the
argument array is used rather than the input shortcut variables like input1 and input2:
Dim Primary As ACEParameter = args(1)
Dim Secondary As ACEParameter = args(2)
If (Primary.IsFresh) Then
output = Primary.CurrentValue
IsOutputFresh = True
DNALog.WriteLog(DNALog.LogLevel.Always, "Using Primary")
Else If (Secondary.IsFresh) Then
output = Secondary.CurrentValue
IsOutputFresh = True
DNALog.WriteLog(DNALog.LogLevel.Always, "Using Secondary")
Else
IsOutputFresh = False
DNALog.WriteLog(DNALog.LogLevel.Always,
"All Lines are down for point " + args(0).KeyName + ".")
End If
74
6.2 Variable Parameters
75
This example shows how to determine which inputs are used and which are not. This routine performs
an addition between any number of inputs up to 9.
output = 0
If Not(args(1) Is Nothing) Then
output += input1
End If
output += input2
End If
output += input3
End If
output += input4
End If
output += input5
End If
output += input6
End If
output += input7
76
End If
output += input8
End If
output += input9
End If
6.3 Launching an executable

For ACE to trigger a series of events that are very time consuming, you can write a separate executable,
and then have ACE call that executable. The following code runs an executable from ACE. The
command HelloACE.exe must be on the path.
�OASySDNA.Common.ProcessUtilities.ExecuteBinaryAsynchronously
("HelloACE.exe", "")
6.4 Calculating a volume

The following piece of code calculates the volume of a cylinder and illustrates the use of the
System.Math class.
Dim Height As Double = input1
Dim Radius As Double = input2
output = System.Math.Pi * System.Math.Pow(Radius, 2) * Height
6.5 try-catch
If an error is expected, one that is not critical to the aceconfig record, then try-catch is used to trap it.
This is only to be used for expected errors, ones that should not cause the aceconfig record to be
disabled. All other errors are ignored so that ACE can effectively manage the execution of ACE points
and alarms when things go wrong. To catch a specific error, substitute the type of error to be caught for
77
the word “Exception”. For example “catch DNAException” catchs all OASySDNA exceptions that are
thrown.
Try
Dim i As Integer
Dim j As Integer = 0
i = 1 / j
Catch ex As Exception
DNALog.WriteLog(DNALog.LogLevel.Always, "Caught an error")
End Try
6.6 fldget and fldput

The fldget and fldput commands are used to interact with the RealTime database. The following
piece of code illustrates the use of these commands.
Dim prevValue As Double = Fldget("analog", "acetest1", "curval")
Fldput("analog", "acetest1", "curval", 6)
Dim OPEN As Double = GetStatusByName("acetest10","OPEN")
Fldput("status", "acetest10", "cursta", OPEN)
Fldput("analog", "acetest1", "curval", prevValue)
6.7 Changing a status point

The following example illustrates how to change a status value based on two inputs. The first input is
meant to be an analog value that is varying. The second input is meant to be some deadband value for
78
setting the status point. The GetStatusByName is needed here so that the status string value can be
mapped to a numeric status value that ACE understands.
' Close an object based on input.
If (input1 > input2)
output = GetStatusByName(args(1).KeyName,"CLOSE")
End If
79
Troubleshooting ACE Reference
7 Troubleshooting
7.1 ACE disabled on failover..................................................................................................................80
7.2 BLT ACE crashes..............................................................................................................................80

7.3 ACE Code aborts without warning....................................................................................................80
This section contains information on troubleshooting common ACE difficulties.
7.1 ACE disabled on failover

If ACE points are being disabled on failover it is likely because ACE is trying to run something on the
standby machine that is causing an exception. There is a known race condition that can cause this to
happen. It only affects one or two ACE points when it occurs, and from then on every point only
executes on the hot machine.
By default, ACE catches DNAExceptions related to execution on the standby machine and does not
disable the ACE routine. However, if you are using these routines with non-baseline tables such as LMS
tables these exceptions may not be caught and you may need to add try-catch statements to your code.
7.2 BLT ACE crashes

There is a known memory fragmentation problem with Microsoft’s .Net product. This affects ACE
because all of the BLT components in BLT ACE are .Net components. This error occurs because the
ACE BLT components try to access the RealTime database while they have already allocated some
memory in the .Net managed heap. As a result of this memory allocation, there is not a large enough
block of continuous memory to load the RealTime database. The solution is simply to set the
OAS_MAX_VIRTUAL registry entry to a lower number. By default, usually halving the number will work,
but you can try increasing this if needed until the problem happens again.
7.3 ACE Code aborts without warning

If an exception is thrown by your ACE code, and that exception is not caught within your ACE code, then
the ACE code will abort and the exception will be caught by the ACE Engine. If the exception is caused
by a temporary condition (such as a command inhibit tag, owning system unavailable, point in manual
data override or offscan), then the ACE Code aborts without any alarms or events. However, the ACE
code is able to execute again when its configured execution trigger next occurs. If the exception is not
considered a temporary condition, then it is treated as a severe coding error and the aceconfig record is
disabled so that it will not run until it is manually repaired, an alarm is generated, and an event is logged.
80
ACE Reference Troubleshooting
To guarantee that code will always execute to completion, despite exceptions thrown by temporary
conditions, it is recommended that you place try-catch code around methods that throw exceptions. This
includes methods:
fnput
fldput
Related Information
fldget and fldput on page 78
81
Schneider Electric
49 Quarry Park Blvd SE
Calgary, AB T2J 6V8 - Canada
Phone: 1 (403) 253-8848
www.schneider-electric.com
As standards, specifications, and designs change from time to time,

please ask for confirmation of the information given in this publication.
© Schneider Electric. All Rights Reserved.

ACEReference ElkSP4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ACEReference ElkSP4

Uploaded by

Copyright:

Available Formats

OASyS DNA®

7.3 ACE Code aborts without warning................................................................................................80

1.2 Product Pieces....................................................................................................................................8

1.5 Registry Variables.............................................................................................................................11

1.6 Error Messages................................................................................................................................12

1.7 Arbitration States of Multithreaded ACE...........................................................................................16

ACE procedures can be triggered:

• Whenever there is a change to input parameter's numeric value.

• On alarm (if a path input point changes alarm state).

• On startup (going hot from standby state during startup or failover).

1.1 Product Description

Inputs and Outputs

• less than or equal

• greater than or equal

• Periodically (specifiable in seconds).

• On alarm change for a RealTime path.

Special Output Handling

1.2 Product Pieces

The ACE product consists of the following parts:

• ACE BLT components

There are two databases in the RealTime system to support ACE:

1.3 Execution Model

Figure 1 - ACE Execution Model

1.5 Registry Variables

Table 1 - ACE Registry Variable descriptions

Table 1 - ACE Registry Variable descriptions (continued)

the machine only has 8 cores, ACE will only use 7

1.6 Error Messages

ACE log messages are stored in: log\ACEEngine.log

1.6.1 Configure error messages in OASyS DNA

1. Create a new XML file called ACE.xml.

• Procedure timeout value (WARNING: ACE config <AceconfigName> procedure

3. Save the ACE.xml file in config/registry.

1.6.2 Configure error messages in OASyS DNA 7.4

Before you begin

1.6.3 Enable logging

Ex: toggleDebug -p 1234

Table 2 - Debug Levels

1.6.4 Bad Code Detection

1.6.5 Exception handling

Exceptions that do not disable aceconfig, but log an error message

Infrequent messages that are logged at a DebugLog level in the oasErrLog:

Exceptions that will disable the aceconfig record

1.7 Arbitration States of Multithreaded ACE

aceconfig <name> interrupted during execution as a result of a shutdown

1.7.1 Arbitration Status

For further information, refer to the Arbitration section.

Table 3 - Arbitration Status Icons

Table 3 - Arbitration Status Icons (continued)

2.2 Aceconfig Row Edit: Trigger Configuration Tab................................................................................21

2.4 Job Scheduler Records....................................................................................................................25

2.5 Record Fields and Flags...................................................................................................................25

2.6 Output Record Flags.........................................................................................................................28

2.7 Types of Execution...........................................................................................................................30

2.8 Disabling and enabling an ACE record.............................................................................................31

Figure 2 - Aceconfig Table

2.1 Aceconfig Row Edit: Main Tab

Figure 3 - Aceconfig Row Edit: Main Tab

Table 4 - Aceconfig Row Edit: Main Tab description

2.1.1 Output Point Path Selector

Figure 4 - ACE Output Point Path Selector

Table 5 - ACE Output Point Path Selector description

2.2 Aceconfig Row Edit: Trigger Configuration Tab