简介这份资源是Sankyo Robot SP6500工业机器人的官方说明书面向玻璃搬送产线的设备调试、维护工程师及自动化集成人员用于解决SP6500控制系统配置、程序规格与信号分配等实操问题。包内共1个PDF文件约5.2MB内容涵盖硬件构成例、Command处理Program Flow、标准I/O信号分配、CC-Link分配一览表以及从6000.00.x.A到6500.01.x.A各版本的改订履历并附有基板纵横指定、在荷确认仕样变更等条目。读者可据此掌握CC-Link卡版本设定、Hand Position Sensor检测、Glass碎裂检测与吸着确认等功能的实现方式对照I/O端口分配表完成接线与调试并借助版本记录追溯功能演进、定位兼容性问题。目前已有10496人学习下载适合需要系统查阅SP6500规格与排错依据的中高级技术人员。1. 玻璃搬送机器人的控制契约为什么一份规格书比代码更值得读一台玻璃搬送机器人出故障现场工程师最先翻的往往不是程序源码而是那份几百页的规格书。原因很反直觉这类设备的程序本身并不复杂真正复杂的是机器人控制器与上位 PLC 之间那份隐式的控制契约——哪个信号代表命令、哪个寄存器存位置号、握手超时算谁的错。Sankyo SP6500 的这份搬送 Application Program 规格书本质上就是把这份契约逐条写死从 CC-LINK 的 IO 分配、Data Register 的偏移到 0x01 到 0x37 的异常码表全部落到可核对的编号上。搞懂它你就明白为什么工业机器人能 work靠的不是算法多聪明而是状态机、握手时序和异常分类被设计得足够死板。这也是理解 sankyo robot SP6500 这类设备底层机制最直接的入口。2. CC-LINK 通信层为什么 IO 分配表决定了整套程序的骨架2.1 从站内存映射输入输出为什么按块而不是按信号排规格书第 4 章把 CC-LINK 的 IO 分配拆成输入PLC→SC5000和输出SC5000→PLC两个方向每个方向又按 User 区域切成十几段4.1.1 到 4.1.14。这种切法不是随手分的而是跟着 CC-LINK 从站的远程 IO 寄存器RX/RY和远程寄存器RWr/RWw的物理排布走的。控制器作为从站PLC 作为主站双方看到的是一块连续地址空间规格书要做的就是把第几个 bit 是哪个信号钉死。常见的实现思路是远程 IO 的 bit 区放布尔型握手信号启动、停止、命令码有效位远程寄存器区放数值型数据位置号、地址码、Work Type。这样 PLC 侧扫描一个 bit 就能判断命令是否到达不需要解析报文。代价是地址一旦定死扩展就得往后加段——这也是为什么规格书里 4.1 的分配表从 4.1.1 一路排到 4.1.14版本迭代时新增功能只能往后面的段塞。提示读这类分配表时先确认自己手上 PLC 的 CC-LINK 主站参数占用站数、扩展 Cyclic 设定否则地址会整体错位。规格书 6500.00 版明确写了CC-LINK 设定变更 Version2.0 扩展 Cyclic 2 倍这一条直接改变了寄存器数量老程序照搬会翻车。2.2 Data Register 的偏移位置号为什么不能直接当地址用第 5.9 节专门讲 Register 的 Offset5.10 节讲 Access 位置显示。这两节放在一起看才有意义PLC 写进 Data Register 的不是绝对坐标而是一个位置号 偏移的组合。控制器收到后先查 Teaching Data 表第 8 章把位置号翻译成实际的 X/Y/Z/R 轴目标值再叠加偏移量。为什么这么设计因为玻璃搬送的对位基准会随产线、卡匣、工装变化如果 PLC 直接下发绝对坐标任何一次机械调整都要改 PLC 程序。用位置号 偏移把几何数据锁在控制器侧的 Teaching Data 里PLC 只负责说去 3 号位偏 2mm机械变更只动示教数据。这是典型的关注点分离也是这类搬送程序能跨产线复用的关键。PLC 侧写入示意: RWw[0] Command Code // 动作命令码 RWw[1] Position No // 示教位置号 RWw[2] Offset // 偏移量单位由参数定 RY[0] Command Valid // 命令有效握手位 控制器侧解析示意逻辑: if RY[0] and RWw[0] in valid_cmd_set: target teaching_data[RWw[1]] offset_table[RWw[2]] state_machine.dispatch(RWw[0], target)上面这段是机制示意不是源码。关键点在最后一行命令码不是直接调用某个动作函数而是进状态机分发。规格书第 6.1 节的 Command Motion 一览表就是这个 dispatch 表的文字版第 7 章的状态迁移图则是状态机的合法跳转约束。两者必须对齐否则会出现命令收到了但状态不允许执行的 0x1F 命令一致信号超时。2.3 握手时序Finish ACK 超时为什么是 0x10第 6.2 节 Timing Chart 和第 10 章的 0x10 异常码Command 完了 ACK 信号输入 Over Time是一对。控制器执行完一条命令后置完成位等 PLC 回 ACKPLC 不回超时即报 0x10。这个设计的动机很实际搬送动作有物理耗时PLC 和控制器是异步的没有 ACK 就无法确认这条命令的副作用已经被上位消化下一条命令贸然下发会导致位置错乱。我一般会这么理解这套握手命令有效位是请求完成位是响应ACK 是响应已确认。三段式握手比两段式多一个往返但换来的是命令队列不会因为单边超时静默丢步。现场排查 0x10 时先看 PLC 扫描周期是否长于控制器动作时间再看 ACK 位是否被别的逻辑覆盖——这两个是最常见的根因。3. 动作命令与状态机一条搬送命令到底经历了什么3.1 Command Motion 一览表背后的分层粗动作与细动作第 6.1 节的命令一览表乍看是一堆并列的动作码但按 6.15 节 Motion 详细说明展开后会发现它们分两层一层是取/放/待机/原点复位这类粗粒度搬送动作另一层是Line Sensor 感应Access 位置在荷确认非接触 Alignment这类细粒度感知动作。粗动作负责把手臂送到位细动作负责确认到位是否真的成立。这种分层不是审美选择而是异常处理的需要。粗动作失败通常意味着机械或安全链问题急停、干涉区域细动作失败则多是工件状态问题无片、双片、偏移超限。规格书第 10 章的异常码正好按这个分0x04 到 0x0F 是 R1/R2 吸着与在荷检测类0x11 到 0x1E 是 Alignment 与 Shift 类0x20 到 0x2E 是参数与补偿量类。异常码的编号段位其实就是动作分层的镜像。3.2 OVERLAP 动作为什么允许两条命令在时间上重叠第 6.5、6.6 节专门讲 OVERLAP 动作及其 Timing Chart。允许重叠的动机是节拍玻璃搬送里取和放之间有一段纯运输时间如果严格串行机械臂在等 PLC 确认时是空转的。OVERLAP 让控制器在完成当前动作的收尾阶段就预取下一动作的参数把握手延迟藏进机械运动时间里。但重叠是有代价的状态机必须保证重叠的两条命令在资源上不冲突同一 Hand、同一轴、同一吸着回路不能同时被两条命令占用。规格书 6.10 节两 Hand 指定动作特别注明仅对 Double Hand Robot 无动作限制的 Robot 有效就是在划这条边界。实现上常见的做法是给每个资源加占用标记dispatch 前做冲突检查冲突则退化为串行——这也是为什么 0x2A上下 Hand 的轴分配异常会单独存在一个异常码。资源冲突检查示意: resources {hand_r1, hand_r2, axis_z, vacuum_r1, vacuum_r2} for r in cmd.required_resources: if r.locked_by ! None and r.locked_by ! cmd.id: return SERIALIZE # 退化为串行不报错 lock(cmd.required_resources, cmd.id)注意这里选择退化而不是报错重叠是优化不是语义冲突时串行执行结果仍然正确只是慢一点。这个取舍在实时系统里很常见——优化路径失败要能安全回落到正确路径。3.3 原点复位与中间待机急停之后为什么不能直接继续第 6.7 到 6.9 节讲急停后的原点复位、存在中间待机动作时的复位与吸着 Retry、以及 Z/R 轴原点复位的可能范围。这三节合起来回答一个现场高频问题急停后为什么不能简单清报警继续跑因为急停发生时机械臂可能停在任意位置吸着回路可能还带着一片玻璃Z 轴可能在行程中间。直接继续会让状态机的当前位置假设失效。规格书的做法是强制走原点复位流程且复位本身有范围约束6.9 节超出范围要先手动干预。吸着 Retry6.8 节则是针对复位后工件还在手上的情况先确认吸着状态再决定是放回还是继续搬。注意原点复位不是回零这么简单它是一次带状态校验的重新初始化。现场如果跳过复位直接发命令最常见的现象是位置偏差累积几片之后开始报 0x1D/0x1E 的 Glass Shift 异常。4. 感知与对位碎裂检测、在荷确认、非接触 Alignment 怎么协同4.1 碎裂检测与在荷检测为什么被拆成两个独立功能版本履历里有一条很关键6000.03.x.A Glass 碎裂检测功能、在荷检测独立功能追加随后 6000.031.x.A 又追加了碎裂检测功能用 Error。这说明早期这两个功能是耦合的后来被拆开。拆开的动机是误判率碎裂检测看的是玻璃完整性可能用边缘或应力传感在荷检测看的是手上有没有东西吸着压力/流量。两者物理量不同耦合在一起时一片正常但吸着略弱的玻璃会被误报成碎裂。拆开之后异常码也分开了0x04/0x0A 是吸着异常V/S err0x05/0x0B 是在荷检测异常碎裂相关则走独立的检测路径。这种一个物理现象一个传感器、一个传感器一个异常码的拆分原则是这类设备可维护性的基础——现场看异常码就能定位到具体传感器不用猜。4.2 吸着确认无效 Parameter为什么允许关掉确认第 6.13 节讲吸着确认无效 Parameter版本履历 6000.01.x.A 追加。允许关掉吸着确认听起来危险但有明确场景某些薄玻璃或特殊工装下吸着压力传感器的读数波动大强制确认会导致频繁误报停机。参数化关闭确认等于把是否信任这个传感器的决定权交给工艺工程师。常见的实现思路是确认逻辑本身保留只是用一个开关短路掉判定结果同时仍然记录传感器原始值供诊断。这样关掉确认不等于关掉观测出问题时还能回溯。这个设计取舍值得记住——安全相关的检查可以放宽但观测不能丢。4.3 非接触 Alignment 的四种 Sensing 路径第 8.3 节把非接触 Alignment 按用哪个传感器、感哪个方向分成四类Hand 部 Alignment Sensor 做 R 轴方向、固定式 Sensor 做 X 轴方向、Hand 部 Sensor 做 X 轴方向、Line Sensor 做 X 轴方向。第 9 章又给了两条执行 Flow。这种多路径并存不是冗余而是适配不同世代的机械结构和不同尺寸的基板。以 Line Sensor 的 X 轴 Sensing 为例6.11 节它又细分为通过信号指定和通过 Command 指定两种触发方式6.11.1两者的差别在于谁来控制感应的起止时机信号方式由 PLC 实时控制适合与外部输送同步Command 方式由控制器内部时序控制适合固定节拍。选错方式不会报错但会出现感应窗口和玻璃实际位置错位表现为 Alignment 补偿量异常0x2C/0x2D/0x2E。Line Sensor X 轴 Sensing机制示意: 信号方式: PLC 置 Sensing Start - 控制器按当前速度扫过 - 置 Sensing Done Command方式: 控制器收到 Command - 内部按参数化速度/窗口扫描 - 置 Done 差异点: 扫描窗口的起止由谁决定 失败表现: 补偿量超限 - 0x2C(θ) / 0x2D(Y) / 0x2E(X)4.4 基板纵横指定与 Shift Sensor 双个对应6500.01.x.A 追加了基板纵横指定功能且在荷确认仕样变更和Shift Sensor 2 个对应。纵横指定意味着同一套程序要处理横放和竖放两种基板姿态Teaching Data 里必须能区分Shift Sensor 从 1 个变 2 个则是为了同时检测两个方向的偏移而不是靠单传感器加假设推算。这两条改动都指向同一个趋势基板越大、对位要求越高单点感知越不够用必须多点冗余。5. 异常码体系0x01 到 0x37 为什么这样分段5.1 异常码的分段逻辑与现场定位路径第 10 章的异常码表从 0x01 排到 0x37中间还有若干未使用占位。分段规律大致是0x01-0x03 参数类0x04-0x0F R1/R2 吸着与在荷类0x10-0x1F 握手与 Alignment 类0x20-0x2E 命令参数与补偿量类0x30-0x37 Mapping 与 Torque/Thermal 类。保留未使用占位是为了版本兼容——新增异常码插进预留段不打乱已有编号PLC 侧的异常处理逻辑不用改。现场定位路径因此很清晰先看异常码落在哪个段段位决定查哪一章。0x04 段查吸着回路和真空传感器0x11 段查 Alignment Sensor 的 ON/OFF 时序0x20 段查 PLC 下发的命令参数是否越界。这种编号即索引的设计比一堆无编号的错误字符串好用得多。5.2 参数类异常为什么占大头数一下会发现0x20 到 0x2E 几乎全是指定的 XX 值不合适。这不是巧合控制器和 PLC 之间靠编号传参任何一方版本不一致、配置错位都会表现为参数越界。规格书把这些情况逐一给码等于把配置错误从运行时崩溃里分离出来。血泪经验是现场大部分所谓机器人抽风追到底都是 PLC 侧某个寄存器写错了位置号或 Work Type。5.3 Torque 与 Thermal 异常机械健康的最后一道观测0x36 Torque 值异常、0x37 Thermal 值异常是 6500.00 版追加的。这两个不是搬送逻辑的一部分而是机械健康的旁路观测扭矩超限可能意味着卡阻或碰撞温度超限可能意味着连续高负载。把它们做成异常码而不是 Warning说明设计上认为这两类情况必须停机处理不能带病运行。6. 避坑与排查现场最容易翻车的五个点6.1 现象换版后所有位置整体偏移 → 原因CC-LINK 扩展 Cyclic 设定未同步 → 解决核对主站占用站数与扩展设定6500.00 版把 CC-LINK 设定变更到 Version2.0、扩展 Cyclic 2 倍寄存器数量翻倍。如果 PLC 主站参数还按老版本配地址映射整体错位表现就是所有位置号解析出错误坐标。排查时先比对双方版本号和占用站数再看 Data Register 的实际读写地址是否落在规格书 4.2 节给的范围内。6.2 现象偶发 0x10 完成 ACK 超时 → 原因PLC 扫描周期抖动或 ACK 位被覆盖 → 解决查扫描周期与 ACK 位写逻辑0x10 的根因几乎总在 PLC 侧。先测 PLC 最大扫描周期是否接近控制器动作时间再看 ACK 位是否被同一程序里别的分支重复写。常见翻车是 ACK 位用了自复位逻辑控制器还没读到就被清掉了。6.3 现象碎裂检测频繁误报 → 原因碎裂与在荷检测未按新版拆分 → 解决确认程序版本 ≥6000.03 并检查传感器独立配置6000.03 之前碎裂和在荷是耦合的薄玻璃吸着略弱就误报。确认控制器程序版本并按 6.13 节检查吸着确认无效 Parameter 是否被误开——误开会让在荷判定失效反而放大误报。6.4 现象Alignment 补偿量报 0x2C/0x2D/0x2E → 原因Sensing 触发方式与输送节拍不匹配 → 解决核对信号方式与 Command 方式的选用信号方式适合与外部输送同步Command 方式适合固定节拍。用错方式时感应窗口和玻璃实际位置错位补偿量算出来超限。按 6.11.1 节确认当前用的是哪种触发再对照 8.3 节确认传感器路径选对。6.5 现象急停复位后连续几片位置偏差 → 原因跳过原点复位或复位范围超限未处理 → 解决强制走 6.7-6.9 节复位流程并检查 Z/R 轴范围急停后直接清报警继续状态机的当前位置假设是错的偏差会累积。按 6.9 节确认 Z/R 轴在可复位范围内超出范围先手动干预再走完整复位和吸着 Retry。7. 设计取舍为什么这套程序宁可死板也不聪明读完这份规格书最值得琢磨的不是某个功能怎么实现而是整套设计反复做的同一个取舍宁可把契约写死、把异常码排满、把状态迁移约束到死板也不让控制器聪明地猜。CC-LINK 的 IO 分配按块定死位置号必须查表翻译握手必须三段确认重叠动作冲突时退化串行而不是动态调度——每一条都在牺牲灵活性换可预测性。这不是技术保守而是场景决定的。玻璃搬送面对的是高价值工件、连续产线、多人维护一次静默的错误比十次明确的停机代价大得多。异常码从 0x01 排到 0x37、还预留未使用段本质是把可能出错的方式提前枚举完让现场任何一次停机都能对应到一个确定的编号和一条确定的排查路径。这种设计哲学和互联网系统追求的自愈、弹性几乎相反但在工业现场它是正确的可观测、可复现、可交接比聪明重要。验证这套设计是否被正确实现我一般会做三件事一是拿异常码表逐条对照程序里的判定分支看有没有码没实现或实现了没码二是用 Timing Chart 反推握手时序在 PLC 侧打点确认每个沿的先后三是故意制造参数越界比如写一个不存在的 Position No确认报的是 0x20 而不是别的码。这三步走完基本能确认程序和规格书是同一套契约。从那以后我每次接手这类搬送程序都强制先把 IO 分配表和异常码表打印出来贴在工位上改任何一行逻辑前先在上面找到对应的编号。希望帮到你。本文还有配套的精品资源点击获取 工业机器人控制契约：CC-LINK IO分配与异常码体系解析
简介这份资源是Sankyo Robot SP6500工业机器人的官方说明书面向玻璃搬送产线的设备调试、维护工程师及自动化集成人员用于解决SP6500控制系统配置、程序规格与信号分配等实操问题。包内共1个PDF文件约5.2MB内容涵盖硬件构成例、Command处理Program Flow、标准I/O信号分配、CC-Link分配一览表以及从6000.00.x.A到6500.01.x.A各版本的改订履历并附有基板纵横指定、在荷确认仕样变更等条目。读者可据此掌握CC-Link卡版本设定、Hand Position Sensor检测、Glass碎裂检测与吸着确认等功能的实现方式对照I/O端口分配表完成接线与调试并借助版本记录追溯功能演进、定位兼容性问题。目前已有10496人学习下载适合需要系统查阅SP6500规格与排错依据的中高级技术人员。1. 玻璃搬送机器人的控制契约为什么一份规格书比代码更值得读一台玻璃搬送机器人出故障现场工程师最先翻的往往不是程序源码而是那份几百页的规格书。原因很反直觉这类设备的程序本身并不复杂真正复杂的是机器人控制器与上位 PLC 之间那份隐式的控制契约——哪个信号代表命令、哪个寄存器存位置号、握手超时算谁的错。Sankyo SP6500 的这份搬送 Application Program 规格书本质上就是把这份契约逐条写死从 CC-LINK 的 IO 分配、Data Register 的偏移到 0x01 到 0x37 的异常码表全部落到可核对的编号上。搞懂它你就明白为什么工业机器人能 work靠的不是算法多聪明而是状态机、握手时序和异常分类被设计得足够死板。这也是理解 sankyo robot SP6500 这类设备底层机制最直接的入口。2. CC-LINK 通信层为什么 IO 分配表决定了整套程序的骨架2.1 从站内存映射输入输出为什么按块而不是按信号排规格书第 4 章把 CC-LINK 的 IO 分配拆成输入PLC→SC5000和输出SC5000→PLC两个方向每个方向又按 User 区域切成十几段4.1.1 到 4.1.14。这种切法不是随手分的而是跟着 CC-LINK 从站的远程 IO 寄存器RX/RY和远程寄存器RWr/RWw的物理排布走的。控制器作为从站PLC 作为主站双方看到的是一块连续地址空间规格书要做的就是把第几个 bit 是哪个信号钉死。常见的实现思路是远程 IO 的 bit 区放布尔型握手信号启动、停止、命令码有效位远程寄存器区放数值型数据位置号、地址码、Work Type。这样 PLC 侧扫描一个 bit 就能判断命令是否到达不需要解析报文。代价是地址一旦定死扩展就得往后加段——这也是为什么规格书里 4.1 的分配表从 4.1.1 一路排到 4.1.14版本迭代时新增功能只能往后面的段塞。提示读这类分配表时先确认自己手上 PLC 的 CC-LINK 主站参数占用站数、扩展 Cyclic 设定否则地址会整体错位。规格书 6500.00 版明确写了CC-LINK 设定变更 Version2.0 扩展 Cyclic 2 倍这一条直接改变了寄存器数量老程序照搬会翻车。2.2 Data Register 的偏移位置号为什么不能直接当地址用第 5.9 节专门讲 Register 的 Offset5.10 节讲 Access 位置显示。这两节放在一起看才有意义PLC 写进 Data Register 的不是绝对坐标而是一个位置号 偏移的组合。控制器收到后先查 Teaching Data 表第 8 章把位置号翻译成实际的 X/Y/Z/R 轴目标值再叠加偏移量。为什么这么设计因为玻璃搬送的对位基准会随产线、卡匣、工装变化如果 PLC 直接下发绝对坐标任何一次机械调整都要改 PLC 程序。用位置号 偏移把几何数据锁在控制器侧的 Teaching Data 里PLC 只负责说去 3 号位偏 2mm机械变更只动示教数据。这是典型的关注点分离也是这类搬送程序能跨产线复用的关键。PLC 侧写入示意: RWw[0] Command Code // 动作命令码 RWw[1] Position No // 示教位置号 RWw[2] Offset // 偏移量单位由参数定 RY[0] Command Valid // 命令有效握手位 控制器侧解析示意逻辑: if RY[0] and RWw[0] in valid_cmd_set: target teaching_data[RWw[1]] offset_table[RWw[2]] state_machine.dispatch(RWw[0], target)上面这段是机制示意不是源码。关键点在最后一行命令码不是直接调用某个动作函数而是进状态机分发。规格书第 6.1 节的 Command Motion 一览表就是这个 dispatch 表的文字版第 7 章的状态迁移图则是状态机的合法跳转约束。两者必须对齐否则会出现命令收到了但状态不允许执行的 0x1F 命令一致信号超时。2.3 握手时序Finish ACK 超时为什么是 0x10第 6.2 节 Timing Chart 和第 10 章的 0x10 异常码Command 完了 ACK 信号输入 Over Time是一对。控制器执行完一条命令后置完成位等 PLC 回 ACKPLC 不回超时即报 0x10。这个设计的动机很实际搬送动作有物理耗时PLC 和控制器是异步的没有 ACK 就无法确认这条命令的副作用已经被上位消化下一条命令贸然下发会导致位置错乱。我一般会这么理解这套握手命令有效位是请求完成位是响应ACK 是响应已确认。三段式握手比两段式多一个往返但换来的是命令队列不会因为单边超时静默丢步。现场排查 0x10 时先看 PLC 扫描周期是否长于控制器动作时间再看 ACK 位是否被别的逻辑覆盖——这两个是最常见的根因。3. 动作命令与状态机一条搬送命令到底经历了什么3.1 Command Motion 一览表背后的分层粗动作与细动作第 6.1 节的命令一览表乍看是一堆并列的动作码但按 6.15 节 Motion 详细说明展开后会发现它们分两层一层是取/放/待机/原点复位这类粗粒度搬送动作另一层是Line Sensor 感应Access 位置在荷确认非接触 Alignment这类细粒度感知动作。粗动作负责把手臂送到位细动作负责确认到位是否真的成立。这种分层不是审美选择而是异常处理的需要。粗动作失败通常意味着机械或安全链问题急停、干涉区域细动作失败则多是工件状态问题无片、双片、偏移超限。规格书第 10 章的异常码正好按这个分0x04 到 0x0F 是 R1/R2 吸着与在荷检测类0x11 到 0x1E 是 Alignment 与 Shift 类0x20 到 0x2E 是参数与补偿量类。异常码的编号段位其实就是动作分层的镜像。3.2 OVERLAP 动作为什么允许两条命令在时间上重叠第 6.5、6.6 节专门讲 OVERLAP 动作及其 Timing Chart。允许重叠的动机是节拍玻璃搬送里取和放之间有一段纯运输时间如果严格串行机械臂在等 PLC 确认时是空转的。OVERLAP 让控制器在完成当前动作的收尾阶段就预取下一动作的参数把握手延迟藏进机械运动时间里。但重叠是有代价的状态机必须保证重叠的两条命令在资源上不冲突同一 Hand、同一轴、同一吸着回路不能同时被两条命令占用。规格书 6.10 节两 Hand 指定动作特别注明仅对 Double Hand Robot 无动作限制的 Robot 有效就是在划这条边界。实现上常见的做法是给每个资源加占用标记dispatch 前做冲突检查冲突则退化为串行——这也是为什么 0x2A上下 Hand 的轴分配异常会单独存在一个异常码。资源冲突检查示意: resources {hand_r1, hand_r2, axis_z, vacuum_r1, vacuum_r2} for r in cmd.required_resources: if r.locked_by ! None and r.locked_by ! cmd.id: return SERIALIZE # 退化为串行不报错 lock(cmd.required_resources, cmd.id)注意这里选择退化而不是报错重叠是优化不是语义冲突时串行执行结果仍然正确只是慢一点。这个取舍在实时系统里很常见——优化路径失败要能安全回落到正确路径。3.3 原点复位与中间待机急停之后为什么不能直接继续第 6.7 到 6.9 节讲急停后的原点复位、存在中间待机动作时的复位与吸着 Retry、以及 Z/R 轴原点复位的可能范围。这三节合起来回答一个现场高频问题急停后为什么不能简单清报警继续跑因为急停发生时机械臂可能停在任意位置吸着回路可能还带着一片玻璃Z 轴可能在行程中间。直接继续会让状态机的当前位置假设失效。规格书的做法是强制走原点复位流程且复位本身有范围约束6.9 节超出范围要先手动干预。吸着 Retry6.8 节则是针对复位后工件还在手上的情况先确认吸着状态再决定是放回还是继续搬。注意原点复位不是回零这么简单它是一次带状态校验的重新初始化。现场如果跳过复位直接发命令最常见的现象是位置偏差累积几片之后开始报 0x1D/0x1E 的 Glass Shift 异常。4. 感知与对位碎裂检测、在荷确认、非接触 Alignment 怎么协同4.1 碎裂检测与在荷检测为什么被拆成两个独立功能版本履历里有一条很关键6000.03.x.A Glass 碎裂检测功能、在荷检测独立功能追加随后 6000.031.x.A 又追加了碎裂检测功能用 Error。这说明早期这两个功能是耦合的后来被拆开。拆开的动机是误判率碎裂检测看的是玻璃完整性可能用边缘或应力传感在荷检测看的是手上有没有东西吸着压力/流量。两者物理量不同耦合在一起时一片正常但吸着略弱的玻璃会被误报成碎裂。拆开之后异常码也分开了0x04/0x0A 是吸着异常V/S err0x05/0x0B 是在荷检测异常碎裂相关则走独立的检测路径。这种一个物理现象一个传感器、一个传感器一个异常码的拆分原则是这类设备可维护性的基础——现场看异常码就能定位到具体传感器不用猜。4.2 吸着确认无效 Parameter为什么允许关掉确认第 6.13 节讲吸着确认无效 Parameter版本履历 6000.01.x.A 追加。允许关掉吸着确认听起来危险但有明确场景某些薄玻璃或特殊工装下吸着压力传感器的读数波动大强制确认会导致频繁误报停机。参数化关闭确认等于把是否信任这个传感器的决定权交给工艺工程师。常见的实现思路是确认逻辑本身保留只是用一个开关短路掉判定结果同时仍然记录传感器原始值供诊断。这样关掉确认不等于关掉观测出问题时还能回溯。这个设计取舍值得记住——安全相关的检查可以放宽但观测不能丢。4.3 非接触 Alignment 的四种 Sensing 路径第 8.3 节把非接触 Alignment 按用哪个传感器、感哪个方向分成四类Hand 部 Alignment Sensor 做 R 轴方向、固定式 Sensor 做 X 轴方向、Hand 部 Sensor 做 X 轴方向、Line Sensor 做 X 轴方向。第 9 章又给了两条执行 Flow。这种多路径并存不是冗余而是适配不同世代的机械结构和不同尺寸的基板。以 Line Sensor 的 X 轴 Sensing 为例6.11 节它又细分为通过信号指定和通过 Command 指定两种触发方式6.11.1两者的差别在于谁来控制感应的起止时机信号方式由 PLC 实时控制适合与外部输送同步Command 方式由控制器内部时序控制适合固定节拍。选错方式不会报错但会出现感应窗口和玻璃实际位置错位表现为 Alignment 补偿量异常0x2C/0x2D/0x2E。Line Sensor X 轴 Sensing机制示意: 信号方式: PLC 置 Sensing Start - 控制器按当前速度扫过 - 置 Sensing Done Command方式: 控制器收到 Command - 内部按参数化速度/窗口扫描 - 置 Done 差异点: 扫描窗口的起止由谁决定 失败表现: 补偿量超限 - 0x2C(θ) / 0x2D(Y) / 0x2E(X)4.4 基板纵横指定与 Shift Sensor 双个对应6500.01.x.A 追加了基板纵横指定功能且在荷确认仕样变更和Shift Sensor 2 个对应。纵横指定意味着同一套程序要处理横放和竖放两种基板姿态Teaching Data 里必须能区分Shift Sensor 从 1 个变 2 个则是为了同时检测两个方向的偏移而不是靠单传感器加假设推算。这两条改动都指向同一个趋势基板越大、对位要求越高单点感知越不够用必须多点冗余。5. 异常码体系0x01 到 0x37 为什么这样分段5.1 异常码的分段逻辑与现场定位路径第 10 章的异常码表从 0x01 排到 0x37中间还有若干未使用占位。分段规律大致是0x01-0x03 参数类0x04-0x0F R1/R2 吸着与在荷类0x10-0x1F 握手与 Alignment 类0x20-0x2E 命令参数与补偿量类0x30-0x37 Mapping 与 Torque/Thermal 类。保留未使用占位是为了版本兼容——新增异常码插进预留段不打乱已有编号PLC 侧的异常处理逻辑不用改。现场定位路径因此很清晰先看异常码落在哪个段段位决定查哪一章。0x04 段查吸着回路和真空传感器0x11 段查 Alignment Sensor 的 ON/OFF 时序0x20 段查 PLC 下发的命令参数是否越界。这种编号即索引的设计比一堆无编号的错误字符串好用得多。5.2 参数类异常为什么占大头数一下会发现0x20 到 0x2E 几乎全是指定的 XX 值不合适。这不是巧合控制器和 PLC 之间靠编号传参任何一方版本不一致、配置错位都会表现为参数越界。规格书把这些情况逐一给码等于把配置错误从运行时崩溃里分离出来。血泪经验是现场大部分所谓机器人抽风追到底都是 PLC 侧某个寄存器写错了位置号或 Work Type。5.3 Torque 与 Thermal 异常机械健康的最后一道观测0x36 Torque 值异常、0x37 Thermal 值异常是 6500.00 版追加的。这两个不是搬送逻辑的一部分而是机械健康的旁路观测扭矩超限可能意味着卡阻或碰撞温度超限可能意味着连续高负载。把它们做成异常码而不是 Warning说明设计上认为这两类情况必须停机处理不能带病运行。6. 避坑与排查现场最容易翻车的五个点6.1 现象换版后所有位置整体偏移 → 原因CC-LINK 扩展 Cyclic 设定未同步 → 解决核对主站占用站数与扩展设定6500.00 版把 CC-LINK 设定变更到 Version2.0、扩展 Cyclic 2 倍寄存器数量翻倍。如果 PLC 主站参数还按老版本配地址映射整体错位表现就是所有位置号解析出错误坐标。排查时先比对双方版本号和占用站数再看 Data Register 的实际读写地址是否落在规格书 4.2 节给的范围内。6.2 现象偶发 0x10 完成 ACK 超时 → 原因PLC 扫描周期抖动或 ACK 位被覆盖 → 解决查扫描周期与 ACK 位写逻辑0x10 的根因几乎总在 PLC 侧。先测 PLC 最大扫描周期是否接近控制器动作时间再看 ACK 位是否被同一程序里别的分支重复写。常见翻车是 ACK 位用了自复位逻辑控制器还没读到就被清掉了。6.3 现象碎裂检测频繁误报 → 原因碎裂与在荷检测未按新版拆分 → 解决确认程序版本 ≥6000.03 并检查传感器独立配置6000.03 之前碎裂和在荷是耦合的薄玻璃吸着略弱就误报。确认控制器程序版本并按 6.13 节检查吸着确认无效 Parameter 是否被误开——误开会让在荷判定失效反而放大误报。6.4 现象Alignment 补偿量报 0x2C/0x2D/0x2E → 原因Sensing 触发方式与输送节拍不匹配 → 解决核对信号方式与 Command 方式的选用信号方式适合与外部输送同步Command 方式适合固定节拍。用错方式时感应窗口和玻璃实际位置错位补偿量算出来超限。按 6.11.1 节确认当前用的是哪种触发再对照 8.3 节确认传感器路径选对。6.5 现象急停复位后连续几片位置偏差 → 原因跳过原点复位或复位范围超限未处理 → 解决强制走 6.7-6.9 节复位流程并检查 Z/R 轴范围急停后直接清报警继续状态机的当前位置假设是错的偏差会累积。按 6.9 节确认 Z/R 轴在可复位范围内超出范围先手动干预再走完整复位和吸着 Retry。7. 设计取舍为什么这套程序宁可死板也不聪明读完这份规格书最值得琢磨的不是某个功能怎么实现而是整套设计反复做的同一个取舍宁可把契约写死、把异常码排满、把状态迁移约束到死板也不让控制器聪明地猜。CC-LINK 的 IO 分配按块定死位置号必须查表翻译握手必须三段确认重叠动作冲突时退化串行而不是动态调度——每一条都在牺牲灵活性换可预测性。这不是技术保守而是场景决定的。玻璃搬送面对的是高价值工件、连续产线、多人维护一次静默的错误比十次明确的停机代价大得多。异常码从 0x01 排到 0x37、还预留未使用段本质是把可能出错的方式提前枚举完让现场任何一次停机都能对应到一个确定的编号和一条确定的排查路径。这种设计哲学和互联网系统追求的自愈、弹性几乎相反但在工业现场它是正确的可观测、可复现、可交接比聪明重要。验证这套设计是否被正确实现我一般会做三件事一是拿异常码表逐条对照程序里的判定分支看有没有码没实现或实现了没码二是用 Timing Chart 反推握手时序在 PLC 侧打点确认每个沿的先后三是故意制造参数越界比如写一个不存在的 Position No确认报的是 0x20 而不是别的码。这三步走完基本能确认程序和规格书是同一套契约。从那以后我每次接手这类搬送程序都强制先把 IO 分配表和异常码表打印出来贴在工位上改任何一行逻辑前先在上面找到对应的编号。希望帮到你。本文还有配套的精品资源点击获取