ATLAS 10 Automation API

This introductory documentation is designed for Atlas 10 users who want to utilise the Atlas 10 Automation API as a replacement for their existing tooling that currently leverages the A9 Automation API. It is assumed that those using this document are familiar with basic programming principles and the usage of Atlas 9 & 10 applications. When finalised, that Atlas 10 Automation API documentation will be part of the Atlas 10 help file. Please refer to the attached "ATLAS 10 COM API migration guide".

Atlas 9 API Architecture

ATLAS 9 supports ActiveX Automation as a Multiple-Use Automation Server. This allows an ATLAS application to be controlled by other ActiveX components such as:

• Visual Basic
• Visual Basic For Applications
• MATLAB

Any such program can:

• extract data and other information from ATLAS
• navigate through the exposed object mode
• retrieve data from the sessions loaded into ATLAS
• be embedded within the ATLAS workspace in an InPlace Display

Atlas 10 API Architecture

This diagram shows that existing tools will need to swap to use the new A10 COM API, which has been designed to be as close to the existing A9 API as possible.

The WCF API is the new A10 Automation API, see attached "ATLAS 10 Automation API Guide 1.0.pdf". This will be actively developed and improved.

The COM API has a limited shelf life. It will not receive active development and will be obsolete end of 2018.

Approach

The Atlas 10 Automation API will include a COM API which will, as closely as possible, match the existing A9 COM API. This will allow users to keep their existing tooling without a large amount of re-work or script updates.

As this is a transitional piece of work to aid migration to the full A10 API, the COM API will have a limited shelf-life and will not be developed once released.

Included with this overview is a list of all the A9 objects and methods that MAT intend to implement. Also, there is a release of A9 that includes a cut down version of the A9 API so that users can compile their tools against what is proposed to be included in that new A10 COM API. This will give users the opportunity to raise any missing methods and grievances with the proposed solution.

Atlas 9 Compatibility – Aims

• A10 API will expose on a like for like basis most commonly used A9 APIs
  • Some less common/esoteric APIs may only be accessible via WCF
• Minor changes required to run existing Scripts
  • Such as updating TLB/ProgId/manifest to target ATLAS 10 rather than ATLAS 9
• ATLAS 9 to be able to coexist with ATLAS 10
  • Updated APIs to support ATLAS 10 only functionality
• Such as Compare Sets
• Aim to support existing ATLAS 9 samples as a minimum

Limitations

• Some objects may not refresh correctly if the UI is updated manually.
• Cannot retrieve Layers when  a Session has not been loaded yet.
• Possible mismatches in lap times of 1 microsecond due to rounding double types.
• When loading sessions, the layer's index is ignored. Sessions will be added on the layers sequentially.
• Parameters.Remove does not remove in-memory channels.
• SessionLoaded is asynchronous therefore consecutive calls may fail until the session is fully loaded. Wait until OnSessionLoaded event is invoked is recommended.
• A10 has no concept of Layers so be very careful with every script that uses the Layers object. Layers are only accessible once a session has been loaded. Therefore if the session can not be loaded it is recommended to wrap Layers.Layer[] in at try/catch.
• Some objects which represent state of the application such as Displays or Layers might not reflect the changes. It is recommended to create new instances if changes are made to the application.
• Some Parameter properties do not exist in the IParameter interface returned. To access them it is recommened to cast the returned object to ATLAS10.Parameter.
• OnTelemetryStarted event is invoke after processing the PGVs, therefore there is a delay between the start recording action and the event invocation.
• CloseSession uses Layer number, not Index.