Short introduction: TwinCAT ADS

Basic structure of ADS devices and ADS symbols

Automation Device Specification (ADS) is the basis for the Interface for MATLAB^®/Simulink^®. ADS describes a device- and fieldbus-independent interface and enables communication between ADS devices.

The ADS device concept and the identification of an ADS device are explained below.

The modular system architecture of TwinCAT allows the individual parts of the software (e.g. TwinCAT PLC, TwinCAT NC ...) to be regarded as independent devices: there is a software module for each individual task. The servers in the system are the executing devices that provide certain services. The clients are programs that request the services of the servers. A client initially establishes a connection to the server and requests a service: for example, it requests reading the value of a variable or it requests writing a variable.

The Interface for MATLAB^®/Simulink^® provides an ADS client interface for Simulink^® and MATLAB^®, which enables data exchange (read and write) with TwinCAT runtimes. The TwinCAT runtime, or its ADS devices, thus provide their services as ADS servers and can be used from LabVIEW™.

In addition, the interface for MATLAB^®/Simulink^® provides an ADS server for MATLAB^® so that a MATLAB^® environment can provide services to ADS clients.

ADS data exchange between ADS devices takes place via the ADS router. As shown in the diagram above, data exchange between ADS devices implemented on the same system takes place via the system memory. If two ADS devices, e.g. MATLAB^® and the TwinCAT runtime are on different systems, a route can be created between two ADS routers. When creating the ADS route, the transport type (usually TCP/IP) for communication between the two ADS routers can be defined. Accordingly, an ADS device identifies itself via the AMS NetId of the ADS router and a port number, which then specifies the ADS device on the system. For example, port 851 is the default port for the first PLC instance in the TwinCAT runtime. ADS services of an ADS device are then specified by two parameters, the index group and the index offset. For example, a PLC variable is accessible for reading or writing under a specific index group and index offset.

Summary

• AMS NetId: identifies the ADS router, i.e. the system.
• ADS Route: specifies the connection between two ADS routers.
• Port: identifies an ADS device.
• Index Group/Offset: specifies the ADS system service, e.g. a variable for reading and writing.

In order to make the addressing of variables in a TwinCAT runtime more convenient for the user, TwinCAT creates ADS symbols, which can be searched with the Target Browser, for example. The Target Browser is also integrated in the interface for MATLAB^®/Simulink^® in the TC Symbol Interface, so that ADS symbols can be selected easily and quickly. An ADS symbol for a variable in TwinCAT then contains the information mentioned above: AMS NetId, Port, Index Group and Index Offset and furthermore the Bit Size as well as a symbol name and the data type of the variable.

For more information on ADS, please see the following links:

• AMS NetId and Port: ADS device identification
• Index Group and Index Offset: Specification for ADS devices
• ADS Routes: System Node "Routes" and Add Route
• Connecting Devices with same AMS NetId: AmsNAT
• Using MQTT and Message Broker with ADS: ADS-over-MQTT
• TLS encrypted ADS: Secure ADS
• Target Browser: Target Browser
• Record ADS communication: ADS Monitor

Basic ADS data communication

Basically, ADS has three different ways/modes of communicating data:

Synchronous reading or writing

• The ADS client waits for response from the ADS server before proceeding with the execution of the code.

Asynchronous reading or writing

• The ADS client sends a read or write request to the ADS server, but does not wait for a response; instead, it continues to execute other parts of the program (e.g., requests to other variables).

Event-based communication (read only)

• An ADS notification is only registered once on the server. The notification can be registered "on change" or "cyclic". After a notification has been registered at the server, it is sent to the server without any further requests from the client.