企业官网建设流程全解析

搞配料、包装、检重这些产线的人，估计都碰上过这种局面：西门子SMART200 PLC和一台托利多电子秤明明离得不远，秤上的重量数字跳得清清楚楚，PLC里却死活读不到。要么收进来是一串乱码，要么干脆没反应，最后只能靠操作工看秤手工抄数。这篇就围绕SMART200自由口通讯把路子捋一遍——从硬件接线、口参数，到XMT/RCV程序框架、报文解析，再到超时和报警处理。以我调这类秤的经验，九成问题其实不在硬件，而在于开头三步没走对：协议模式没搞清楚、物理链路没接好、口参数没对齐。适合正在做老秤改造、新产线通讯调试或者纯粹想搞懂自由口原理的朋友参考。

1. 为什么偏偏要用自由口：秤的报文让Modbus库英雄无用武之地

1.1 电子秤通信模式的两种面孔

托利多秤的串口通讯大体分两种模式。第一种是连续输出，秤只要上了电、处于称重状态，就按自己设定的周期往外发当前重量，PLC只负责收。第二种是命令应答，PLC先发一个读取命令，秤收到后再回一帧当前数据，一问一答。

连续输出简单粗暴，程序只需要管收包；但有个问题——你无法主动控制和秤的对话节奏，而且像清零、去皮这类操作如果秤也支持串口命令，就得走命令应答。命令应答模式需要你先把秤侧的命令字搞清楚，再在PLC里组帧发送，程序上多一层状态管理，但可控性明显更高。我个人在配料类项目里更倾向命令应答，因为每一帧数据都对应一次明确的请求，程序里好做超时判断，也方便判断秤到底是在线还是已经掉线。

1.2 SMART200自由口到底能干多少活

S7-200 SMART的集成串口物理层是RS485，默认走PPI协议与编程软件通信。当你在程序里把串口改成自由口模式之后，这个口的协议就完全交给你定义了：波特率、数据位、校验位可以配；收发全靠XMT和RCV两条指令；每个口的发送完成、接收完成、字符到达都有对应的中断事件。

自由口模式下，CPU不会替你区分帧，所有字节按原始形态进出，所以你要自己定"一帧到什么时候算完"。这是它的灵活之处，也是很多初学者觉得难的地方。记住一点：它是半双工，发和收不能同时进行，程序状态机要避免"一边发一边收"的冲突。另外，自由口模式下Port0不再响应PPI编程协议，好在SMART200有以太网口，在线监控走网线就行，这个后面还会细说。

1.3 为什么Modbus RTU库在这里第一轮就被淘汰

SMART200自带的Modbus RTU主站库确实好用，但是它的报文结构是固化死的：功能码、寄存器地址、数据区全部按标准Modbus帧打包。托利多这类电子秤走的是厂商自定义的ASCII字符串协议，帧头、状态位、重量段、单位都是特定排列，有些帧尾还带异或校验字节。你没法在MBUS_MSG里塞进去自定义ASCII报文，所以正确做法就是绕开Modbus库，直接用自由口的XMT/RCV来收发。

判断标准很简单：翻一下秤的通讯协议手册，如果帧格式里出现了大量ASCII可打印字符，比如字母、逗号、正负号，而不是标准的十六进制功能码加寄存器地址，那就别折腾Modbus了。硬要用库去套，最后只能是在软件里反复改寄存器映射，浪费时间还收不到正确数据。

2. 接线、口参数和第一行SMB30：动手前的三个关键决定

2.1 从秤的RS232到PLC的RS485：一段最容易被忽略的路

大多数托利多秤随机标配的串口是RS232，而SMART200集成Port0是RS485，两者电平标准不一样，直接怼上去是没用的。常规做法是外接一个RS232转RS485转换器，转换器RS232那一侧接电子秤的串口，RS485那一侧的两根线接到PLC的A、B端子上。接之前一定翻手册确认PLC侧DB9的3脚和8脚定义，不同批次产品引脚标注有差异，别想当然，用万用表量一下最稳。

转换器的选购有几个关键点：要选有源供电的型号，别贪便宜用无源的，秤的232口驱动能力有限，很容易出现"单独接电脑正常、接上PLC就没反应"的情况；有条件就选带光电隔离的，现场变频器、伺服干扰大的时候能救命；波特率范围至少要覆盖9600到19200。另外，如果这台秤本身支持RS485选件或者PLC端加了RS232信号板，那可以省掉转换器，但A/B线的顺序、屏蔽层接地这些同样不能错。

2.2 口参数必须两边对齐：波特率、数据位、校验位一个都不能错

电子秤面板里通常都有串口参数设置菜单，波特率、数据位、校验位、停止位都可以改。PLC自由口的SMB30里也要配成完全一致。最常见的组合是9600,8,N,1，也就是9600波特率、8位数据位、无校验、1位停止位。但我遇到过不少老秤默认是7位偶校验，这种情况下PLC如果还按8N1收，收到的字符串会整体错位，基本都是乱码或者干脆收不到。

调参数时先用秤把输出模式、波特率确认好，再在程序里按相同参数设置。顺序很重要：先调秤，再写PLC，两边挨个对齐。如果现场有多台秤，最好把每台秤的当前设置都记下来，尤其是博途里看不到的秤面板参数，一旦改了设置没记录下来，下次断电重启之后排查起来要命。

2.3 SMB30：运行时切换协议的那几个字节

SMART200的自由口是靠写特殊寄存器来激活的，Port0对应SMB30，Port1对应SMB130。SMB30的位含义见下表：

把这些位拼成一个字节，9600、8位数据、无校验、自由口就是16#09；如果秤要求7位偶校验，那就是16#A9。程序里只需要一条MOVB指令，把值写入SMB30，串口立即切到自由口。这里有个比老S7-200方便很多的地方：SMART200的编程调试走以太网口，所以哪怕你把Port0切成了自由口，也不影响在线监控和下载程序，调试体验好很多。很多老工程师担心一写SMB30就掉编程连接，在SMART200上完全不必有这个顾虑。

3. XMT/RCV的双人舞：初始化、缓冲区、接收完成中断怎么编排

3.1 RCV控制字节：接收规则由你定制

自由口接收不是傻傻地等，RCV指令有一个配套的控制字节SMB87，里面每一位都可以定义接收的触发和结束条件。SM87.7是总开关，必须置1；SM87.4是结束符检测，置1后RCV遇到SMB89里指定的结束字符就认为一帧结束；SM87.3是超时检测，置1后配合SMW92里的毫秒数，超过时间没收到数据就自动结束接收；SM87.5是空闲检测，置1后通过SMW90设定静默时长来判定一帧结束。

最常用的组合是"结束符+超时兜底"：正常帧按结束符收完，异常情况由超时来终止，避免RCV永远挂起。接收缓冲区用V区开辟，比如VB200开始。RCV执行后，系统会把实际收到的字节数写到缓冲区的第一个字节，后面的字节才是真正的报文内容。这个首字节非常关键，后面解析帧长、判断是否收到完整数据都靠它。缓冲区的长度至少要能装下"一字节长度+最大帧长"，我习惯把SMB94最大字符数设成32，遇到超长帧直接按错误处理，避免缓冲区被冲掉。

3.2 中断事件的"交通规则"：ATCH、ENI和事件号

自由口程序离不了中断。Port0的接收完成中断事件号是23，发送完成是9，每收到一个字符的中断是8。程序里先用ATCH指令把对应的中断程序和事件号绑在一起，再执行ENI开全局中断。这里有个建议：接收完成中断里只做收尾动作——比如把接收完成标志位置1、把接收长度保存到固定变量——不要在里面做复杂的字符串解析。

解析放到主程序或者轮询子程序里做，原因很简单：中断程序里逻辑越短，越不容易破坏主循环的时间节拍，也越不容易和主程序抢变量。还有一个小细节：RCV是一次性的，收完一帧后它会自动失能。如果还要继续收，必须在代码里再次执行RCV。所以程序结构上通常做成：接收完成中断置位 → 主程序发现标志后解析、处理 → 处理完再次RCV、清零标志。这套循环顺手了，通讯状态机就立起来了。

3.3 先搭一个能收能发的裸框架

下面这段是初始化部分的STL风格示意，对应"上电后把Port0切自由口并立即开始第一次接收"：

LD SM0.1 // 首次扫描脉冲 MOVB 16#09, SMB30 // Port0：9600, 8, N, 1，自由口模式 MOVB 16#98, SMB87 // 允许接收 + 结束符检测 + 超时检测 MOVB 16#0A, SMB89 // 帧尾结束符：换行 MOVW 100, SMW92 // 100ms超时 MOVB 32, SMB94 // 最多接收32字节 RCV VB200, 0 // 启动第一次接收 ATCH INT_RCV, 23 // 绑定接收完成中断 ENI // 全局开中断

发送侧也一样，把要发的命令按"长度字节+数据"的格式放缓冲区，然后XMT。比如命令只有一个字符'R'，那VB100里放1，VB101里放16#52。如果还要在发送完成后知道"已发完"，可以把发送完成中断也绑定上，置一个发送空闲标志。裸框架跑通之后，再往里面加解析和业务逻辑，心里就踏实了。这个阶段我习惯先把两块通信状态字M变量加上注释，M0.0接收完成、M0.1发送空闲，后面所有逻辑都围绕这两个标志展开，程序不会乱。

4. 不定长报文到底怎么收：结束符RCV和字符中断拼包两种打法

4.1 结束符方案：SMB89设成0A，帧尾干净利落

如果秤的帧尾固定且唯一，最简单的方法是结束符接收。把SMB89设成帧尾字符的ASCII码，比如秤以回车换行结尾，就把SMB89设成16#0A（换行）。RCV接收到这个字符，自动判定一帧结束，转到接收完成中断。在接收完成中断里，先看SMB86状态字节有没有错误位，再看缓冲区首字节的长度是否符合预期。

这套方案很省事，但有一个前提：结束符在报文中不能出现在其他位置。托利多秤的数据部分基本是数字和逗号，换行符只会出现在帧尾，所以实测很稳。命令应答模式下，我一般先执行RCV再发XMT，顺序别反。

提示：命令应答模式下，务必要先执行RCV，再执行XMT。接收没有挂好就发命令，秤的应答可能从第一个字节就丢了。

先让接收挂好，再发命令，这样秤的应答一到，RCV立刻就能接住，不会丢第一个字节。如果你发现收到的数据总是少一个字符或者首尾不齐，第一反应就应该是检查这个顺序。

4.2 字符中断方案：每个字节都自己说了算

有些秤的协议帧尾不固定，或者一帧里可能出现多个换行，这时候RCV结束符方案就有点不好用。可以改用每接收一个字符触发一次的中断（Port0对应事件8），在中断里把SMB2（接收到的字符）逐个存入自己维护的缓冲区，手动计数。帧结束怎么判断？常见做法是配合一个超时窗口：如果距离上一个字符超过比如50ms还没有新字符进来，就认为这帧结束了。

字符中断方案的优点是逻辑完全你自己说了算，协议再怪也能拼出来；代价是每个字节都打断一次CPU，程序里还要维护缓冲区指针、长度计数器、帧结束判定。不过9600到19200波特率下，SMART200完全扛得住。如果既有帧尾又要防异常，可以在字符中断方案里加上最大长度保护，超过预定长度直接丢弃重来。写这个方案时建议把缓冲区指针和长度计数放在同一个V区连续地址，调试的时候从变量表里一眼就能看到拼包进度。

4.3 现场怎么选：两种方案的对比与混搭

两种方式各有各的适用场景，我整理了一张对比表，方便直接在项目里定方案：

如果让我选，一律优先结束符RCV。只有遇到帧尾不固定、或者调试中发现结束符可能混在数据里，才换字符中断。还有一招混搭：用RCV正常接收，同时把超时打开，这样万一秤掉线或者发出半帧数据，RCV也会在超时后收回控制权，不会把整个通讯卡死。这个兜底机制我每次都会加，哪怕是连续输出模式也一样。

5. 重量数值是怎么从字符串里"抠"出来的：ASCII解析的全过程

5.1 先从帧里定位：用FIND/MIDR把数字段切出来

假设秤在命令应答模式返回这么一帧，实际格式以你手头那台秤的协议手册为准：

ST,GS,+000.120 kg\r\n

我们需要的是中间那个"+000.120"，也就是7个字符的数字段。先不要急着一个个数偏移量，除非你能确定帧格式永远不会变。稳妥的做法是先用FIND指令在接收到的字符串里找"GS,"这个特征子串，找到之后位置就确定了，再用MIDR指令从特征串后面截取固定长度，比如截7个字节得到"+000.120"。如果秤的帧里还有毛重/净重标志位，找特征串时也要区分清楚——想读毛重就找对应的GS标记，想读净重就找另一个标记，别拿错字段去算。

字符串指令在S7-200 SMART里都有，FIND负责查找子串位置，MIDR负责提取子串。注意第一个字符串操作数往往是"长度字节+ASCII字符"的格式，所以定义查找子串时也要先在V区把长度和字符放好。整个过程最好封装成一个解析子程序，输入是接收缓冲区首地址，输出是重量值、符号、状态位，以后换秤的协议格式，只改子程序内部就行。我这里用的"ST,GS,+"只是演示结构，不同型号的秤字段名可能不一样，但定位思路完全通用。

5.2 没有现成的ASCII转浮点指令：那就自己数位权

S7-200 SMART并没有一条"字符串转浮点"的捷径指令，ATH只是把"十六进制ASCII字符"转成字节，不能直接拿来做带小数点的十进制字符串转换。所以这个步骤必须自己写。我的做法是把数字段拆成整数部分和小数部分分别累加。

假设数字段是"+000.120"，去掉前面的正负号和中间的小数点之后，整数部分是"000"，小数部分是"120"。用一个循环扫描字符串，每遇到一个数字字符就减去16#30，得到真正的数字值；整数部分按位权累加，小数部分累加成"千分位"再除以1000。比如"120"累加成120，最后得到0.120，再和整数部分合并。符号位单独判断，遇到负号在最后取负。

这里有一个容易被带偏的细节：十六进制ASCII转整数指令处理的是0x30到0x39这种十六进制数字的ASCII，范围很有限，不要拿它来做多位数十进制转换。自己写循环虽然看着笨，但当秤返回的是6位整数、3位小数时，这个子程序就是一劳永逸的。写得通用一点，比如把小数点位置、整数位宽、小数位宽都做成参数，后面接其他品牌的秤也能复用。

5.3 单位与精度：别把kg读成了t

解析完成后，还要考虑单位换算和精度。秤返回的单位可能是kg、g，甚至t，程序里必须和工艺要求的单位一致。我遇到过项目里PLC端要做累计量，秤返回kg，但数据库要求t，直接拿原始值累加，最后报表差了三倍。正确做法是把单位统一成工艺单位，在解析子程序出口处就完成换算，后面所有逻辑都用统一单位。

另外浮点数比较要留余量。PLC浮点是单精度32位，两次运算的结果可能差0.0001，程序里判断重量是否到某个阈值时，不要用等于号硬比，用"差值绝对值小于允许误差"的方式写。解析子程序跑起来之后，先挂一段时间的变量监控表盯着VD区里的浮点数，和秤面板显示对比几分钟，确认小数位和跳变都对再往下做报警逻辑。尤其是秤在动态称重状态下数值会抖动，程序里最好做一次软件滤波，取连续几帧稳定值再输出。

6. 通讯不能只做"通"这一下：超时重试、掉线报警和几个实战坑

6.1 别让程序永远等下去：超时与通讯状态机

命令应答模式下，最忌讳的就是程序里"傻等"：发了命令之后死等接收完成，秤一直不回就直接卡死在那。自由口程序一定要有状态机思路。简单的做法是维护两个标志：允许发送、接收完成。一个周期内，如果允许发送就组帧、发命令、把允许发送清零；如果接收完成标志为1，就解析、处理、然后允许发送置1，进入下一轮。RCV的超时时间由SMW92确保，超时后接收结束，程序能继续往下走，不会因为一帧坏数据卡住整个系统。

再用一个通讯失败计数器。连续几次超时没有任何有效帧，就置掉线报警位，同时把重量值保持在一个安全值，触屏上弹"电子秤通讯故障"；恢复条件很简单，连续收到若干帧有效数据，自动清零报警位。这套机制看着基础，但在产线上能省不少半夜去现场的电话。计数器的复位逻辑也要写清楚，别出现"报警置起来容易、消掉难"的问题。

6.2 校验和与数据合法性：防乱码更要防错值

比收不到更危险的是收到一个错值还在继续用。如果秤支持校验，帧尾通常会带一个或两个校验字节。常见的BCC异或校验做法是：把数据部分的每个字节逐次异或，得到一个单字节，和帧里附带的校验值比对。接收完成之后先跑一次校验子程序，对不上就把这一帧丢弃，不计入重量数据。

别以为只有收到乱码才需要校验。现场有一次是秤的通讯板老化，偶发把某一位数据翻转，字符看起来完全正常，但重量差了几公斤。加了校验之后，这种异常帧直接被识别出来。就算秤没有校验，也至少要做合法性判断：重量值是否在传感器量程范围内、符号位是否合理、正负号是否符合工艺逻辑。数据安全这件事，宁可在程序里多写几行判断，也别太相信串口。尤其是涉及到配料配方值的场景，一帧错值就可能把整罐料配错，损失远大于那几行程序。

6.3 实测中那些最刁钻的故障：四条排查链路

最后列几条我在实际调试中踩过、也在别人项目里见过的坑。

第一，能收到数据但是全乱码。优先查口参数，波特率、数据位、校验位一定要和秤面板设置一致；查完口参数再看转换器供电，无源转换器接上PLC后带不动负载，数据会碎成一堆字节。

第二，时通时断，几分钟一次。这种情况多半不是程序问题，是物理链路问题。检查屏蔽层是否单端接地，485线是不是和动力电缆缠在一起走了同一个线槽，转换器有没有隔离。变频器一启动通讯就断的现场，差不多都是这类原因。

第三，命令模式发出后秤没反应。先别急着改PLC，用串口助手直接和秤对话，确认PC发命令能收到应答。如果PC能通而PLC不行，看XMT缓冲区长度字节对不对、命令字符的ASCII码有没有写错、通讯端口选的是Port0还是Port1。这一条排查链路能快速把问题定位到"秤的设置"还是"PLC程序"。

第四，接收不完整、帧长度飘忽不定。多半是SMB94最大字符数设小了，帧被截断；或者SMB89结束符和秤实际帧尾不一致。还有一种隐蔽情况：RCV只执行了一次，下一次接收没重新挂上，看起来就是"通一次之后再也不动"。

如果要把这套东西用到自己现场，我建议按这个顺序推进：先不开PLC程序，用一台电脑串口助手把秤的真实报文抓下来，确认模式、口参数、帧格式；然后再写自由口的收发裸框架，用变量表观察接收缓冲区和解析结果；最后才加报警、累计这些业务逻辑。每一步都有明确验证点，出了问题也知道在哪一段找，比直接堆代码、猜问题要快得多。