Communication modes
Initial classification
The extensions to the basic functionalities (sync, async and notification) are explained below. Practical recommendations are also given as to which mode is a preferred choice for exemplary applications.
The following table shows all provided modes with an initial classification.
Mode | Read | Write | Short description |
|---|---|---|---|
X | X | Read/write a variable in a self-contained one-time action. The client waits during the request to the server. | |
X | X | Read/write a variable in a self-contained one-time action. The client does not wait during the request to the server. | |
X |
| Waiting for an "On Change" event in TwinCAT as a one-time action. The notification is unregistered after the event. | |
X |
| One-time reading of a time series with a defined length. The notification is unregistered after receiving the time series. | |
X |
| Continuous reading (cyclic or "on change"). The notification is not automatically unregistered; it runs until it is explicitly unregistered. The notifications received are forwarded to an event structure in LabVIEW™. | |
X |
| Buffered continuous reading (cyclic or "on change“). The notification is not automatically unregistered; it runs until it is explicitly unregistered. The notifications received are forwarded to an event structure in LabVIEW™. The buffer enables higher data throughput, but causes latency. | |
X |
| Continuous reading (cyclic or "on change"). The notification is not automatically unregistered; it runs until it is explicitly unregistered. On the LabVIEW side, the data is written to a buffer to which the user has direct access. |
In the table above some modes are assigned the property "Buffered". The diagram below illustrates the system structure. For "Noti. Buffered" and "E-Noti. Buffered", the addressed buffer refers to a LabVIEW™-side buffer of size LVBufferSize. The buffer is filled with data read from TwinCAT and transferred to LabVIEW™ when the buffer size is reached. In addition, there is a TwinCAT-side buffer from the standard ADS interface, which, however, can only be used with ADS notifications of the type Cyclic. By default the size of this buffer is TcBufferSize = 10 samples, although it can be adjusted.
In the following section, the above example is considered with the following parameters:
TcBufferSize = 10
LVBufferSize = 500
ADS notification of the Cyclic type with 1 ms sample time (corresponds here to the cycle time of the PLC).
Every 1 ms a sample is now written into the TwinCAT-side buffer. After 10 ms the buffer is full and is transferred to the LabVIEW™-side buffer. After receiving 50 messages with 10 samples each, i.e. after 500 ms (plus communication time), the LabVIEW™-side buffer is full and then transfers the entire data packet of 500 samples to LabVIEW™. Accordingly, there is a delay time of at least 500 ms until the data packet is received in LabVIEW™. The minimum expected delay time is also displayed in the configuration dialog (Edit Symbol Parameters) in the lower part as "Expected min delay".
Parameterizing and realizing the communication modes
The parameters mentioned in the above section can be set in the User Interface (UI) of the Symbol Interface.
In addition to the parameterization of the ADS symbols, the basic structure of the LabVIEW™ program must be observed, which is outlined below.
The Symbol Interface opens a dialog with the Target Browser and the possibility to parameterize each ADS symbol according to the above figure. The output of the Symbol Interface is a string in XML format describing all selected ADS symbols and their parameterization. This string is linked to the Init VI. Alternatively, the Symbol Interface can export the XML. This XML file can then be passed directly to the Init VI. The Init VI then passes handles of the ADS symbols to a Read VI, which can be set as a polymorphic VI to the options described above. At the output there are data handles, which are linked with a Type Resolver VI. The output of the Type Resolver VI is a Variant Type, which can be cast to the correct format. When writing, the order of Type Resolver and Write VI is reversed accordingly.
The above diagram illustrates the structure with Low Level VIs. To simplify programming, several Low Level VIs are combined, depending on the communication mode. See Sync Read or Async Read, for example.
Practical considerations
There are various options for reading data. In order to simplify the selection in practice, a table is provided below which describes exemplary application scenarios and suggests a communication mode.
Signal type in | Example | Communication mode |
|---|---|---|
Quasi-static | Read the current parameter set of a PID controller or the ID of the current product in the machine. | |
Continuous | Stream of one or more sensor signals (temperature, strain, force, …). There is no defined end of the data stream. | Fast response required: E-Noti. Single (Transmode "cyclic") |
High data throughput: E-Noti. Buffered or LVB-Noti. Single | ||
Event | Waiting for TwinCAT event, e.g. start of a process: bStart changes from FALSE to TRUE. | Noti. Single (Transmode "on change") |
Event | Responding to changes in states, e.g. changing the signals to be read depending on the state of the machine: The event occurs frequently and this event should be observed throughout. | E-Noti. Single (Transmode "on change") |
Signal of defined length | Reading of exactly 1000 samples of a specific sensor signal. |