Basic examples

A large number of basic examples are included in the LabVIEW™ environment during the installation of the Interface for LabVIEW™. These can be found with the help of the NI Example Finder.

The following keywords facilitate the search for the examples:

The NI Example Finder can be started in LabVIEW™ under Menu > Help > Find Examples.

Basic examples 1:

Likewise, you can find all examples via the Directory Structure at
Beckhoff Automation > Beckhoff-LabVIEW-Interface.

The examples are categorized into the communication modes described at the beginning of the documentation:

One-time reading

Simple Read with TypeResolving.vi

The example, like the other examples in Basic examples, uses the basic VIs from the LabVIEW™ VIs in the following steps:

  1. In the first step, the Symbol Interface basic block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The ReadGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example, Index Array selects the first ADS symbol in the list.
  4. After initialization the polymorphic ADS-Read block is called. The Read Choice input can be used to select which read mode is to be used. The Read Choice input is a LabVIEW™ Enum and provides the following options:
    • Read Sync: For this, a synchronous read request is first sent to the TwinCAT runtime and a response is waited for. The received ADS data packet is then converted from raw data to the LabVIEW™ data type "Variant" using the TypeResolver.
    • Noti. Single: For this, an ADS notification is registered and individual received notifications are passed on to LabVIEW™. After reading the notification, the notifications are unregistered again. The received ADS data is then converted from raw data to the LabVIEW™ data type "Variant" with the help of the TypeResolver.
    • Noti. Buffered: For this, an ADS notification is registered and a block of received notifications is passed on to LabVIEW™. The number of notifications buffered in the block is determined by the LVBufferSize symbol parameter. After reading the notifications, they are unregistered. The received ADS data is then converted from raw data to the LabVIEW™ data type "Variant" with the help of the TypeResolver.
  5. Interaction: Variant-to-Data can be used to customize the example to translate the Variant to an appropriate data type. The data type depends on the ADS symbol selected in the Symbol Interface. See Type Resolving.
  6. In the last step, the Release basic block is called and the ADS client is released from memory.

Notice

Noti. Single

Noti. Single supports only the Transmode=OnChange

Read Async with TypeResolving.vi

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the Symbol Interface basic block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime.
    • If you have already exported an XML description of the ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The ReadGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example, Index Array selects the first ADS symbol in the list.
  4. After initialization the With TypeResolving block is called. An asynchronous read request is sent to the TwinCAT runtime for this purpose. The program code continues running without waiting for feedback.
  5. In this example, the Read low-level block is called in a while loop, waiting for a response from the addressed ADS server. Please note that this is an illustrative example. The implementation in actual applications may differ considerably. Once feedback has been received, the received data packet is converted to the appropriate LabVIEW™ data type "Variant".
  6. Interaction: Variant-to-Data can be used to customize the example to translate the Variant to an appropriate data type. The data type depends on the ADS symbol selected in the Symbol Interface. See Type Resolving.
  7. The next step is to call a Read low-level block and thus release the Reader from memory.
  8. In the last step the Release basic block is called and thus the ADS client is released from memory.

One-time writing

Write Sync with TypeResolving.vi

The example, like the other examples in Basic examples, uses the basic VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Symbol Interface block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The WriteGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example, Index Array selects the first ADS symbol in the list.
  4. Interaction: Insert the appropriate data type in the place marked in red. The data type depends on the ADS symbol selected in the Symbol Interface. See Data types.
  5. After initialization, the block Write Sync Single TypeResolved is called. For this purpose, the raw data is first converted from the LabVIEW™ data type to a suitable TwinCAT 3 data type and then a synchronous write request is sent to TwinCAT. The block waits for a response from the server to ensure that the data was sent successfully.
  6. In the last step the Release basic block is called and thus the ADS client is released from memory.

Write Async with TypeResolving.vi

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Symbol Interface block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The WriteGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example, Index Array selects the first ADS symbol in the list.
  4. Interaction: Insert the appropriate data type in the place marked in red. The data type depends on the ADS symbol selected in the Symbol Interface. See Data types.
  5. After initialization, the block Write Async Single TypeResolved is called. For this purpose, first the raw data is converted from the LabVIEW™ data type to a suitable TwinCAT 3 data type and then an asynchronous write request is sent to TwinCAT. The block does not wait for a response from the ADS server.
  6. In this example the low-level block CheckWriteStatus is called in a While loop and waits for a response from the requested ADS server. Please note that this is an illustrative example. The implementation in actual applications may differ considerably.
  7. The next step is to call the low-level block Release Writer to release the writer from memory.
  8. In the last step the Release basic block is called and thus the ADS client is released from memory.

Reading data continuously

The examples in this group use the polling procedure or LabVIEW™ event-based procedures to request the data packets cyclically.

Continuos Read Sync Base.vi

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Symbol Interface block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the low-level blocks Base Init, Get List of ReadWrite Symbols and Get List of Registered Targets are called to initialize the ADS client.
  3. To speed up reading and type resolving, the ADS Reader, with the call of Init Reader, and the TypeResolver, with the call of Init Type, are initialized in advance and only once in the next step.
  4. In the next step the Send Reader-Request block requests a new data packet from TwinCAT with each cycle of the loop. The received data packet is converted to a suitable LabVIEW™ data type "Variant" using the call Resolve From TC Type.
  5. Interaction: Variant-to-Data can be used to customize the example to translate the Variant to an appropriate data type. The data type depends on the ADS symbol selected in the Symbol Interface. See Type Resolving.
  6. When the termination condition for the loop is reached, the ADS reader is released from memory with the call Release Reader and the TypeResolver with the call Release Type.
  7. In the last step the Release basic block is called and thus the ADS client is released from memory.

Read Notification-Event Single

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Symbol Interface block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime. When selecting, note the parameter settings of the symbols for this operation mode: E-Noti. Single.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The ReadGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example, Index Array selects the first ADS symbol in the list.
  4. A User Event is created and registered. See also the LabVIEW™ documentation on user events.
  5. When E-Noti. Single is called, an ADS notification is registered on the ADS server for the selected ADS symbol.
  6. The next step is to wait for the ADS notifications in the event structure. If no notification is received, the event structure times out. Calling the block Stop Notification stops the ADS notification. The stop occurs at the ADS server so that no more messages are sent.
  7. Interaction: Type Resolving is not implemented in the example. Two options are available. The Resolving type is either realized within the event loop or after the ADS notification has been completed/unregistered. The following items in the event structure are relevant: Data and TimeStamps. The latter are the ADS timestamps.
  8. When the block Unregister Notification is called, the ADS notification of the symbol is unregistered at the ADS server and the handle to the ADS notification is released from memory.
  9. In the last step the Release basic block is called and thus the ADS client is released from memory.

Read Notification-Event Buffered.vi

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs. The example is identical in structure to Read Notification-Event Single. The only differences are:

  • The polymorphic VI is set to E-Noti. Buffered.
  • At the Data point in the event loop an array of size LVBufferSize is always passed.

Read Notification-Event Multiple

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs. The example is identical in structure to Read Notification-Event Buffered. The only differences are:

  • The polymorphic VI is set to E-Noti. Multiple Symbols.
  • For each ADS symbol a corresponding measurement duration ElapseTimeMs (in milliseconds) can be selected.
  • Reading from each ADS symbol requires corresponding LabVIEW™ event case.

Read Notification-LVBuffer Multiple

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Symbol Interface block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime. When selecting, observe the parameter settings of the symbols for the operation mode LVB-Noti. Multiple Symbols.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The ReadGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example, Array Subset selects the first 3 ADS symbols in the list.
  4. For each selected ADS symbol, a handle to the LVBuffer is initialized with the call to Init LVBuffer Handle.
  5. When LVB-Noti. Multiple Symbols is called, ADS notifications are registered on the ADS server for the selected ADS symbols. For this purpose the block takes an array of ADS symbols as input. In addition, the duration of the individual notification can be entered in milliseconds. Thus, the notifications are automatically stopped after the time expires.
  6. In the next step, the individual symbols are read in a while loop. Reading can be waited for a defined time (timeout) or infinitely long.
  7. When the block Unregister Notification is called, the ADS notification of the symbol is unregistered at the ADS server and the handle to the ADS notification is released from memory.
  8. When the block Release LVBuffer Handle is called, the handle to the LVBuffer is released from memory.
  9. In the last step the Release basic block is called and thus the ADS client is released from memory.

Read Notification-LVBuffer Single

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Symbol Interface block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime. When selecting, observe the parameter settings of the symbols for the operation mode LVB-Noti. Single Symbol.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The ReadGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example, Index Array selects the first ADS symbol in the list.
  4. A handle to the LVBuffer is initialized for the selected ADS symbol, with the call of Init LVBuffer Handle.
  5. When LVB-Noti. Single Symbol is called, ADS notifications are registered on the ADS server for the selected ADS symbol. In addition, the block allows to enter a measurement duration in milliseconds. Thus, the notifications are automatically stopped after the time expires.
  6. In the next step, the selected symbol can be read in a while loop. Reading can be waited for a defined time (timeout) or infinitely long. It is important to consider whether the ADS notifications are sent Cyclic or OnChange from the server.
  7. When the block Unregister Notification is called, the ADS notification of the symbol is unregistered at the ADS server and the handle to the ADS notification is released from memory.
  8. When the block Release LVBuffer Handle is called, the handle to the LVBuffer is released from memory.
  9. In the last step the Release basic block is called and thus the ADS client is released from memory.

Writing data continuously

Continuos Write Sync Base.vi

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Symbol Interface block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The WriteGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example, Index Array selects the first ADS symbol in the list.
  4. To speed up writing and type resolving, the ADS Writer, with the call of Init Writer, and the TypeResolver, with the call of Init Type, are initialized in advance and only once in the next step.
  5. In the next step the Send Writer-Request block sends a new data packet to TwinCAT with each cycle of the loop. Before writing, the LabVIEW™ data type Variant is converted to a suitable TwinCAT 3 data type by calling Resolve To TC Type block.
  6. After reaching the termination condition of the loop, the ADS reader is released from memory by calling Release Writer and the TypeResolver by calling Release Type.
  7. In the last step, the Release basic block is called and the ADS client is released from memory.

Generate LabVIEW™ type

To automatically generate a LabVIEW™ data type to an ADS symbol, the TypeResolver and the Generate Type wrapper block are used. The following examples describe two different ways to implement this:

Generate Type using Symbol Interface or Symbol's file

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Symbol Interface block is called. When the example is executed, the user interface opens and the user can select an ADS symbol in the TwinCAT runtime.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The ReadGrpSymbols and WriteGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1).
  4. In a For loop is executed:
    • TypeResolver: With Init Type the type description is loaded in the TypeResolver and passed to the LabVIEW™ process as XML string (TypeInfo).
    • TypeGenerator: Calling the Generate Type Wrapper VI generates a LabVIEW™ type.
    • Release-Type: Releases the handle to the TypeResolver from memory.
  5. Releases the handle to the client.

Generate Type using TypeInfo file

In contrast to Generate Type using Symbol Interface or Symbol’s file, the example uses a pre-generated TypeInfo file to generate a LabVIEW™ type.

SumUp Read or Write

Read SumUp with TypeResolving.vi

The example, like the other examples in Basic examples, uses the basic VIs from the LabVIEW™ VIs in the following steps:

  1. In the first step, the Symbol Interface basic block is called. When the example is executed, the user interface opens and the user can select an ADS symbol from his TwinCAT runtime.
    • If you have already exported an XML description of your ADS symbols from the Symbol Interface, you can also select the exported file in the Front Panel before starting the VI, so that the XML is loaded rather than calling the UI.
  2. In the second step, the Init basic block is called and the ADS client is initialized.
  3. The ReadGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example, Index Array selects the first and second ADS symbols of the list.
  4. After initialization of the ADS client, the TypeResolvers are initialized with the selected symbols.
  5. After that the SumUp handle is initialized for reading with the help of Init SumUp. Here the flag bAutosend is set to true so that new data is read automatically.
  6. The Add Request block assembles the SumUp sub-commands.
  7. After that, the example splits into two different threads:
    • Loop 1: Reads cyclically the new data one after the other from the sub-commands. The read data is converted to corresponding LabVIEW™ data types using the initialized TypeResolver.
    • Loop 2: Enables or disables the automatic sending of ADS requests.
  8. In the last step, all initialized handles are released from memory.

Notice

ADS error message when reading symbols with bAutosend set to false

ADS error messages may occur in Loop 1 if the flag bAutosend is set to false when initializing the SumUp handle. In this case, the block Get Data starts reading the data from the sub-commands even though they have not yet been sent to the ADS server and therefore do not contain any data.

Write SumUp with TypeResolving.vi

The example, like the other examples in Basic examples, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Symbol Interface block is called. When the example is executed, the user interface opens and the user can select an ADS symbol from his TwinCAT runtime.
    • If you have already exported an XML description of the ADS symbols from the Symbol Interface, you can select it as a path so that the XML is loaded rather than calling the UI.
  2. In the second step, the basic Init block is called and the ADS client is initialized.
  3. The WriteGrpSymbols output may contain more than one ADS symbol (if you selected more than one symbol in step 1). In the example two ADS symbols of the types timestamp and string are expected. With Index Array the first and the second ADS symbol of the list are selected.
  4. After initialization, the TypeResolvers are initialized to the selected symbols. Then it is checked whether the first symbol has the timestamp data type and the second has the string data type.
  5. After that the SumUp handle is initialized for writing with the help of Init SumUp. Here the flag bAutosend is set to false so that the new data is not written automatically.
  6. After that, the example splits into two different threads:
    • Loop 1: Waits in an event structure for new data generated by Loop 2. The new data is distributed to the appropriate sub-commands and waited to be sent. Before that the raw data is transformed into a TwinCAT 3 data type. If the sub-command already contains data, these are replaced by the new data. In the event structure, automatic sending can be enabled or disabled.
    • Loop 2: Generates the block diagram events in a cycle of 250 ms.
  7. In the last step, all initialized handles are released from memory.

CoE Read or Write

The example, like the other examples in this chapter, uses the basic VIs and the low-level VIs from LabVIEW™ VIs in the following steps:

  1. In the first step, the basic Init block is called up with an empty character string and the ADS client is initialized.
  2. The CoE blocks expect the AMS address as a string of the EtherCAT device from which the CoE configuration is to be read. The Device Address control element expects a character string with the following format: AMS Net-Id of the master and AMS Port of the device (AMS NetId:Port).

If the control element is left empty, the example opens a dialog box for selecting an EtherCAT device.

  1. The example reads the CoE list from the EtherCAT device.
  2. Interaction:
    • Double-click on an object in the CoE list to select it and read the object description. This calls up the low-level VI.
    • An entry with a subindex can be read using the Check Entry button.
    • In the next step, various CoE entries can be read or written.
  3. In the last step, the client handle is released from the memory.