企业官网建设流程全解析

简介：这份阿特拉斯（Atlas Copco）PowerFocus 6000开放协议附录文档，面向需要远程控制或数据订阅控制器的自动化工程师、PLC与上位机开发者，以及负责紧固系统集成的技术人员。它围绕PF6000在Open Protocol实现中的产品专属事项展开，可帮助读者理解协议落地的边界与约束。压缩包内仅含1个PDF文件，大小约980KB，篇幅集中、便于随查随用。文档按MID支持、MID Relay与数字输入信号、Revision支持、MID 64/65旧结果数据特殊处理，以及紧固程序（Pset）选择、Pset批量大小和序列（Job）选择等模块组织，并给出通信启停、参数集上传与选择等消息的修订支持说明。已有195人学习，适合在对接PF6000、排查消息兼容性或设计数据订阅方案时作为协议附录查阅。

1. 拧紧枪的数据抓不出来？先看这份 2.8 版开放协议附录

车间里最常见的画面：拧紧枪在工位上转得好好的，PLC 想拿一次拧紧的扭矩、角度和 OK/NOK 判断，结果只能对着现场总线干瞪眼；再往上，MES 想知道这批活儿做到第几颗、当前选的是哪个紧固程序，又是一条单独的数据链。中间缺的那一环，往往就是控制器的开放协议 Open Protocol。这份资源是某工业装配工具厂商 PF 6000 系列控制器的开放协议附录，规范版本 2.8 Rev.2，从 2.8.14 固件起生效，内容不是泛泛的协议科普，而是把「这台控制器到底支持哪些消息、哪些字段、哪些现场 IO 信号」一条条列清楚。

它解决的是选型前的可行性判断和联调时的对表问题：你要做的功能，MID 清单里有没有对应的一行？有的话 Revision 到几？继电器和数字输入功能号能不能对上你现场的 IO 点？这些在主协议文档里查不到，全在这份附录里。适合三类人：要对接拧紧控制器的上位机或 PLC 工程师、做产线数据采集与追溯的集成商、手里已经有协议主文档但联调总在字段上翻车的人。

2. MID 支持表怎么读：把 Revision 一列当成能不能下手的判据

六十多条 MID 摆在一张表里，新手最容易犯的错是从上往下一条条试。熟手反过来：先看自己要实现的功能对应哪几个 MID，再看 Revision 列和后面的章节备注，最后才决定协议栈怎么写。这张表真正的价值在这儿——它是一份「哪些路能走、哪些路是死胡同」的前置判断，能省掉两三天无效联调。

2.1 数字、「p」、「-」三种记号的含义完全不同

附录里对这三类记号的定义很直白：Revision 列写数字，表示控制器支持从 Rev0 一直到这个数字的全部版本；写「p」，表示这个 MID 至少有一个 Revision 是部分支持；写「-」，表示完全不支持。这三种记号决定了三种完全不同的开发动作。

写数字的，可以按表里的最高 Revision 直接发，字段按主协议文档补齐就行，比如 0001 是 6、0038 是 2、0071 是 3。写「p」的，是最费时间的一类：报文能通，但字段缺斤少两，你必须拿着真实报文逐个字段比对，不能看到回复就以为拿到了完整数据。附录里被标 p 的不少，0002 通信启动应答、0012/0013 参数集数据上传、0033 Job 数据上传应答、0035 Job 信息、0041 工具数据上传应答、0061 最近一次拧紧结果、0065 旧拧紧结果应答、0140 动态 Job 请求、0200 设置外部控制继电器、0250~0253 选择器插槽信息，都在这个名单里。

写「-」的，就是明确不该碰的路。0044 断开工具、0046 设置主工具、0047~0049 配对相关、0090~0103 整段多轴状态与多轴结果、0110/0111 在紧凑型与图形界面显示文本、0130 Job 关闭、0240~0244 用户数据、0270 控制器重启、0410/0411 AutoDisable、8000~8003 那组紧急状态，全是不支持。发过去的结果基本就是一条 0004 指令错误，白白浪费一轮排查时间。

有一类细节特别容易被忽略：表里还有备注列。0076 报警状态那行写着「只发送需要确认的活动事件」，意思是不要指望它把所有报警都推给你；0210/0211 那行写着「初始 211 需要一台配置了外部监控信号的设备」，这是硬件配置前提，不是代码问题；500~504 电机调优结果那几行写着「事件 2022 必须配置为在控制器中显示」。备注列看漏一条，联调现场就要多熬一个下午。

2.2 握手四件套和 9999 心跳

0001 发出去，正常情况回 0002；请求被拒会回 0004，被接受会回 0005。注意 0002 本身是 p，字段只有部分是可靠的，我一般只从里面取协议 Revision 和通道号两个值，剩下的当调试信息原样打印出来存日志，等出问题再翻。别用 0002 的字段去反推控制器支持什么功能，那是这张表该干的事。

帧格式是定长 ASCII：前 4 位是整个报文的字符总数（包含这 4 位本身），紧接着 4 位是 MID，剩下是数据体。这个「长度包含头部自身」的约定是新手第一个卡点，很多人写出来总是差 4。

def build_frame(mid: int, body: str = "") -> bytes: """Open Protocol 帧：4 位总长度 + 4 位 MID + 定长 body，全 ASCII""" payload = f"{mid:04d}{body}" total = len(payload) + 4 # 长度字段本身也计入总长 return f"{total:04d}{payload}".encode("ascii") def read_frame(sock) -> tuple[int, str]: """按长度字段精确读满一帧，不用分隔符，不依赖 recv 一次收全""" head = b"" while len(head) < 4: chunk = sock.recv(4 - len(head)) if not chunk: raise ConnectionError("对端关闭连接") head += chunk total = int(head) rest = b"" while len(rest) < total - 4: chunk = sock.recv(total - 4 - len(rest)) if not chunk: raise ConnectionError("对端关闭连接") rest += chunk text = (head + rest).decode("ascii") return int(text[4:8]), text[8:] print(build_frame(1)) # b'00080001'，0001 在 Rev6 下 body 可以为空

build_frame里total要把长度字段自身的 4 位算进去，这是协议约定，不是习惯问题。read_frame用循环把recv补满，是因为 TCP 是字节流，一帧拆成两个包到达太正常了；一次性recv(total)在本地测试机上跑得好好的，上产线就偶发解析错位，这种玄学问题十有八九就是没读满。

9999 心跳的 Revision 是 0，作用就是保温连接。发得太勤没意义，太稀疏又容易被中间设备掐掉，我一般设 5~10 秒一次，同时在本地维护一个「最后收到任意帧的时间戳」，超时三倍心跳间隔就按断链处理，走重连而不是继续等。

2.3 结果类 MID 的取舍：0061 订阅还是 0065 拉取

拧紧结果有两条完全不同的路。0060~0063 是订阅式的，控制器在每次拧紧结束时主动把结果推给你，客户端回 0062 确认，不需要时用 0063 取消订阅。这条路适合实时跟线，PLC 拿到 OK/NOK 立刻放行或拦截，延迟最低。

0064/0065 是上传式的，客户端主动去拉历史结果，适合断线重连后补数据，或者离线批量采集。但 0065 标的是 8p，附录专门用 2.4 节讲它的特殊处理，还用 2.3 节讲哪些参数不支持。这两个信号要一起看：能拉到的旧结果结构，和实时推给你的结果结构，字段并不是一一对应的。我吃过一次亏——实时通道里有的角度细分项，在旧结果里就是空值，代码里没做判空，整条追溯记录被写成了 0，对账的时候被产线问了一整天。

实用的判断规则是这样：实时控制走 0060 订阅；数据补采走 0064 拉取；两条路都各自写一份字段映射，不要图省事共用一套解析函数。另外 0061 是 8p，意味着它推过来的数据体里也有部分字段不可靠，修完解析器之后一定要拿一条真实的 OK 记录和一条真实的 NOK 记录分别核对，只测 OK 那条很容易漏掉只在异常分支里出现的字段。

3. 继电器与数字输入：0215 和 0221 两张表怎么落到产线 IO

如果上位机方案是走 PLC 而不是纯软件，这一章比报文本身更重要。产线上真正决定节拍的往往不是报文，而是那几个硬线 IO：OK 灯亮不亮、批次做完了没有、扫枪能不能触发。附录 2.2 节把继电器功能编到了 353 号，数字输入编到了 20 号往上，这些编号是配 IO 时的唯一依据，配错一个号，排查方向会彻底跑偏。

3.1 继电器编号不是随手编的，是分段的

353 个编号看着吓人，按功能分段之后就清楚了。00~31 是基础状态段，最常用的是 01 OK、02 NOK、09 循环完成、10 报警、18 控制器就绪、19 工具就绪、20 工具启动开关、21/22 方向开关。这一段基本能覆盖一条普通工位的全部指示灯和放行信号。

32~39、59~66，加上 110 和 111，是运行中 Pset 和运行中 Job 的位。bit0 到 bit9 拼起来就是一个十进制编号，也就是说不用发任何报文，光靠读 IO 就能知道当前在跑第几个程序和第几个 Job。做老设备改造、上位机又不想大改的时候，这个设计特别省事。

有一点必须提醒：251~266 这两段是各 8 位的组合量，单看某一位没有意义，必须按位拼成整数再显示。我见过现场直接把 251 接成「批次完成」指示灯，结果第一个批次亮、第二个批次反而不亮，因为 251 只对应已完成数量的 bit0，计数到 2 的时候 bit0 是 0。这种坑看现象很玄学，看表一眼就明白了。

3.2 Tracking event 那一列的 Yes 和空白，决定你该订阅还是该轮询

继电器表的最后一列叫 Tracking event，有的编号写 Yes，有的空着。按附录的标注理解，这一列标 Yes 的功能在状态变化时会被纳入事件跟踪，可以在 0215 或者相关状态报文里被感知；空着的就只有电平状态，你只能在收到 0215 回复时看到当前值，中间跳变抓不到。

这个区别直接决定采集策略。像 01 OK、02 NOK、05 低扭矩、06 高扭矩、12 Job OK、13 Job NOK、14 Job 运行中、90 使能扫描枪、91 线控启动、93~102 外部控制 1~10，这些标了 Yes 的，可以用状态变化去驱动业务逻辑。而 03 低、04 高、09 循环完成、10 报警、32~39 的运行中 Pset 位、144 批次完成，这些都没标 Yes，只能靠轮询 0215 去取当前值，轮询间隔就成了精度上限。

需要精度的地方就别省这一次报文。批次计数这类会跳变的状态，我一般 200~500 毫秒轮询一次 0214/0215，同时用 144 批次完成继电器做一次交叉验证，两个来源对不上就报警，比事后追账强得多。

3.3 DigIn 功能号：复位批次、远程启动和 Pset 选择位

数字输入的编号比继电器少得多，但每一个都要配准。01 复位批次、02 解锁工具、05 工具拧紧禁用、06 工具松开禁用、07 远程启动脉冲、08 远程启动持续、09 工具启动松开、10 批次递增、11 跳过 Pset、12 中止 Job、14 参数集切换、15 复位继电器，这些是最常用的。

03 和 04 是两个特殊项：工具禁用 n.o.（常开）和工具禁用 n.c.（常闭）。同一个物理功能走两种电气逻辑，接错线的话表现正好相反——本该禁用的时候工具还能转，这在安全相关的工位上是要出事的，接线前一定对着表核一遍常开常闭。

16~19 是参数集选择位 0~3，这四个位拼起来能表达 16 个程序。用硬线选程序和用报文发 0018 是两条平行路径，选哪条取决于现场有没有 PLC 以及换型频率。硬线选的优点是响应快、不依赖网络；缺点是改程序数量要动线。报文选的优点是灵活，缺点是一旦网络抖动，程序就切不过去。我的习惯是：换型频繁的工位走报文，固定几个程序的工位走硬线，两条路径不要同时启用，否则谁最后生效说不清。

13 号 Job 关闭这一项要单独说。它在数字输入表里是存在的，但事件跟踪那一列是空白的，意味着只能当电平功能用，不能指望它产生事件。这条和第 4 章要讲的 0130 Job 关闭是「-」不支持，其实是同一个限制的两个侧面——这个控制器体系里，「关闭 Job」不是一个可以随便调用的动作。

3.4 0215 报文里那几个偏移量，别照着别人的代码抄

0215 IO 设备状态回复里有继电器数量和继电器状态、数字输入数量和数字输入状态这几段。附录给了两个计算公式，X = 31 + 4 × 实际继电器数量，Y = X + 8 + 4 × 实际数字输入数量，用来定位不同设备块之间的起始位置。这里的 4 是每个设备块占用的字符数，也就是说继电器或数字输入数量一变，后面所有块的起始位都要跟着挪。

这就是为什么网上抄来的解析代码在你的现场一定跑不通——对方工位 8 个继电器，你这里 16 个，后面的数字输入状态整体错位 32 个字符，读出来的全是垃圾。正确做法是先读数量字段，再用公式算出起点，最后按块解析。

def parse_0215(body: str) -> dict: """0215 是定长 ASCII，先读数量，再按数量算每段起点，绝不硬编码偏移""" pos = 0 unit_id = body[pos:pos + 4]; pos += 4 # 设备/单元编号 relay_cnt = int(body[pos:pos + 4]); pos += 4 # 本设备实际继电器数量 relay_state = body[pos:pos + 4 * relay_cnt]; pos += 4 * relay_cnt digin_cnt = int(body[pos:pos + 4]); pos += 4 # 本设备实际数字输入数量 digin_state = body[pos:pos + 4 * digin_cnt] return { "unit": unit_id, "relay": [relay_state[i:i + 4] for i in range(0, len(relay_state), 4)], "digin": [digin_state[i:i + 4] for i in range(0, len(digin_state), 4)], }

这段代码里最关键的不是切片本身，而是「先读数量、再算长度」这个顺序。relay_cnt和digin_cnt都是从报文里读出来的，不是写死的常量，这样同一份代码才能同时适配 8 路和 16 路的设备。每路状态占 4 个字符（两路状态码，或者一组位），具体怎么解读要拿一条真实回复对着功能表核一遍，别凭猜。写完解析器之后，手动把某个继电器强制置位一次，看解析出来的那一位有没有跟着翻转，这是最快的验证方式。

4. Pset、Batch、Job：三个选择动作的报文级实现

这三个概念在产线上天天被混着叫，但在协议层是三套独立的东西：Pset 是紧固程序（用哪套扭矩角度参数），Batch 是批次（这个程序要做多少颗），Job 是作业序列（一串 Pset 加顺序和跳转条件）。附录用 2.5、2.6、2.7 三节分别讲，说明这三套东西的坑是分开的，别指望一套代码通吃。

4.1 Pset 三件套：选择、订阅、上传

选择用 0018，报文里带 Pset ID 和批次大小。这条是「设置型」请求，回 0004 或者 0005，注意 0005 只代表指令被接受，不代表切换已经生效，切换是否完成要看 0015 参数集已选上报。

订阅用 0014~0017 这四个：0014 订阅、0015 上报、0016 确认、0017 取消订阅。0015 只在选择发生变化时才发，所以订阅之后不要干等，先主动发一次 0018 触发一次变化，把当前值确认下来。这一点和很多订阅类协议的「订阅即推当前值」不一样，容易踩空。

上传用 0010/0011 拉 Pset ID 列表，用 0012/0013 拉具体的参数集数据。这里要特别注意：0012/0013 标的是 Rev4 且带 p，附录 2.5 节专门讲了它的部分支持问题。我的一般做法是只用 0010/0011 拿 ID 清单，参数配置在本地维护一份，不去依赖 0012 把一整套参数完整拉回来。真要做配置比对，也只看自己关心的那几个字段，剩下的当只读参考。

def zpad(v, w: int) -> str: """数字类字段左补零，长度必须精确等于字段宽度""" s = str(v) assert len(s) <= w, f"{s} 超出字段宽度 {w}" return s.zfill(w) def spad(v, w: int) -> str: """字符类字段右补空格，同样定长""" s = str(v) assert len(s) <= w, f"{s} 超出字段宽度 {w}" return s.ljust(w) # 0018 选择 Pset：字段宽度按附录 2.5 节的字段表填，这里用常见宽度示意 body = zpad(5, 3) + zpad(10, 4) # Pset ID = 5，批次大小 = 10 sock.sendall(build_frame(18, body)) mid, data = read_frame(sock) assert mid in (4, 5), f"0018 期望 0004/0005，实际收到 {mid}"

zpad和spad看着像凑数的工具函数，但协议里字段是定长的，少补一个零整条报文就错位，后面所有的字段全废。assert那一行是我强制加的护栏：字段超宽的时候宁可当场抛异常，也不要静默截断——截断的报文发出去，控制器可能照样回 0005，但选中的是另一个程序，这种错误在产线上极难发现。最后那句断言同样重要，0018 只认 0004 和 0005，收到别的 MID 说明前面的帧解析已经错位了，继续往下走只会越错越远。

4.2 批次大小与 Lock at batch done

批次相关的四个动作：0019 设置批次大小、0020 复位批次计数器，加 0021~0024 那组 Lock at batch done 的订阅、上报、确认、取消订阅。

0019 是给某个 Pset 设定批次大小，也就是说批次是挂在 Pset 上的，不是全局的。切换 Pset 之后批次计数是不是延续，取决于你对 0020 的调用时机。我见过现场换型之后计数接着上一批往下走，最后批次完成信号永远不触发，根因就是换 Pset 之后没复位计数器。

0021~0024 那一组的语义在附录里有明确备注：0022 这个信号表示的是「被批次序列完成锁定」，也就是整批做完之后的锁定状态，不是批次进行中的进度。把它当成「批次做完了」的脉冲去用会出问题，因为它是个持续状态，要靠后续动作才能解除。

真要做批次进度显示，比 0022 更靠谱的是 251~258 已完成批次位和 259~266 剩余批次位，这两段各 8 位，拼起来就是两个整数。要注意位数上限——8 位最大 255，批次大小超过 255 的时候这两段表达不了，得靠报文里的计数字段。

4.3 Job：选择、重启、动态 Job

选择 Job 用 0038，Revision 2。Job 重启用 0039，Revision 1，语义是让当前 Job 从头开始，不会切换到别的 Job。Job 的状态订阅用 0034~0037 这一组，其中 0035 Job 信息带 p，字段部分支持，做展示够了，做控制判断要谨慎。

0140 执行动态 Job 请求标的是 Rev1 加 p，意思是这个功能存在但只能部分用。动态 Job 的典型场景是同一工位上按车型临时拼一条作业序列，不用预先把所有组合都配到控制器里。想法很好，但因为 p 的存在，实际项目里我一般先做一条最小验证：发一次请求，把返回的 Job 号和控制器面板上显示的 Job 号对一遍，能对上再往下做。

0120~0129 那一组 Job line control 是产线节拍控制常用的：0121 启动、0122/0123 两级预警、0124 完成、0127 中止、0128 批次递增、0129 批次递减、0131/0132/0133 设置各个控制点。这套东西配合线体做「到点提醒、超时拦截」很顺手，但它对时序敏感，网络抖一下就可能漏掉一个预警，所以关键拦截动作还是要落到硬线 IO 上做兜底。

4.4 0130 Job 关闭是「-」，那关 Job 到底怎么做

这是附录里最容易被忽略、但现场问得最多的一条。0130 Job 关闭在表里是「-」，也就是这个控制器不支持这条 MID。很多人照着主协议文档写完 0130，上线发现永远回 0004，然后开始怀疑网络、怀疑固件、怀疑人生。

正确的替代路径有两条。第一条走报文：用 0127 中止 Job（Rev1，支持），语义是中止当前正在执行的 Job，效果接近「不干了」。第二条走硬线：数字输入的 12 中止 Job，或者继电器 138 Job 关闭继电器——注意后者只是状态指示，是告诉外面「现在 Job 处于关闭态」，不是让你去关它的控制点。

选哪条取决于你要的是「中止当前这一轮」还是「让整个 Job 处于关闭状态」。前者用 0127，后者只能靠 IO 或者控制器面板操作。把这两件事混为一谈，代码写出来就是错的，而且错得很隐蔽——因为中止确实让产线停下来了，看起来像是生效了，但下一个循环 Job 又自己跑起来了。

5. 避坑：五条踩坑记录

下面这五条都是联调现场真实会遇到的，按现象、原因、解决的顺序写，遇到对应的现象可以直接对号入座。

5.1 握手回了 0002，但字段一大半是空的

现象：0001 发出去，收到了 0002，解析出来只有 Revision 和通道号有值，后面几个字段全是空格或者 0。

原因：0002 在表里标的是 6 加 p，也就是这个 MID 的 Revision 6 只是部分支持，字段并不保证齐全。很多人默认「握手成功 = 控制器信息全拿到了」，然后拿这些字段去做功能判断。

解决：只取 Revision 和通道号两个可靠字段，其余原样存日志。判断控制器能力去看第 2 章那张 MID 表，而不是看 0002 的返回值。写代码的时候给解析函数加一句注释，标明哪些字段不可信，比事后回忆强。

5.2 0211 一直收不到，订阅像是没生效

现象：0210 订阅成功，回了 0212 确认，但 0211 状态上报一条都没有。

原因：附录在 0210/0211 那一行写得很清楚——初始的 0211 需要一台配置了外部监控信号的设备。这是硬件配置前提，不是软件问题。控制器上没配外部监控信号，就没有状态可报。

解决：先去控制器侧确认外部监控信号有没有配置、配在哪几路，再回来订阅。同时把这条写进项目的前置条件清单里，别等到联调最后一天才发现硬件没配。类似的备注还有 500~504 电机调优结果，需要把事件 2022 配置为显示，同一个道理。

5.3 0065 拉回来的旧结果，好几个字段是 0

现象：用 0064 拉历史拧紧结果，字段结构看着对，但角度细分、状态位这几个位置永远是 0。

原因：0065 标的是 8p，附录 2.3 节专门列了不支持的参数，2.4 节讲 MID 64/65 的特殊处理。这些字段

本文还有配套的精品资源，点击获取