ADS Sum Command合并的是请求，不必把变量排成连续内存

控制器中几个变量不在连续内存区域，读取它们是否就必须始终对应几次独立调用？Beckhoff的ISumCommand接口说明给出了另一种组织方式：ADS Sum Command可以在一次ADS调用中读取多个没有组成连续线性内存区域的变量。被组合的是请求，变量原有布局并没有因此被描述为自动改变。[1]

文档先提到单个变量，以及完整数组和结构可以各用一次ADS调用读取，随后才引出Sum Command对分散变量的组合。两种文字放在一起，能够看出它并非只给一块现成连续数组换名称。请求容器提供了一种通信组织形式，内存中的对象是否连续则是另外一层关系。

这种组合也保留了子请求身份。接口属性表将Result说明为主SumCommand请求的AdsErrorCode，把SubResults说明为各个子请求的结果。一个组合请求中仍有可以分别描述的成员结果，而不是所有变量从此只剩下一个无法区分的数值。本文解释属性含义，没有读取真实控制器状态或处理现场错误。

可以用一个仅为说明概念的例子理解：把数项查询放入同一个容器，并不使查询对象变成同一件东西；容器有自己的结果，各项查询仍有各自结果。这个比喻不是实际数据包结构图，也没有给出构造请求的代码或缓冲区安排。所读接口页已经区分主结果和子结果，文章保留这种组织关系即可。

原文的限制节同时说明目标设备需要支持相关命令，并讨论组合请求与数据体量的限制。这些上下文提醒读者，产品说明中的“一次调用”不是对所有设备、任意规模的无条件承诺。本文不采用具体数量或耗时，也不把组合读取自动解释成所有变量在完全同一时刻形成的现场快照。

页面标为TwinCAT 3、ADS.NET V4，接口版本为4.3.0.0；这些是本篇解释所对应的文档身份，不是本文验证过的软件兼容组合。首次发布日期未知，页脚年份未作首发日期。对控制器通信资料，新增的具体认识在于分散变量可以通过组合请求被访问，而主请求与子请求结果仍各有身份；它不构成控制代码、轮询设置或生产安全建议。