exOS API 数据模型 描述文件 由.typ数据类型定义文件生成，这些文件用于向数据连接两侧的数据集消息路由器提供信息。
每当exOS构建插件在<Build>部分中遇到<GenerateDatamodel>标记时，就会生成数据模型描述文件。与.exospkg文件中的大多数其他条目一样，如果需要解析的数据类型定义不止一个，则可以有多个<GenerateDatamodel>指令。
<GenerateDatamodel>指令定义了以下属性：
▪文件名：这是相对于exospkg文件定义数据结构的.typ文件的文件名。在上例中，.typ文件位于WaterTank文件夹中。
▪类型名：这是将要被解析的结构的根数据类型，在头文件生成器和 exOS 组件生成器 中使用这个根结构的名称来命名整个exOS软件包和许多其他对象。应避免使用"_typ"或"_t"之类的后缀。
它包含以下指令：
•<输出>：
头文件生成器可以向多个头文件创建输出。通常，至少有两个输出文件夹（一个用于AR，一个用于Linux），因此有两条<Output>指令
o路径：描述文件相对于exospkg文件的目标路径。描述文件的名称取自数据结构的根名称，该名称通过TypeName属性提供。在上面的例子中，描述文件的名称为exos_watertank.h和exos_watertank.c。
•<SG4>：
对于许多B&R程序员来说，#ifdef_SG4是C代码中一条众所周知的指令，用于标记特定于AR的代码。此条目设置了AR运行时选项。
o包含：对于描述文件，AR的一个特定选项是包含由AS生成的.typ文件的描述文件，而不是为Linux代码生成的类型定义。通过包含AR生成的头文件，可以将内部exos-api命令与IEC_GLOBAL和_LOCAL变量或库的.fun文件中定义的变量混合使用。在本示例中，动态库WaterTank也包含WaterTank.typ文件，因此将该头文件与#include<WaterTank.h>包含在一起不会与在.fun文件中定义的功能块接口中的WaterTank.typ数据类型冲突。
如果我们查看示例中的软件包，就会发现WaterTank库中的WaterTank.typ文件用于创建WaterTank和Linux目录中的exos_watertank.h和exos_watertank.c文件。
exOS构建插件使用{project}\Temp\Objects\{Configuration}\{ConfigHardware}\exos\exosPkg\GenerateDatamodel中的临时存储来检查最新构建的.typ文件是否有任何更改，并在.typ文件有更改时（或每次"全部重建"时）触发新的头文件生成。数据模型生成器的输出如下：
▪已更改.typ文件：
▪正在为'WaterTank'生成数据模型文件。
如果在exostarget中激活了冗长日志记录功能，即使.typ文件未变（描述文件未动），也会输出更多信息。
The exOS API datamodel description files are generated from .typ datatype definition files which are used to provide information to the Dataset Message Router on either side of the data connection.
This is done whenever the exOS build-plugin encounters a <GenerateDatamodel> tag within the <Build> section. As with most other entries in the .exospkg file, there can be several <GenerateDatamodel> instructions if more than one datatype definition needs to be parsed.
The <GenerateDatamodel> instruction defines the following attributes:
•FileName: This is the filename of the .typ file that defines the datastructure relative to the exospkg file. In the example above, the .typ file is located in the WaterTank folder.
•TypeName: This is the root datatype of the structure that is going to be parsed and the name of this root structure is used in the header generator and the exOS Component Generator for naming the complete exOS package along with a lot of other objects. Postfixes like '_typ' or '_t' or the like should be avoided.
It contains the following instructions:
•<Output>:
The header generator can create output to several header files. Normally, there are at least two output folders (one for AR, one for Linux), and thus two <Output> instructions
oPath: Path of the destination of the description file relative to the exospkg file. The name of the description files is taken from the root name of the datastructure which is provided via the TypeName attribute. In the example above, the description files would be called exos_watertank.h and exos_watertank.c.
•<SG4>:
For many B&R programmers, the #ifdef _SG4 is a well known instruction in C-code to mark code that is specific to Automation Runtime. This entry sets Automation Runtime options.
oInclude: For the description files, an AR specific option is to include the description files generated from the .typ file by Automation Studio instead of the typedef generated for Linux code. By including the AR generated header, it is possible to mix the internal exos-api commands with IEC _GLOBAL and _LOCAL variables, or with variables defined in the .fun file of a library. In the example, the dynamic library WaterTank also includes the WaterTank.typ file, and therefore including this header with #include <WaterTank.h> would not conflict with datatypes from the WaterTank.typ that are defined in the function block interface defined in the .fun file.
If we look at the package from the example, one can see that the WaterTank.typ file from the WaterTank library is used to create the exos_watertank.h and exos_watertank.c files in the WaterTank and Linux directories.
The exOS build-plugin uses a temporary storage in {project}\Temp\Objects\{Configuration}\{ConfigHardware}\exos\exosPkg\GenerateDatamodel to check if any changes have been made to the .typ files from the latest build and triggers a new header generation if the .typ file has changed (or at every "Rebuild All"). The output of the datamodel generator looks like the following:
•Changed .typ file:
•Generating datamodel file for 'WaterTank'..
If verbose logging is activated in the exostarget, additional information is output - even if the .typ file is unchanged (and the description files are untouched).