要求
某机器制造商销售的机器有 3 种不同的扩展等级--机器类型 A、B 和 C。但是，应该可以随时进行改装，并通过人机界面应用程序直接更改扩展级别。应用程序会适应相应的扩展级别。
在运行期间应能决定使用哪种机器类型。这意味着可以根据购买的机器类型设置相应的硬件配置。
机器制造商只需维护一个项目和一个硬件设置。
解决方案
基本思路
•一个配置项目，包含所有机器类型的所有硬件。
•通过 XML 文件导入相应的扩展级别。
•使用 SYS_Lib库调整应用程序 。
组件列表
•MpIOImport （自有 MpLink）：管理新硬件配置的导入。
•MpIOImportUI （来自 MpIOImport 的 MpLink）：包含与人机界面应用程序建立连接和导入硬件配置所需的所有参数和结构。
连接图
配置
配置中指定了 "备份设备名称"。配置的原始文件存储在目标系统配置中定义的数据存储设备上。有关配置的更多信息，请参阅 MpIO 配置。
使用 mapp 组件
添加功能块 MpIOImport 以管理硬件配置。
然后配置MpIOImport 。这需要 "FileDevice"、"FileName "以及 "ImportAllowed "和 "Import"。
添加并配置功能块 MpIOImportUI， 以便在运行时通过人机界面应用程序更改硬件配置。
根据所使用的机器类型，使用 SYS_Lib 库调整 应用程序。
为了能够通过 mapp IO 导入相应的硬件配置，需要在 AS 中添加不同机器类型所需的所有模块。更多信息，请参阅 此处。
需要注意的是，"ModuleSupervised（模块监控）"必须设置为 "关闭"！否则，如果指定插槽中没有硬件模块，控制器将以服务模式启动。
机器类型 A 的导入文件可以如下所示：
<IOCFG xmlns="http://www.br-automation.com/AR/IO" Version="2.0">
<Module ID="$root" Source="AR" SourceID="$root" />
<Module ID="IF6.ST1" Source="AR" SourceName="A_AnalogInputModule" >
<Parameter ID="Supervision" Value="on" />
<LN ID="AnalogInput01" DPName="Program:aiInput1" />
<LN ID="AnalogInput02" DPName="Program:aiInput2" />
</Module>
<Module ID="IF6.ST2" Source="AR" SourceName="A_DigitalOutputModule" >
<Parameter ID="Supervision" Value="on" />
<LN ID="DigitalOutput01" DPName="Program:doOutput1" />
<LN ID="DigitalOutput02" DPName="Program:doOutput2" />
</Module>
<Module ID="IF6.ST3" Source="AR" SourceName="A_SafeOutputModule" >
<Parameter ID="Supervision" Value="on" />
</Module>
<Module ID="IF6.ST4" Source="AR" SourceName="AB_DigitalInputModule" >
<Parameter ID="Supervision" Value="on" />
</Module>
</IOCFG>
有关导入文件结构的更多信息，请参阅 此处。
该导入文件被传输到控制器的数据存储设备 "HD "中：
使用 MpIOImport 导入该文件。导入完成后，由于 "ModuleSupervised（模块监控）"已通过导入文件重新启用，因此指定插槽上必须存在所有模块。例如，机器类型 A 的最终硬件配置可能如下所示：
Requirement
A machine manufacturer sells a machine with 3 different expansion levels – machine types A, B and C. When buying, the customer decides which variant he needs. However, it should be possible to retrofit at any time and to change the expansion level directly via the HMI application. The application adapts to the respective expansion level.
It should be possible to decide during runtime which machine type should be used. This means that depending on which machine was purchased, the corresponding hardware configuration can be set.
The machine builder only wants to maintain one project with one hardware setup.
Solution
Basic idea
•A project with a configuration that contains all the hardware for all machine types.
•Import of respective expansion level via XML file.
•Adjustment of the application using library SYS_Lib.
Component list
•MpIOImport (own MpLink): Manages the import of the new hardware configuration.
•MpIOImportUI (MpLink from MpIOImport): Contains all necessary parameters and structures for establishing a connection to an HMI application and importing a hardware configuration.
Connection diagram
Configuration
A "backup device name" is specified in the configuration. The original files of the configuration are stored on this data storage device, which is defined in the configuration of the target system. For more information about configuration, see MpIO configuration.
Using the mapp components
Function block MpIOImport is added to manage the hardware configuration.
MpIOImport is then configured. This requires "FileDevice", "FileName" as well as "ImportAllowed" and "Import".
Function block MpIOImportUI is added and configured to change the hardware configuration at runtime via the HMI application.
The application is adapted using the SYS_Lib library depending on the machine type used.
In order to be able to import the respective hardware configuration with mapp IO, all modules required for the different machine types are added in Automation Studio. For more information, see here.
It is important to note that "ModuleSupervised" must be set to "off"! Otherwise, the controller starts in service mode if the hardware modules are not present in the specified slots.
The import file for machine type A could look like this:
<IOCFG xmlns="http://www.br-automation.com/AR/IO" Version="2.0">
<Module ID="$root" Source="AR" SourceID="$root" />
<Module ID="IF6.ST1" Source="AR" SourceName="A_AnalogInputModule" >
<Parameter ID="Supervision" Value="on" />
<LN ID="AnalogInput01" DPName="Program:aiInput1" />
<LN ID="AnalogInput02" DPName="Program:aiInput2" />
</Module>
<Module ID="IF6.ST2" Source="AR" SourceName="A_DigitalOutputModule" >
<Parameter ID="Supervision" Value="on" />
<LN ID="DigitalOutput01" DPName="Program:doOutput1" />
<LN ID="DigitalOutput02" DPName="Program:doOutput2" />
</Module>
<Module ID="IF6.ST3" Source="AR" SourceName="A_SafeOutputModule" >
<Parameter ID="Supervision" Value="on" />
</Module>
<Module ID="IF6.ST4" Source="AR" SourceName="AB_DigitalInputModule" >
<Parameter ID="Supervision" Value="on" />
</Module>
</IOCFG>
For more information about the structure of an import file, see here.
This import file is transferred to the controller in data storage device "HD":
This file is imported using MpIOImport. As soon as the import is completed, all modules must be present on the specified slots since "ModuleSupervised" is re-enabled using the import file. For example, the final hardware configuration for machine type A could look like this: