4. EKI XML配置文件详解

EKI（Ethernet KRL Interface）的通信行为几乎全部由一份 XML 配置文件决定。机器人控制器在启动 EKI 或调用 EKI_Init 时读取该文件，据此建立套接字、解析报文、判断收发完成条件。因此，理解 XML 的结构层次，比记住某个标签的拼写更重要——它决定了“谁连谁、传什么、什么时候算传完、断了怎么办”。

从整体看，EKI 配置文件是一棵由根元素统领的树：根元素声明接口类型与全局属性，其下挂载若干通道（Channel），每个通道再细分连接参数、数据格式、超时与重连策略。下面这张结构图展示了各层级的从属关系与关键参数归属。

根元素与通道定义

根元素通常写作 <EKI>，其属性声明接口的全局行为。最常见的两个属性是 Type 与 Version：Type 取 Client 或 Server，决定机器人控制器是主动发起连接还是被动监听；Version 用于标识配置格式版本，便于控制器做兼容性判断。根元素下可以定义多个 <Channel>，每个通道代表一条独立的逻辑通信链路。例如机器人同时与视觉系统和 PLC 通信，就应配置两个通道，而不是把所有数据塞进一个通道——通道隔离能避免一条链路故障拖垮另一条。

通道元素一般带有 Name 属性，该名称会出现在 KRL 的 EKI_Init("ChannelName") 调用中，是程序与配置之间的绑定键。通道内部再按功能划分为若干子节点，下面逐一说明。

连接参数

连接参数决定“和谁连、从哪个门进出”。典型字段包括：

• IP：对端地址。客户端模式下填目标设备 IP；服务器模式下通常填 0.0.0.0 表示监听本机所有网卡。
• Port：端口号，需与对端严格一致，且避开控制器已占用的系统端口。
• Protocol：一般为 TCP；若对实时性要求不高且允许丢包，也可选 UDP，但 EKI 的多数应用仍以 TCP 为主。
• Role：部分实现中与根元素 Type 配合，明确本通道的主从角色。

一个容易出错的点是：客户端模式下若对端 IP 写错，控制器不会立即报错，而是在超时后才返回连接失败。因此配置完成后应先用 ping 确认网络可达，再启动 EKI。

数据格式与元素映射

数据格式节点定义报文如何被解析。EKI 支持 XML 与二进制两种模式。XML 模式下，配置中会列出收发报文的元素名与数据类型，例如：

<Data>
  <Element Name="X_Pos" Type="REAL" />
  <Element Name="Y_Pos" Type="REAL" />
  <Element Name="Status" Type="INT" />
</Data>

KRL 侧通过 EKI_GetReal("ChannelName", "X_Pos", x) 读取对应值。元素名必须与配置完全一致，大小写敏感；类型也必须匹配，把 REAL 写成 INT 会导致解析出的数值被截断或直接报错。二进制模式则需额外指定字节序与偏移量，适合高频、小报文场景，但调试难度更高，建议先用 XML 模式打通链路，再按需切换。

超时与重连策略

超时参数控制“等多久算失败”。常见字段有 Timeout（单次收发等待毫秒数）和 ConnectTimeout（建链等待时间）。超时设得太短，网络抖动就会误判失败；设得太长，故障时程序会长时间阻塞。工程上建议首次调试设为 3000～5000 ms，稳定后再根据实际节拍收紧。

重连策略决定断链后的行为。若配置 Reconnect 为 true 并给出 RetryInterval，控制器会在断链后按间隔自动重试。需要注意的是，重连期间 KRL 程序若正在执行 EKI_Get…，可能返回错误码而非阻塞等待，因此程序里必须对返回值做判断，不能假设每次调用都成功。

配置校验方法

XML 配置最容易犯的错误是标签未闭合、属性拼写错误或元素名与 KRL 不一致。推荐按以下顺序校验：

1. 语法校验：用任意 XML 解析器（如浏览器直接打开或 xmllint）检查文件是否 well-formed，能排除绝大多数括号与引号问题。
2. 结构校验：确认根元素、通道、连接参数、数据格式各层级的从属关系正确，没有把 <Data> 错放到通道外。
3. 一致性校验：逐项比对配置中的元素名、类型与 KRL 程序里的 EKI_Get/Set 调用，确保一一对应。
4. 联调校验：先只启动 EKI 并观察连接状态，再发一条固定测试报文，确认收发正常后再接入完整业务逻辑。

把这份配置当作通信契约来对待：根元素定规则，通道分链路，连接参数定对象，数据格式定语言，超时与重连定容错，校验定交付质量。六者齐备，EKI 通信才具备可复现、可排障的基础。