Using Device Applications¶

Using a device application allows for the separation of globally required data from exclusively control programs:

The global data that is used by all control applications of a device are managed in their own Device application object. They are compiled fully with this object and downloaded to the controller at the time of commissioning. The Device application does not include control programs developed by the user. Because of this, the exclusively control applications of the device are smaller and require less time to download. Reason: The global data does not have to be included at every download or online change. However, loading the global data requires more memory and download time as when using exclusively single applications. Reason: ALL referenced data and the entire code are downloaded to the controller with the device application because it is not clear what is used later or not.

Therefore, using a device application instead of single applications makes sense when

the device in use has enough memory (for example not an embedded system),
and if the control tasks should be distributed to multiple applications for improved logical mapping.

Organization in the device tree:

Depending on the device, you can insert the Device application object in the device tree below the PLC logic node of the device. By using different types of child objects, this manages the global data and code segments that are used by all exclusively control applications of the device. Examples: library manager, GVLs, network variable list. The PLC logic node is hidden after the device application is inserted into the device tree.
The exclusively control program code is contained in one or more ordinary application objects that are displayed in the tree in parallel to the Device application. In the hierarchy however, they are ranked below the Device application and can access the global data and variables of the device application. They do not have mutual access to each other and also cannot have any child applications. However, data exchange is possible via the global data of the device application.

Control and behavior:

An online change is not possible for the device application. Therefore, changes to the device application lead to a new download of the device application and the child applications (in the device tree on the same level).
After a download or reset (warm or cold), the device application is then in status “Stop”. You can login, logout, start, stop, and reset all applications of the device application, individually or collectively, via corresponding context menu commands.
At the first login and download of an application, the device application is also downloaded automatically.
When commissioning the device, you can use the online configuration mode for testing the I/Os. When commissioning is complete, you must then perform a new download for the applications and the device application.
If you delete the device application from the device, then its child applications are also deleted from the device.
When generating a boot application for an application of the device, a boot application is also generated automatically for the device application.
By default, each application has the property that the device application stops, as well as all other applications, in case of an exception.
Notes about task configuration:

POUs cannot be called in the task configuration of the device application. This task configuration is used by bus masters in the field in order to reach an approximation of the timing of the bus cycle task when the program is executed. Depending on the device, there are two possibilities:
- You define a task of type “External” in the task configuration of an application. As an external event for triggering the task, you specify the call of the implicitly provided bus master event. This allows for reaching an asynchronous timing compensation with the bus master.
- You define a task of type “Parent task” in the task configuration of an application. For the parent task, you select the cyclic tasks of the bus master from the provided tasks of the device application. This allows for reaching a synchronous timing compensation with the bus master.
  
  Please note the following restriction: Whether or not synchronous calling is executed depends on the state of the device application only. If this is running and the child application is not running, then the code is called anyway.
Notes about persistent variables:

If the device supports static memory areas for persistent and retain variables, then you can use the Persistent variable configuration object to map the memory also into global and application-specific for remanent data. This makes sense so you do not have to download the device application and all applications to the controller again after a persistent variable list is modified. By default, for devices with static memory management, the entire memory is reserved in the device application for remanent data. However, as soon as you create a persistent variable list in an application, you must also provide a memory area for it there. Even an empty list requires at least a few bytes of memory. For devices without static memory allocation, an individual memory segment is allocated automatically for persistent data for each application.
Note for symbol configuration:
- A Symbol configuration as a child application of a Device application is not supported.
- You can also apply the references to the symbol configuration libraries of an application in the library manager of the device application. The advantage of this is that the libraries do not have to be downloaded with the application, and therefore the applications are smaller. Refer to the option Add library placeholder to device application when adding a Symbol configuration object, or the command with the same name in the Tools menu of the symbol configuration.