企业官网建设流程全解析

直接上结论：西门子触摸屏做IO变量动态显示，核心不在触摸屏侧，而在PLC侧的DB块和FC块怎么设计。这套方案我在现场用过很多次，从S7-1200配KTP系列，到S7-1500配精智面板，思路完全通用。标题说5分钟搞定，指的是理清思路之后，真正组态确实用不了多少时间，但前提是DB块和FC块的结构必须设计对，否则后面动辄返工。

很多工程师习惯把IO变量直接拖进触摸屏做一个布尔指示灯，一个电机手自动状态做两三个画面对象，十几台设备下来光画面就几百个对象，改一个点要找半天。用DB块集中映射、用FC块做统一状态转换，画面侧只面对一个结构清晰的变量表，维护成本直接降一个量级。这篇文章不废话，直接讲怎么从零构思这套方案，包括DB块怎么建、FC块怎么处理数据、触摸屏变量表怎么连接，附带现场踩过的坑。

1. 为什么IO点不能在触摸屏上直接映射：背后的问题拆解

先说一个最基本的认知。触摸屏的IO域、指示灯、位状态显示，都可以直接绑定PLC的I点和Q点，地址填I0.0、Q0.5这种，编译下载后它也能动。但这样做只是在做“显示”，做不了“监控”，更做不了“动态”。区别在哪里，我拆开讲。

1.1 直接映射的三个硬伤

第一个硬伤是地址分散导致的数据采集效率问题。触摸屏和PLC通信时，是按数据块来读写的。如果你画面上有30个指示灯，分别绑了I0.0、I0.3、I1.2、Q0.1、M10.0、DB1.DBX0.0，触摸屏为了拿到这30个点，需要发起多次通信请求。西门子触摸屏的单次报文请求虽然可以连续读取一块区域，但这些点不在连续区域时，只能拆成多次请求。设备一多、点一多，通信负载直线上升，画面刷新速度肉眼可见地变慢。

第二个硬伤是点位变更牵一发动全身。今天I0.0接的是1号电机运行反馈，明天改图纸换成I0.4，你得去触摸屏画面里找到那个绑定I0.0的指示灯，改地址。如果这个状态还被报警记录、趋势图引用，你要改的地方更多。现场调试高峰期，这类改动最浪费工时。

第三个硬伤是缺少统一的状态处理机制。实际的IO信号，尤其传感器信号，直接拿来用会带很多毛刺。比如接近开关的抖动、光电传感器的瞬时误动作，直接映射到画面上就是指示灯闪烁、计数跳变。这些东西需要滤波、去抖、取反、置位保持等处理，直接映射等于把原始信号完全暴露给操作工，这不是监控，这是添乱。

1.2 动态显示的本质需求

“动态显示”这个词在不同人口中含义不同。有人理解成电机运行时显示绿色，停止显示灰色，这是“状态显示”。有人理解成数值实时变化，温度、压力、流量不断刷新，这是“数值显示”。也有人理解成画面对象根据条件自动改变外观，比如设备故障时按钮变红闪烁、未就绪时按钮灰化不可操作，这是“动态交互”。

西门子触摸屏把这三种需求都归入“动画”功能的范畴。动画可以控制对象的可见性、颜色闪烁、文本列表、图形列表，而这些动画的触发条件，都可以绑定到一个整型变量或布尔变量上。这就有意思了——你不需要在触摸屏上放几十个独立指示灯，只需要把设备的运行状态、故障状态、待机状态整合成一个或几个状态字，画面上的一个图形对象根据状态字的不同值显示不同颜色/文本/图形，一个对象替代原来五六个对象。

这就是DB块和FC块在这套方案里的价值：PLC侧先把原始IO处理成有业务含义的状态信息，集中存放在专用的DB块里，触摸屏只负责消费这些整理好的数据，显示逻辑简单，数据来源可靠，通信次数大幅减少。

2. DB块结构设计：映射区、保持区、状态区三分天下，通讯只走数据块

DB块是整个方案的地基。建得不合理，后面FC块写得再漂亮都白搭。我建议对IO变量监控场景，DB块按三个功能区来组织：IO映射区、中间暂存区、状态输出区。

2.1 IO映射区：把散落的点集中成连续块

IO映射区做的事情很简单：在DB块里按固定顺序定义变量，FB/FC里把物理I/O点的状态批量搬运进来。

举个实际例子。假设你的设备有16个数字量输入、8个数字量输出、4路模拟量输入，映射区可以这样定义：

有人会觉得，直接从I点读不行吗，为什么要先搬运进DB？因为只有搬运进来，才能让触摸屏只面对一个DB块连续读取。S7-1200/1500的触摸屏通信，对DB块的连续数据读取效率远高于零散点位读取，尤其是你做了优化块访问属性之后，直接按数组访问非常快。

数组下标和设备编号一一对应，是工程上最容易查错的方式。比如1号电机运行反馈是DI_Raw[0]，3号电机过载信号是DI_Raw[2]。现场查线时，拿万用表量完信号，打开DB块看一眼对应下标就知道触摸屏上有没有显示，不用再拿图纸找符号名。

2.2 状态输出区：触摸屏真正消费的数据

状态输出区是给触摸屏看的，也是整个DB块里最重要的部分。这里的变量定义要贴近业务语义，不贴近硬件地址。

例如1号电机，状态区可以定义：

MOTOR_1_RUN : Bool // 运行反馈，已经过滤波和取反处理 MOTOR_1_FAULT : Bool // 综合故障，来自过载/变频器故障/急停 MOTOR_1_MODE : Int // 0-待机 1-运行 2-故障 3-检修

定义成这种结构，触摸屏上的指示灯、按钮、报警文本都可以直接绑变量。尤其MOTOR_1_MODE这种整型状态字，配合画面对象的“文本列表”或“图形列表”，一个图形对象就能按不同取值显示不同颜色、不同文字，效果等于四五个独立对象。

有人问为什么不用Bool直接用，要搞一个Int状态字？因为状态字在触摸屏上做动画太方便了。西门子触摸屏的动画组态里，可以针对整数变量设置多个状态/范围的颜色和可见性，一个圆角矩形就能把待机（灰）、运行（绿）、故障（红）、检修（黄）全部表现出来。如果你拆成三个Bool，在画面上就要叠加三层半透明对象分别控制可见性，组态工作量直接翻倍。

2.3 优化块访问的坑与DB块偏移量对齐

S7-1200/1500的DB块在属性里可以勾选“优化块访问”。勾选后，PLC侧不用管偏移量，符号名直接访问，非常方便。但这也带来两个现场容易踩的坑。

第一个坑是老版本触摸屏软件对优化块访问支持不完善。博途TIA Portal V13及更早版本，部分触摸屏型号无法直接访问优化访问的DB块变量，必须在DB块属性里把“优化块访问”去掉，改成标准访问，然后手动管理和核对偏移量。新版本V15/V16以及精智面板基本没问题，但如果现场还有老面板，建议直接建标准访问DB，省得后面下载时发现变量连不上。

第二个坑是字节对齐。手动管理偏移量时，Bool和Bool之间是紧凑排列的，但Bool和Int之间会有填充字节，Int和Real之间也有对齐规则。比如一个FB接口里先放一个Bool再放一个Int，如果手动偏移量排错了，触摸屏读出来的数据就是错位的。最简单的做法是：建标准访问DB后，用“偏移量自动建议”功能，让博途自己排，排完截图留底。千万别手动调偏移量，博途的自动建议基本是按最优对齐排的。

3. FC块处理逻辑：为什么用FC而不是FB，还有中间变量的循环扫描问题

把原始IO搬进DB映射区，在映射区基础上做滤波、取反、边界检测，最后输出到状态区，这是一整套逻辑。实现这套逻辑，可以用FC，也可以用FB。我的选择是FC为主、FB辅助，理由后面讲。

3.1 为什么用FC：无背景数据块，调用灵活，不占实例DB

FC全称是Function，功能块，没有自己的背景数据块。FB全称是Function Block，函数块，每次调用都要分配一个背景DB来保存实例数据。

对于IO变量动态显示这个场景，大部分逻辑是“读一个输入、做处理、写一个输出”，不涉及复杂的内部状态保持。这种情况下用FC更轻，不需要为每一个设备建一个背景DB，直接传参数就行，调用几次都行。FC的临时变量在每次扫描周期结束后会被释放，因此它天然适合做纯组合逻辑。

反过来，如果要做带累计功能的逻辑，比如设备运行时间累计、故障次数统计，那就得用FB了，因为FB的背景DB能保存上次扫描的中间值。这是FC和FB一个核心区别：FC的临时变量不能跨扫描周期保持，FB的静态变量可以。你写FC时如果在临时变量里存了一个值，指望下个周期还在，那是想多了，一定丢。

3.2 经典设备状态处理FC：以电机为例

下面是一个标准的电机状态处理FC逻辑。输入参数是原始IO映射区的几个Bool，输出是状态输出区的Bool和Int。

FC的接口我建议这样定义：

• 输入：Raw_Run（原始运行反馈）、Raw_Fault（原始故障输入）、Filter_Time（滤波时间，单位ms）
• 输出：Run_Out（处理后的运行状态）、Fault_Out（处理后的故障状态）、State_Mode（0/1/2/3状态字）

FC内部逻辑分三步：

第一步：输入滤波。反馈信号如果是一个接近开关或者继电器触点，在吸合瞬间有抖动，直接取Bool会看到画面上指示灯闪烁。滤波逻辑可以这样写：在OB1里做周期轮询（比如每10ms调用一次FC），用定时器或者简单计数法。计数法思路是：输入为1时计数器加1，输入为0时计数器清零，计数超过设定阈值才认为信号稳定为1。阈值乘以轮询周期就是滤波时间。

第二步：故障合成。把过载信号、变频器故障信号、断路器跳闸信号做或运算，得到综合故障。注意这里要考虑常开常闭逻辑，急停按钮通常接常闭触点，PLC侧读到的信号和实际逻辑正好相反，需要取反后再参与合成。如果直接在FC里做取反，务必在接口注释里写明白这是常闭逻辑，不然调试完三个月后你自己回来看代码都会懵。

第三步：状态字生成。根据处理后的运行反馈和故障合成结果，生成状态字：

• 故障为真，状态字=2
• 运行反馈为真且无故障，状态字=1
• 运行反馈为假且无故障，状态字=0
• 检修模式开关投入时，状态字=3

这个状态字直接写入DB状态输出区，触摸屏画面上的图形对象就用它做动画控制。

3.3 模拟量处理的额外要求

模拟量变量除了搬运，还要做工程量转换。4-20mA电流环信号读进来是0~27648，要显示成实际温度、压力，就得用FC做线性变换。

转换公式很简单：

工程量 = (原始值 - 量程下限原始值) / (量程上限原始值 - 量程下限原始值) * (工程量上限 - 工程量下限) + 工程量下限

对于4-20mA信号，量程下限原始值对应5530（即4mA对应的数字量），量程上限原始值对应27648（20mA）。

这个公式建议封装成FC_Scale，输入原始值、工程量上下限、原始值上下限，输出工程量。封装的好处是现场仪表量程变化时，只需要改DB里的量程参数，不用动FC代码。还有一个细节：很多PLC的模拟量通道在断线时采样值会跳到32767，转出来的工程量是超大值。在FC里要做超限判断，一旦原始值接近满量程且持续超过一定时间，直接把工程量输出为对应报警值，同时置一个通道故障位。否则操作工看到画面上温度显示一千多度，先吓个半死，然后才查出来是热电偶断线。

4. 触摸屏侧组态：变量表、连接机制和画面动画设置

PLC侧数据准备好了，触摸屏侧反而简单。核心分三步：建立通信连接、批量创建变量、画面动画绑定。这里面细节不少，每一步都有坑。

4.1 通信连接的版本匹配问题

西门子触摸屏和PLC通信，最常用的是集成在博途里的S7协议连接。建立一个S7连接时，需要选择连接类型，比如S7-1200、S7-1500或S7-300/400。这里有个经验：连接类型要选对，否则变量访问不了。S7-1200/1500要用“S7-1500”连接类型，S7-300/400用“S7-300/400”连接类型。选错了，测试连接可能显示正常，但变量表一个值都刷不出来。

还有一个常见报错是“找不到地址”或“无法访问DB块”。这基本就是之前说的优化块访问问题。在触摸屏变量的属性里，DB号必须和PLC侧一致，如果PLC侧勾了优化访问且触摸屏软件版本不支持，这里就访问不了。处理办法有两个：一是PLC侧取消优化块访问并重新编译下载，二是把触摸屏变量改成符号访问方式（新版本支持）。我习惯用第一种，因为标准访问的调试可见性更强。

4.2 批量创建变量的省力技巧

根目录下手动一个一个建变量是体力活，尤其几十个电机、几百个变量的时候。博途里触摸屏变量表支持从PLC变量直接拖拽，也可以从Excel复制粘贴。我常用的做法是：

先在Excel里把变量名列出来，格式和触摸屏变量表的“名称”列对应，然后在博途变量表里直接粘贴。数据类型的列也可以一起粘贴，但要注意博途默认的布尔类型写法是“Bool”，不是“BOOL”，粘贴之前统一大小写。

变量名建议和PLC侧DB变量名保持完全一致，比如MOTOR_1_MODE。这样触摸屏画面组态时，打字有自动补全，不会拼错。更重要的是后续调试时，PLC程序里看变量名、触摸屏里看变量名，即使用WinCC Online Trend或者数据记录功能排查，也能一眼对上号。

4.3 画面对象动态显示的三层动画设置

触摸屏画面上实现动态显示，核心是“动画”功能。不同系列面板菜单位置有差异，但逻辑是一样的：

第一层：外观动画。选中一个图形对象（比如圆角矩形），在属性里找到“动画”→“外观”。添加一个基于整型变量的外观动画，当变量值等于0、1、2、3时，分别设置不同背景色。变量选MOTOR_1_MODE，0灰、1绿、2红、3黄。这样一个对象就把四种状态都显示出来了。

第二层：可见性动画。如果你需要在故障时额外弹出一个感叹号图标或故障文字块，就用到可见性动画。给这个图标添加“可见性”动画，变量指向MOTOR_1_FAULT，条件设为“值为1时可见”。这样正常运行时图标隐藏，故障时自动出现，不需要脚本。

第三层：闪烁动画。报警状态一般要求闪烁，博途的闪烁频率在画面属性里可以设置。对故障颜色块添加“闪烁”动画，条件同样是MOTOR_1_FAULT为1。这里有个经验：闪烁频率不要设太快，默认1秒左右比较合适，太快了操作工会看花眼，太慢了没有紧迫感。我一般把重要故障设成快闪（0.5s左右），一般提示设成慢闪（1.5s左右），视觉层级很清晰。

4.4 I/O域做动态显示的补充思路

除了指示灯，数值型变量的动态显示一般用I/O域。I/O域绑定AI_Value[0]后，显示格式可以设置小数位数、单位，还可以设置“无输入时显示”的字符串。比如通道断线时工程量输出了一个极大值，FC里除了输出工程量，还可以输出一个通道状态Bool。I/O域用“可见性”动画绑定通道状态Bool，断线时隐藏I/O域，同时显示一个“断线”文本，这个思路非常实用。

I/O域还有一个容易被忽略的“数据格式”设置。如果绑定的是Int类型变量，显示格式选十进制；如果绑定的是二进制位串重组的值，选十六进制。有时候操作工反馈说某个温度显示负值，一看是格式选错了，把无符号显示成了带符号。这也是组态时容易踩的细节。

5. 现场调试踩坑实录：数据一致性、刷新率设置和离线模拟的误区

按前面的思路把PLC程序和触摸屏组态都做完，并不代表一切顺利。现场调试时问题不少，挑几个典型说。

5.1 DB块数据一致性：通信中间状态引发的显示跳变

触摸屏读PLC的DB块，不是一瞬间完成的。以S7协议为例，一次读取会把连续地址区间打包成请求，但变量的长度、地址偏移、总数都会影响分帧。如果某个电机运行状态Bool和对应状态字Int在DB块里跨了字节边界，可能某一帧读到的是旧状态，下一帧才读到新状态。这会导致画面闪烁一下：先看到绿色（旧状态），马上变红色（新状态），实际上是PLC数据已经改了，但触摸屏缓存里读到的还是上一帧。

解决办法有两个层面：

一是PLC侧做“数据一致性区”。如果你用S7-1500，可以在DB块里把关键状态数据集中放在一起，利用一致性数据块属性（‘非优化访问’下有个“在RUN/STOP模式下保持”不相关，真正关键字是‘与用户数据保持一致’）。但更通用、更简单的方法是：把状态字和关键Bool放在一个字（16位）里，用Coil或Move一次更新整个字。触摸屏读这个字时是原子操作，永远不会读到一半的状态。

二是触摸屏侧调整“采集周期”。在变量表里，每个变量都有采集周期属性，默认可能设为1秒。对关键状态变量，把采集周期改成100ms或者更短。这样即使某帧读到旧值，下一帧马上刷新回来，肉眼基本无感。

5.2 刷新率设置：不是越快越好

有人以为触摸屏变量采集周期设得越短，画面刷新越快，越好。这是个误区。采集周期太短，PLC通信负载会飙升，尤其触摸屏变量表里几百个变量全设成100ms，CPU的通信负载可能到20%以上，还会影响PLC程序扫描周期，得不偿失。

我的经验做法：

• 状态字、运行反馈、故障位：设100ms~250ms，人眼能感觉到的动态变化主要靠这些
• 模拟量数值：设500ms~1s，温度压力变化没那么快，1秒刷新完全够
• 累计量、趋势记录：设1s以上，趋势记录本身有压缩机制

真实项目里，100个变量全部按这个策略设置后，触摸屏通信负载通常能控制在10%以内。比起一上来全部用默认值，这个细心设置能避免后期运行卡顿。

5.3 离线模拟的局限性

在博途里做仿真模拟时，很多人会遇到一个情况：变量连不上PLC，画面一片空白。这是正常的，因为离线模拟时并没有真实的PLC数据源。如果你想验证画面动态显示效果，有两个办法：

一是用博途“仿真表”功能，手动给变量赋不同状态字，观察画面对象颜色变化。这个适合验证组态逻辑是否正确，比如状态字设为2，画面是否显示红色。

二是用PLCSIM模拟PLC程序，把触摸屏仿真连接到PLCSIM上。这个需要装PLCSIM Advanced（针对S7-1500）或者用普通PLCSIM配合WinCC RT仿真，联调步骤比较繁琐，但能验证PLC程序和触摸屏组态的联动。我的建议是：先做静态仿真确认画面动画逻辑，再做联调确认通信链路，最后现场带真实信号跑。

5.4 在线监控的调试利器：变量监控表

最后分享一个调试时很高效的做法。在PLC程序侧建一个监控表，把所有DB状态输出区变量拖进去，按状态字排序。现场调试时，一边看监控表里的状态字变化，一边给传感器信号，就能快速判断是PLC侧处理问题还是触摸屏显示问题。

有一次现场遇到一台电机明明在转，触摸屏上却显示待机灰色。我没有直接去翻画面组态，而是先看PLC监控表，发现MOTOR_1_MODE值确实是0，再追到映射区看DI_Raw[0]，值也是0，但用万用表量PLC输入端，信号是有的。最后发现是输入通道的公共端接线松了，传感器信号根本进不了PLC。整个过程不到五分钟，如果一开始就去摸屏侧排查，可能要多花一个小时。

这个排查顺序我建议每个做自动化调试的工程师都养成习惯：先确认PLC侧数据对不对，再查触摸屏显示逻辑，最后才怀疑通信链路。数据源头对了，很多显示问题根本不成立。

6. 从单台设备到整线系统：变量命名规范和功能块的复用思路

如果只是给一两台设备做监控，前面五节的方案已经够用。实际项目往往是十几台甚至几十台设备，每台设备有电机、气缸、传感器、温控仪表，按同样套路反复做，工作量很大。这里讲讲怎么从“能用”升级到“好维护、可复用”。

6.1 命名规范：从第一天就强迫自己遵守

命名规范决定了一个PLC程序半年后还有人敢改不敢改。我常用的设备级变量命名格式：

设备简称_部件_信号类型_业务含义 示例： M1_MOT_FB_RUN // 1号电机运行反馈 M1_MOT_CMD_START // 1号电机启动命令 M1_VAL_FB_OPEN // 1号阀开到位反馈 M1_TEMP_PV // 1号温控表过程值

DB块里数组元素的注释，写清对应设备位号；触摸屏画面上的每个对象，在属性栏的“名称”里也写明白对应的变量名。工程后期做设备交接时，这份命名规范比一份两百页的说明书更实用。

6.2 FC块的复用：把设备状态处理做成通用模版

前面说了电机状态处理FC的写法，实际项目中可以把它做成一个通用FC_Pump或者FC_Motor，通过接口参数传入不同设备的原始信号地址和滤波时间。但这里有个限制：FC的输入参数是传值的，不能传“地址”本身，所以如果想一次调用处理多台电机，就要把DB块里的数组元素整个传进去，或者分多次调用。

更优雅的方案是使用FB，定义一个FB_DeviceStatus，静态变量保存设备的内部状态，接口传入映射区数组的下标索引。然后在一个DB里声明多个FB实例，每个实例监控一台设备。这样做的好处是，程序结构非常清晰：实例DB里直接能看到每台设备的状态字、滤波计数器、故障存储，而且新增一台设备只需要在DB里多声明一个实例，不用新建任何代码。

6.3 设备状态字的扩展应用

状态字一旦统一成0/1/2/3这种标准模式，可以很方便地推广到报警记录、报表统计。西门子触摸屏的报警控件可以直接绑定状态字变量，当状态字从1跳到2时，报警记录自动生成“设备故障”条目，同时记录当前时间。历史报表也可以按状态字统计运行时间、故障次数。

更进一步，可以在PLC里再做一层“设备汇总”：用一个FC扫描所有设备的状态字，统计整线的运行数量、故障数量、待机数量，写到整线级DB区的汇总字里。触摸屏主画面上一行显示“运行/故障/待机设备数”，操作工一屏掌握全厂设备情况。这个汇总功能看似简单，但用之前的三分区DB思路扩展起来非常顺畅——每个设备的业务语义已经整理到状态区了，汇总只是加一个循环扫描而已。

回头说说5分钟这个概念。真正5分钟能做完的，是理解了这套数据流组织和通讯思路之后，在一个成熟模板上修改位号和数量。第一次做的时候，建议先在纸上把DB块三分区画出来，把FC输入输出列清楚，把触摸屏动画对照状态字排列好，然后再动手组态。我见过太多项目组一上来就拖变量建画面，做到一半发现显示逻辑和实际工艺对不上，推倒重来，那种返工才是真正的时间黑洞。先设计再实现，这句话在PLC触摸屏联动监控这个领域，比任何技巧都重要。