简介面向西门子博途1200平台学习者的MODBUS轮询程序工程资料包聚焦于工业现场多从站数据采集场景帮助初学者理解轮询机制、通信参数配置与异常处理逻辑。包内共38个文件以cfs、xml、db、plf等工程文件为主覆盖PLC程序、HMI组态及项目数据库等模块压缩包仅1.03MB便于下载后直接导入博途软件分析。已有3438人学习下载。资料重点展示了基于MB_READ/MB_WRITE指令构建轮询循环的完整思路包含从站地址映射、数据解析、错误重试等关键环节并附带项目调试所需的索引与日志文件可辅助读者对照实际工程加深理解。通过学习该程序包使用者能够快速掌握S7-1200与MODBUS设备通信的工程实现方法为后续分布式I/O、数据采集等复杂应用打下基础。 做现场改造或者设备通信调试最绕不开的就是MODBUS。尤其是在西门子的博图环境里写MODBUS轮询程序看着简单写起来一堆坑。市面上很多教程只教你拖一个MB_MASTER块读单个从站但真实项目里一条RS485总线上挂着七八个变频器、仪表你得一个一个轮着读还要考虑某个站点掉线了不能把整条总线卡死——这时候一个结构清晰的轮询程序就是项目能否稳定运行的关键。这篇内容适合正在做S7-1200/1500通讯调试的电气工程师、自动化运维人员也适合刚接触博图SCL语言、想用状态机思路解决实际通讯问题的朋友。我会从现场真实需求出发讲清楚什么是轮询、为什么必须在博图里自己写轮询逻辑、轮询表如何设计、状态机如何实现最后把调试时容易踩的坑和错误码一并整理出来希望能帮大家少走弯路。1. 项目背景为什么轮询程序是必需品1.1 一个典型的多从站采集场景先看一个我上个月处理的现场案例。客户有6台温控表、2台流量计和1台多功能电表全部是MODBUS RTU协议挂在同一条RS485总线上接到S7-1200的CM1241 RS485通信模块。需求很简单PLC每秒钟采集一次所有仪表的数据然后在触摸屏上显示。刚开始我确实走了弯路。熟悉博图的朋友知道MB_MASTER指令一次只能发一个请求也就是说一次调用只能指定一个从站地址、一个功能码、一个数据区。我最初的做法是复制了9个MB_MASTER实例每个读取一台设备心想这样总可以了吧。结果一跑就出问题——两条MB_MASTER的REQ如果几乎同时触发总线上会产生报文交错轻则通讯超时重则从站直接拒绝响应。这就是轮询程序存在的根本原因RS485半双工总线上同一时刻只能有一个请求在传输。多主站同时发报文的场景在MODBUS总线协议里是不被允许的。1.2 轮询的本质总线是单车道我经常跟同事打比方MODBUS总线就像一条单车道所有从站共用一个通道。轮询程序就是站在路口的交通调度员每次只放一辆车过去等这辆车完全通过、得到结果之后再放下一个。如果调度员一次性把所有车都放进去整条路就堵死了。具体到博图的MB_MASTER指令它的REQ输入端是上升沿触发的而且必须一直保持为TRUE直到DONE或ERROR标志返回。这个过程中总线上只能存在这一个请求。所以我们的核心任务就是写一个调度器保证同时只有一个请求在执行并且在请求完成或失败之后自动切换到下一个从站或下一个数据区。1.3 为什么不能用多个MB_MASTER直接堆很多人会问我在博图里复制多个MB_MASTER每个用不同的触发条件轮流激活行不行理论上可以但工程上不推荐。原因是每个MB_MASTER实例占用的资源、维护的背景数据块数量多程序结构混乱后面想增加设备、调整轮询顺序改动起来相当痛苦。更关键的风险在于多个MB_MASTER实例如果分散在不同FC/FB中执行顺序和触发时机很难严格控制。一旦两个实例在同一扫描周期内被置位总线报文就冲突了。用轮询表加状态机的方式所有请求统一管理无论后面挂10个站还是50个站代码逻辑完全不用改只需要把轮询表的数据填好就行。2. 博图中的MODBUS指令家族与小坑预警2.1 核心指令MB_COMMON_LOAD、MB_MASTER、MB_SLAVE在博图V14以后的版本里MODBUS指令已经集成到指令树的“通信 通信处理器 MODBUS”下面不需要再额外挂库。其中最常用的三个指令MB_COMMON_LOAD通信参数加载指令。在调用MB_MASTER之前必须先用它初始化串口参数一次初始化即可。MB_MASTER主站请求指令。负责发送读取或写入请求是轮询程序的核心执行单元。MB_SLAVE从站响应指令。如果PLC是被别的上位机轮询才需要用到单纯做主站时用不到。MB_MASTER的输入输出参数比较多这里挑关键的几个说一下。REQ是请求触发端上升沿有效MB_ADDR是从站地址MODE是功能模式0表示读1表示写DATA_ADDR是从站的起始寄存器地址DATA_LEN是数据长度单位为字DATA_PTR是本地数据区的指针用来存放读到的数据或待写入的数据。DONE、BUSY、ERROR、STATUS这四个输出是轮询程序里必须盯紧的它们共同反映当前请求的完成状态。2.2 RTU与TCP的差别如果项目走的是MODBUS TCP而非RTU博图里的指令会换成MB_CLIENT参数整体上类似但有个重要差别TCP协议本身是全双工的物理层不冲突可以支持多个客户端并发连接。不过从业务逻辑上看我们依然建议用轮询思想管理MB_CLIENT的请求因为PLC的数据处理能力有限同一时刻处理太多并发请求会让程序逻辑变得不可控而且很多仪表服务器的处理能力并不强并发反而降低吞吐量。我见过一个兄弟直接用10个MB_CLIENT同时轮询10个从站结果TCP连接频繁断开最后只能回到顺序轮询方案。MB_CLIENT的MODE参数跟MB_MASTER略有不同TCP模式下MODE更细分1代表读保持寄存器2代表读输入寄存器3到6是不同写模式具体要查一下对应版本的帮助文档。2.3 调用前提MB_COMMON_LOAD必须先执行还有一个高频坑很多新手写完程序不调用MB_COMMON_LOADMB_MASTER直接报错。MB_COMMON_LOAD的作用是配置串口的波特率、校验方式、超时时间并且为MB_MASTER分配背景数据块。不初始化就用MB_MASTERSTATUS大概率返回一个初始化错误码。MB_COMMON_LOAD的关键参数包括PORT是串口硬件标识符需要从PLC组态的“系统常量”里查直接在程序里写数字很容易弄错BAUD是波特率常见9600或19200必须与所有从站保持一致PARITY是校验方式最常用的是偶校验2也有不少设备是无校验0这个必须和设备手册核对TIMEOUT是超时时间单位毫秒这个参数直接决定掉线从站会卡多久建议按从站数量调整我会在后面的调试小节细说。3. 轮询程序的整体架构设计3.1 轮询表把要读的数据配置化轮询程序的第一步不是写代码而是建立一个“轮询表”。轮询表本质是一个数组数组的每一项描述一个请求包含四个核心字段从站地址、功能读/写、从站寄存器地址、数据长度。为什么要用数组而不用固定的程序段因为项目里的从站数量、寄存器地址经常会变。今天要读这6台温控表明天可能要加1台流量计用轮询表的话只需要在数据块里加一行数组元素程序逻辑一行都不用改。我习惯于在PLC数据类型里自定义一个UDT结构如下TYPE PollItem STRUCT SlaveAddr : Int; // 从站地址 Mode : Int; // 通讯模式0读, 1写 DataAddr : Int; // 从站寄存器起始地址 DataLen : Int; // 数据长度字 END_STRUCT END_TYPE在全局数据块里定义一个轮询表数组比如POLL_TABLE : ARRAY[0..19] OF PollItem这样最多支持20个请求项实际项目绰绰有余。在实际编程时可以根据设备规模适当扩大数组边界。同时还应该预留一个变量来记录当前轮询的步骤序号以及一个从站在线标志数组后续做故障诊断要用到。3.2 状态机调度一次只走一辆车轮询调度的核心是一个简单的两态状态机空闲态和执行态。空闲态STATE0从轮询表里取出当前步骤对应的请求参数赋值给MB_MASTER的输入然后将REQ置为TRUE产生上升沿触发请求同时切换到执行态。执行态STATE1等待MB_MASTER的DONE或ERROR输出变TRUE。只要两者都没变程序就一直保持当前状态不变。一旦DONE或者ERROR返回先把REQ复位为FALSE以便下一次产生新的上升沿然后更新故障计数和在线状态把步骤序号切换到下一项最后回到空闲态。这个状态机虽然简单但有一个地方非常容易写错REQ不能保持常TRUE。如果REQ一直是TRUEMB_MASTER只会在第一次产生上升沿时触发一次后续不会持续请求。所以必须在收到DONE或ERROR之后先把REQ复位下次进入空闲态再置位这样才有了新的上升沿。这也是很多初学者写轮询程序卡壳最多的地方。3.3 超时、掉线、错误重试策略轮询程序里最怕的不是通讯正常的时候而是某个从站掉线。如果从站不响应MB_MASTER会一直挂起直到MB_COMMON_LOAD里设置的TIMEOUT超时后才返回ERROR。这个超时时间如果设置不当一个掉线站就会让整个轮询循环停顿几秒钟。我的经验是RTU模式下超时时间建议设置为300到500毫秒不要超过1秒。假设总线上有8个站如果其中1个站掉线其他7个正常站每个也就二三十毫秒完成一个循环总耗时大约1秒左右掉线站会拖慢大约400毫秒整体还可接受。如果超时时间设成3秒一个站掉线之后整个循环被拖慢3秒多触摸屏上的数据刷新率会变得肉眼可见地差。另外错误重试不宜太频繁。对于掉线的从站应该让它在下一轮重新轮询而不是在当前轮内连续重试。因为连续重试会占掉整个总线很长一段时间导致正常站的数据也无法更新。我通常的做法是连续3次失败就在HMI上显示“从站离线”但程序仍然继续往下轮询不会让某个故障站“绑架”总线。4. 实操在博图里一步步搭建轮询逻辑4.1 新建工程、组态串口与添加指令块以S7-1200搭配CM1241 RS485模块为例。新建博图项目后先组态设备然后在网络视图里把CM1241模块拖到CPU右侧的机架上PLC会自动分配硬件标识符。接着打开“PLC数据类型”按上面的方式创建一个名为PollItem的UDT。再建立一个全局数据块DB_Poll在里面定义轮询表数组POLL_TABLE以及当前步骤序号StepIdx、当前状态PollState、故障计数器FaultCnt、最近错误码LastError、通信标志数组OnlineFlag等变量。注意从站在线标志数组的大小最好跟轮询表数组一致。在OB1里首先要调用一次MB_COMMON_LOAD对串口进行初始化。这个指令只需要执行一次所以我通常放在OB100启动组织块里或者用首个扫描周期标志位包起来避免每个周期重复加载。MB_COMMON_LOAD的MB_DB输出要连接到MB_MASTER指令的背景数据块上这里用同一个DB即可。4.2 用SCL实现轮询调度器下面是我在项目里实际使用的SCL轮询调度逻辑精简了业务部分保留了核心框架。这个逻辑放在一个FB里调用情况是每次扫描周期都调用一次MB_MASTER的REQ、MB_ADDR等输入输出都连接到FB的静态变量或IN_OUT变量上。// 轮询调度状态机示例 CASE #PollState OF 0: // 空闲状态装载当前轮询项 #Item : #POLL_TABLE[#StepIdx]; // 读取当前步骤配置 #MB_REQ : TRUE; // 请求置位准备触发 #MB_ADDR : #Item.SlaveAddr; // 从站地址 #MB_MODE : #Item.Mode; // 读/写模式 #MB_DATA_ADDR : #Item.DataAddr; // 从站寄存器地址 #MB_DATA_LEN : #Item.DataLen; // 数据长度 #PollState : 1; // 切换到执行态 1: // 执行状态等待MB_MASTER完成 IF #MB_DONE OR #MB_ERROR THEN #MB_REQ : FALSE; // 必须先复位请求确保下次上升沿 IF #MB_ERROR THEN // 错误处理 #FaultCnt : #FaultCnt 1; #LastError : #MB_STATUS; #OnlineFlag[#StepIdx] : FALSE; ELSE // 读取成功 #FaultCnt : 0; #OnlineFlag[#StepIdx] : TRUE; END_IF; // 切换到下一个轮询项 IF #StepIdx #POLL_TABLE_MAX - 1 THEN #StepIdx : 0; ELSE #StepIdx : #StepIdx 1; END_IF; #PollState : 0; // 回到空闲状态 END_IF; END_CASE;这段代码的要点在于所有MB_MASTER输入参数都必须在REQ置位之前赋值确保上升沿到来时PLC已经拿到完整的请求参数。同时需要注意MB_MASTER的调用本身还需要把DONE、ERROR、STATUS、BUSY这些输出引到FB的静态变量上上面代码里的#MB_DONE、#MB_ERROR、#MB_STATUS就是从MB_MASTER输出端带回来的。4.3 DATA_PTR指针与数据区映射MB_MASTER的DATA_PTR参数指的是存放读写数据的数据区。博图V14以后的MB_MASTERDATA_PTR是VARIANT类型可以直接指向一个全局数据块里的数组或结构体成员。比如我在DB_Poll里定义一个数据缓冲区BUFFER : ARRAY[0..63] OF WORD读写数据都在这块区域里操作然后在调用MB_MASTER时把DATA_PTR : DB_Poll.BUFFER[0]即可。有一个细节要提醒不同从站返回的数据长度不一样读回来的数据在缓冲区里的位置要注意覆盖问题。我习惯为每个轮询项独享一小段缓冲区而不是所有轮询项共用BUFFER的首地址否则前一个从站的数据还没来得及存储就被后一个从站覆盖了。更优雅的做法是在轮询表UDT里增加一个指针偏移字段比如DataPtrOffset然后在SCL里用PEEK或者直接通过偏移量访问缓冲区的指定位置。这样数据搬运到HMI变量或中间变量时逻辑非常清晰。4.4 写操作与浮点数转换如果轮询项是写操作流程稍有不同。写操作前需要先把目标数据搬运到缓冲区里然后再触发MB_MASTER。比如要写入变频器的运行频率先把频率值写入BUFFER对应的字再将轮询项的Mode置为1触发写请求。我通常在SCL里用一个功能块专门管理这个流程先把HMI传来的浮点数数值绑定到缓冲区然后置位写触发标志状态机空闲后会自动执行该写请求。写操作之后经常遇到的问题就是浮点数转换。MODBUS寄存器是16位的一个32位浮点数占用两个寄存器。大部分仪表按大端模式存储高16位在前低16位在后。在博图SCL里先把两个Word拼成一个DWord再用DWORD_TO_REAL指令转换位模式就能还原出浮点数。拼DWord的代码如下#dwordValue : SHL(INT_TO_DWORD(#regHigh), 16) OR INT_TO_DWORD(#regLow); #realValue : DWORD_TO_REAL(#dwordValue);这个转换在我调试电表和流量计时经常用到建议直接做成一个可复用的FC传入两个Word返回一个Real无论哪个项目都能用。另外不同厂家的仪表有的默认低字在前调试时如果发现数据明显不合理比如温度变成几十万可以先把高低字对调再转换往往会豁然开朗。5. 常见坑位与排查技巧5.1 BUSY一直为TRUE程序卡死不动这是轮询程序最典型的故障。MB_MASTER的BUSY输出一旦变成TRUE说明请求已经在总线上发送程序必须等DONE或ERROR返回才能继续。忙标志卡住不释放最常见的原因是从站掉线后超时时间设置太长导致MB_MASTER一直处于挂起状态。排查时先看MB_COMMON_LOAD里的TIMEOUT参数把超时时间缩短到300毫秒左右问题会明显缓解。另外还有一个隐蔽原因多个MB_MASTER实例的REQ同时为TRUE。因为每个从站的请求都在等待DONE返回两个请求同时激活时报文会被第二个请求打断从站根本无法正确响应导致第一个请求永远等不到DONE。排查时可以监控所有MB_MASTER的REQ确保同一时刻只有一个是TRUE。5.2 STATUS错误码看不懂MB_MASTER的STATUS输出会返回一个错误码常见的有这么几个我整理成了速查表STATUS含义排查方向16#8200通讯成功无16#8180从站无响应检查从站地址、波特率、线路16#8181报文校验错误检查从站地址、功能码16#8182功能码无效确认从站支持该功能码16#8183数据地址超范围核对寄存器地址是否超出从站范围16#8184数据长度非法核对读取长度是否越界16#8185CRC校验错误线路干扰、从站波特率不匹配在实际调试中我遇到最多的是16#8180和16#8185。出现16#8180时先用串口调试助手直连从站确认从站地址对不对、波特率校验方式是否匹配。出现16#8185时优先检查RS485的A/B线是否接反、终端电阻是否安装、屏蔽层是否单端接地。5.3 从站掉线后恢复数据更新不及时有次我在调试中遇到过一个问题某个从站断电再上电后虽然通讯恢复了但触摸屏上的数据一直不更新。排查到最后发现是轮询状态机卡在了错误处理分支里——从站掉线后MB_MASTER返回ERROR程序一直停在执行态等待DONE而正常站的请求根本没有机会发出。解决办法其实很简单在收到ERROR后不仅要把REQ复位还要立即把状态切回空闲态让轮询循环继续跑不要卡在错误分支里。同时维护一个在线标志数组如果当前步骤失败但从站地址与上一个成功步骤一致可以允许重试一次。这类逻辑加上之后从站恢复上电后最多一个轮询周期就能重新采集到数据。5.4 博图版本差异与兼容性最后提一句博图版本的问题。MODBUS指令从V13 SP1开始就有V14以后集成到指令树默认位置。V16、V17、V18乃至最新的V20/V21MB_MASTER的接口参数基本上没有大的改动轮询程序的代码可以直接复用。只是新版本创建项目时PLC固件版本和指令版本要匹配比如S7-1200固件4.0以上才支持VARIANT类型的DATA_PTR指针如果选老固件可能要用ANY指针写法代码会复杂一截。所以建项目时PLC固件版本尽量选新一些后面写程序会少很多限制。6. 调试中的一点个人心得做MODBUS轮询这件事我最大的体会是程序写得再漂亮不如先想清楚从站有多少个、数据怎么分布、故障怎么隔离。很多项目的通讯问题并不是程序逻辑问题而是硬件接线、从站参数和超时时间没协调好。建议大家在写轮询表之前先拿一张纸把所有从站的地址、要读的寄存器区间、数据长度列出来再在纸上画一遍状态机的流转过程然后再开博图动手。再分享一个小技巧调试轮询程序时至少在PLC里留一个诊断变量把当前步骤序号和最近一次STATUS错误码放到HMI上。这样现场设备出问题时运维人员一眼就能看出当前轮询到哪一步、卡在哪个从站上不用每次跑到触摸屏后面拿电脑排查。这个习惯帮我省了无数次现场奔波的功夫强烈推荐大家都加上。本文还有配套的精品资源点击获取