企业官网建设流程全解析

提到西门子1200自动洗车博途仿真，免不了从我自己碰到的一个项目聊起。去年接了个洗车机控制的需求，三工位自动洗车，要完成预冲洗、泡沫、刷洗、冲洗、风干、等待六个步骤，操作员只需按启动按钮，全过程自动跑完。我第一反应就是用S7-1200来做，而且先用博途仿真把整个逻辑跑通，再去碰现场设备。这套系统做完后，我把程序整理成了一个模板，后来不少学员和同行都来问：洗车流程的状态机是怎么设计的、I/O点怎么分配、HMI画面怎么布局、仿真调试时遇到过哪些坑。这些问题零零散散，今天干脆完整拆一遍，从控制需求到程序架构，从画面组态到仿真排错，全部写清楚。

这篇文章适合三类人看：刚接触博途想找个完整案例练手的新手，准备做洗车机、输送线这类步进工艺设备的电气工程师，以及想把手动单机改成自动联机但不知道怎么下手的朋友。配套的PLC例程和HMI工程文件，讲解时会提一下文件结构，方便你照着实操。

1. 为什么自动洗车项目适合用西门子1200来做

1.1 洗车机控制的核心需求

先说说洗车机到底要控什么。抛开品牌和外观差异，常规隧道式或往复式洗车机，核心动作基本都是这套逻辑：车辆到位检测、喷淋预冲洗、喷洒泡沫、刷洗、高压冲洗、风干、完成提示。整个过程就是一个典型的顺序控制流程。

顺序控制有几个特点：步骤多但路径清晰，每个步骤之间有明确的切换条件，有的步骤还带超时保护、急停复位、故障报警。这种场景正是PLC最擅长的地方。你用继电器搭当然也能实现，但一旦需要调整步骤顺序、修改某个工位的时间参数，就会非常痛苦——改硬接线、改凸轮、换继电器，工程量不比重新做一个少。

而用PLC加触摸屏之后，调整流程只需要改程序里的状态跳转条件或HMI上的时间参数，设备不用动一根线。这也是为什么现在市面上的自动洗车机基本都走PLC方案。

1.2 S7-1200在同类方案中的定位

在西门子产品序列里，S7-1200属于小型PLC，但它的能力用在洗车机这种场合绰绰有余。以1214C DC/DC/DC为例，集成14路数字量输入、10路数字量输出，自带2路模拟量输入，还支持扩展信号板。如果只算数字量，一个1214C最多可以带32个点左右的本地I/O。常见的洗车机配置大概是二十多个输入点、十几个输出点，紧凑一点的1214C不加扩展模块也够用。

博途仿真这一块也要多说一句。TIA Portal V16以上版本的仿真功能已经比较成熟，S7-1200的PLC程序可以在不连接实体硬件的情况下在电脑上完整跑起来。对学习者和前期开发来说，这意味着你可以先不买PLC，不接线，不装传感器，就能把程序逻辑、HMI画面、运行联调全部验证一遍。等仿真没问题了再上真机，省下的时间和试错成本非常可观。

用1200还有一个很实际的原因：程序文件小，打开编译快，不挑电脑配置。我用博途V17打开一个完整的洗车机项目，包含PLC程序和HMI画面，编译下载基本都在十几秒内完成。对比之前用1500做项目，动辄几百兆的项目文件，1200的小巧确实更适合拿来调试和频繁修改。

2. 控制需求拆解：先把洗车流程变成I/O表和状态

2.1 洗车工艺的六个核心阶段

自动洗车的工艺看着不复杂，但真要落到程序里，必须把每个阶段拆细。我通常把它拆成六个主状态：

• 空闲：等待车辆进入，检测传感器无信号，输出全部关闭
• 预冲洗：车辆到位后启动预冲水泵，持续8秒
• 泡沫喷洒：预冲洗结束后启动泡沫泵和刷子电机，持续15秒
• 刷洗：刷子来回摆动，同时喷淋保持湿润，持续20秒
• 高压冲洗：关闭泡沫泵，启动高压水泵，持续10秒
• 风干：关闭水泵，启动风机，持续15秒

每个主状态下还有分支，比如刷洗阶段刷子电机是正转、反转还是左右移动，这些要单独控制。另外急停信号在任何状态下都必须立即生效——这不是状态机里的一个状态，而是独立于状态机之外的一个“最高优先级中断”，这一点后面细说。

2.2 I/O点表：程序不返工的起点

我见过太多人拿到项目就直接写梯形图，写到一半才发现输入点不够、输出点重复占用、模拟量通道不够用，然后回头改，越改越乱。正确的做法是先列I/O点表，把所有传感器、按钮、执行器对应到PLC地址上，确定无误后再动程序。

以一套紧凑型往复式洗车机为例，I/O点表大概长这样：

列这个表的目的是什么？两个。第一，确认PLC的I/O配置是否够用，如果不够，趁早决定是换1215C还是加扩展模块；第二，为后面的程序变量表和数据块打好基础，避免程序中直接散落地址，后续根本没法维护。

2.3 传感器与执行器的选型思路

先给出基于常见实践的通用建议：车辆到位传感器用对射式光电开关或者地感线圈，前者安装方便、性价比高；刷子限位用接近开关，选电感式或电容式取决于刷臂的材质，金属支架选电感式，塑料件选电容式。

水泵这块，如果没有特殊要求，选普通三相异步电机加接触器控制就能满足大部分需求。但如果你做的是高压冲洗系统，压力波动大、启停频繁，我建议高压水泵走变频器，用S7-1200的模拟量输出或通信方式控制频率。这在程序里会多一个环节，后面第6节会专门说怎么处理。

3. PLC程序架构设计：状态机是洗车控制的骨架

3.1 状态机流转模型与转换条件

写顺序控制程序，最怕的就是用一堆置位复位指令从头套到尾。置位复位当然能实现，但程序一长，你根本分不清某个输出当前在什么状态下是通的，排查问题尤其痛苦。

我推荐用状态机思路：每个步骤对应一个状态位，状态之间通过转移条件切换，某一时刻只有一个状态位为1。举个例子，状态位的表达方式可以是M区布尔量，也可以是一个整型变量存状态编号。

以整型变量为例，定义一个DB块里的变量CarWashState，类型为Int：

• 0：空闲
• 1：预冲洗
• 2：泡沫喷洒
• 3：刷洗
• 4：高压冲洗
• 5：风干

状态切换用CASE指令来实现，这在S7-1200的SCL或者梯形图里都很好处理。CASE结构的好处是逻辑清晰、边界分明，每次进入一个分支，只需要处理这个状态的输出和下个状态的转移条件。以预冲洗为例：

CASE #CarWashState OF 1: // 预冲洗 #PreWashPump := TRUE; IF #PreWashTimer.Q THEN #CarWashState := 2; END_IF; END_CASE;

这段伪逻辑的意思是：在预冲洗状态下，预冲水泵输出得电，同时监视一个定时器；定时器到点后，状态切到泡沫喷洒。每个状态都类似，只是输出组合和转移条件不同。整套程序下来，梯形图量比传统的置位复位方式少了将近一半，而且调试时直接在监控表里看CarWashState的值，就知道设备停在哪个环节，定位问题快得多。

3.2 OB/FC/FB/DB的分工

博途项目里最大的坑之一，就是把所有代码都堆在OB1里面。OB1确实是从头扫描到尾，但一旦程序量上来，OB1就是一座屎山。洗车机控制程序，我建议按这个结构组织：

• OB1：主循环，只做FC调用
• OB100：初始化，把状态位、定时器、HMI变量恢复默认值
• FC_WashControl：主状态机，负责六步骤的流转
• FC_ManualControl：手动控制逻辑，给调试和维护用
• FC_Alarm：报警处理，急停、超时、电机过载检测
• DB_WashData：存放所有工艺参数和状态位
• DB_HMI：存放HMI读写变量，和画面一一对应

这样分完，每个功能块单一职责，谁出问题查谁。而且参数集中存储在DB_WashData里，后续要是想把预冲洗时间从8秒改成6秒，直接在HMI参数画面改就行，不用碰程序。

3.3 关键程序片段注意事项

这里必须提几个写洗车程序时容易忽略的点。

第一，状态与输出不是一一对应的简单的函数。比如泡沫喷洒阶段，刷子电机其实已经启动慢转，为的是让泡沫涂布均匀。如果你只在主状态机的CASE分支里做了这个逻辑，那就没问题。怕的是你在TIA里输出扫描时，由于置位/复位顺序不同，导致两个状态交界处的输出抖动。解决办法很简单：每个状态切换前，强制复位上一个状态的所有输出，再进入新状态。

第二，禁止两个状态同时有效。在状态机里，我用一个数值变量判断当前状态，天然互斥。但如果你用M区布尔量表示状态，一定要加互锁：进入状态B前，先复位状态A，再用状态A的常闭触点去串联状态B的启动。

第三，超时保护必不可少。每一道工序都要配一个超时定时器，例如刷洗阶段超过30秒还没完成，就要报警停机。原因是现场传感器可能失效、电机可能卡住、水泵可能空转，没有超时保护，设备会一直卡在某个状态，操作员又一时没注意，损失的可能是整台车。这种保护逻辑在FC_Alarm里做，调用TON定时器，设定时间取DB_WashData里对应参数，方便调试时缩短。

3.4 安全连锁必须想清楚

这是我在实际项目中反复踩坑后总结的：安全连锁必须独立于状态机，而且要优先于状态机执行。

急停就是最典型的例子。急停信号接到PLC后在OB1里第一个被扫描，如果急停按下，不管当前状态机走到哪一步，所有输出全部复位，设备立即停止。这不是在状态机里加一个分支，而是要在OB1开头加一段独立的逻辑：

// 急停信号串联在主输出使能上 #EStop_Input // 常闭触点PLC输入I0.3 #WashOutputsEnable // 主输出使能标志 ( ) // 输出使能脉冲，急停常闭复位为0

然后所有实际输出点Q0.0到Q0.7都用WashOutputsEnable的常开触点串联在最终输出线圈前。这样急停一按，哪怕状态机因为某种原因还在跑，输出通道全部切断。等急停复位后，要求操作员重新按启动按钮才会恢复——这属于安全PLC编程里“安全复位”的常见实践。

另外还有一个容易忽略的安全点：洗车机属于潮湿环境，电气柜必须做好防水防尘，现场传感器按IP67选型。急停按钮要装在操作员随手能够到的位置，建议双急停，入口一个出口一个。

4. HMI画面组态：从主画面到报警页面的五张画面

4.1 主操作画面：让操作员一眼看懂流程

HMI界面设计有一个原则我一直挂在嘴边：操作员不需要懂程序，他只需要知道“现在到哪一步了、下一步要做什么”。所以主操作画面我建议做成流程图风格，而不是简单的按钮堆砌。

画面顶部是状态指示区，六个步骤用六个指示灯排列，哪个步骤在运行，对应指示灯就亮，颜色用绿色；完成的步骤用灰色锁存显示；故障状态用红色闪烁。这比只显示一行文字直观太多。

画面中间是设备简图，用简单的矩形、圆形表示刷子、泵、风机的位置，每个设备旁边放一个输出状态指示灯。这样操作员看到刷子图标旁边灯亮了，就知道刷子电机确实在转，不用靠耳朵听。

画面底部是操作区，放启动、停止、急停复位三个按钮。启动按钮在自动状态下才有效，停止按钮任何时候都有效。急停复位按钮要弹窗确认，防止误触。

4.2 参数设置页面：洗车时间、泡沫量这样调

参数设置页面主要给工艺调试人员用。这一页按“预冲洗时间、泡沫时间、刷洗时间、高压时间、风干时间”分组，每组配一个数值显示框和输入框，变量直接连到DB_WashData里的对应参数。

这里分享一个之前踩过的坑：HMI直接连DB变量时，如果DB块没有设置“优化访问”，变量地址是偏移地址，在HMI里连接没问题；但如果开了优化访问，HMI连接时要注意变量名对应，不要用绝对地址。在TIA Portal里新建HMI变量时，直接从PLC变量的下拉菜单里选，能避免手写地址写错的问题。

另外，时间参数建议设置上限和下限，比如预冲洗时间限制在3到30秒之间。如果你不在HMI里做限制，操作员误填了一个0，设备会瞬间跳过这个步骤，客户还以为是程序坏了。限制逻辑可以在PLC侧做，也可以HMI侧做，我推荐PLC侧做，因为HMI重置或离线后，PLC侧限制依然有效。

4.3 报警与运行记录：售后少接电话的关键

报警画面别做成简单的红色大叉加一行文字。我比较推荐的布局是：上半区报警列表，每条显示报警时间、报警内容、当前状态；下半区是操作提示区，告诉操作员“当前故障应该怎么处理”。

比如“高压水泵过载”这条报警，操作提示写“请检查高压水枪是否堵塞或电机是否卡死，复位后重新启动”。操作员照着做，能解决八成以上的常见故障，电话打到你这边的次数会直线下降。

报警的PLC侧实现也不复杂。在FC_Alarm里，对每个报警条件生成一个BOOL标志位，上升沿时给HMI的报警变量置位，HMI画面配置离散量报警表，关联对应文本。HMI侧别忘了勾选“确认”按钮，报警发生后操作员按确认会停止蜂鸣器，但报警列表保持显示，直到故障排除后自动清除。

这个“确认消音但保持显示直到故障排除”的做法，是工业HMI报警处理的标准兜底策略：既不让操作员继续受刺耳蜂鸣干扰，又避免故障被草率忽略掉。

5. 博途仿真调试全流程：从下载到排错的实测记录

5.1 仿真环境的准备与硬件配置

博途仿真功能叫做S7-PLCSIM，从V14开始对S7-1200的支持就很完整了。使用前先检查一下你的博途版本：V15及以下的老版本，仿真器和主程序集成度较低，需要单独启动；V16以上版本，可以直接在项目树里右键PLC站点，选择“仿真”启动PLCSIM，体验顺畅很多。如果手头没有指定版本，建议用V17或V18，稳定性和功能都更好。

启动仿真前要确认三件事。第一，PLC设备组态中的以太网地址要设置好，仿真器运行时虚拟一个网口，HMI要能连上这个地址做协同仿真。第二，程序编译不能有错误，警告可以接受，但错误必须清零。第三，OB100里的初始化逻辑要看一眼，仿真启动时OB100只执行一次，如果你的初始化逻辑里有延时或等待，仿真开始时会感觉有点卡顿，这是正常的。

5.2 程序下载、变量监控与强制操作

在PLCSIM里下载程序和往真机下载操作几乎一样。点击下载后，博途会把编译好的PLC程序传送到虚拟PLC里，然后切换到在线监视。在线监视有个技巧：用监控表或者程序状态来查看DB_WashData.CarWashState的变化。我在调试时习惯把状态机相关的关键变量拖到监控表里，包括当前状态、启动按钮、停止按钮、定时器剩余时间，一屏看完所有关键量。

仿真里还有一个很有用的功能就是强制变量。比如你想测试急停逻辑，不用真的去按按钮，直接在监控表里把I0.3强制成0，就能模拟急停信号。这比接真机还方便，真机你还得去按物理按钮。

强制变量的使用有个注意事项：仿真结束前记得把所有强制值释放掉，不然下次打开仿真，强制值还带着，你查问题时会懵半天。我吃过这个亏——某次仿真调试到一个奇怪现象，所有输出都不动了，查了一个小时才发现是之前强制了一个常闭触点。

5.3 仿真调试时容易踩的坑

坑一：HMI和PLC仿真联调不上。这个最常见的原因是仿真器实例冲突。如果你同时开了一个以上的PLCSIM实例，或者上一次仿真没关干净，新的仿真例程可能起不来。解决办法：关掉所有PLCSIM进程，重新启动仿真。PLCSIM的运行实例可以在Windows任务管理器里看到，关掉后再试。

坑二：PLC程序里用了实际硬件地址访问，仿真时没有相应地址。例如直接访问模拟量输入IW64，如果仿真模型里没有给这个地址赋初值，程序会读到一个跳变的随机值。仿真前最好在监控表里想好：哪些输入保持一个固定状态、哪些输入需要手动触发，通过变量强制把初始环境搭好。

坑三：HMI仿真中点击启动按钮没反应。这种现象大多数不是因为按钮没连变量，而是PLC状态机没有进入自动就绪条件。检查三个点：WashOutputsEnable是否被复位、急停变量是否因为常闭逻辑而处于有效状态、车辆到位传感器是否置位。这三个条件不满足，启动按钮按下去了也不会触发状态切换。HMI侧容易处理，你会在按钮上看到置位瞬间又消失了——虚按，其实就是PLC侧条件不满足。

6. 从仿真改成真机：哪些地方必须动

6.1 地址映射从仿真IO迁移到真实IO

仿真时用的是PLCSIM虚拟IO，真机上要映射到物理输入输出模块，直接在设备组态里配好实际IO卡件地址即可。例如你仿真用的I0.0对应真机也是I0.0，那基本不涉及地址映射问题。但如果你仿真时把车辆到位信号放到了I0.0，真机布线时因为靠近方便，传感器接的是I0.3，那就得改程序或者物理改线。

我的建议是：前期I/O点表确定后，严格按点表布线，尽量让仿真地址和真机地址一致。这样程序从仿真搬到真机时，基本不用改地址，只要检查接线就好。

6.2 时间参数和流程节奏的重新校准

仿真时经常会把预冲洗时间从8秒改成5秒来加速测试，这会带来一个问题：你在仿真里验证的“合格流程”其实不完全是真实工艺。所以从仿真转到真机后，第一件事就是按照工艺手册把所有时间参数恢复成设计值，然后空载测试一遍，确认各执行元件动作正确，再接入水、电、气做带载测试。

带载测试时留意水泵启动瞬间的电流冲击和压力波动。有些现场会因为泵启动过快导致水管爆裂，这不是程序逻辑问题，而是启动时序问题。解决办法是在程序里加软启动延时，比如预冲水泵启动后先延时0.5秒，再打开喷淋电磁阀，让管道先充满水再喷射。

6.3 与变频器和传感器的通信集成

如果高压泵走变频器，那么PLC侧的通信设置不能等真机阶段才做。仿真阶段虽然对真实通信帮助有限，但至少要把程序框架搭好。S7-1200和变频器通信常用的方式是Modbus RTU或PROFINET。

PROFINET方式更简单些：在博途的设备和网络视图里，直接添加变频器的GSD文件，连成IO设备，PLC程序里直接通过IO地址读写变频器的控制字和状态字。Modbus RTU方式需要调用MB_COMM_LOAD和MB_MASTER功能块，设置波特率、数据位、停止位、奇偶校验，地址要和变频器侧参数对应好。

特别提醒：1200的Modbus通信有数量限制，一个通信端口最多只能带若干个从站，具体数量根据型号和固件版本略有差异，组态前查一下手册，别等接了七八台设备才发现从站数超了。

传感器这块，真机调试时最容易被忽视的就是“常开常闭选型”和程序逻辑一致性。比如车辆到位传感器你用了常闭型，程序里就要用常闭触点判断；如果现场装了个常开的，程序里没改，结果就是车辆还没到位，系统就认为有车进来，整个状态机乱跑。这个问题在仿真阶段很难暴露，因为仿真时你是手动置位变量，不涉及实际物理信号。

最后说两句梳理完这个项目的心得

把一套自动洗车控制系统从需求拆解做到仿真验证，再推到真机，整个过程最有价值的环节其实是“把每个状态和转移条件想清楚”这一步。很多入门的朋友总急着打开博途拖梯形图，最后程序越写越长，问题却越查越难。用状态机重构之后，这套洗车程序的主逻辑只有寥寥几个CASE分支，任何一步卡住，看变量就知道原因。

我实际测试下来，仿真做得越细，真机调试的时间就越短。那次现场调试，包括通信参数核对、传感器方向调整、工艺时间校正，前后只用了一天半就完成了整机联调。放在以前直接写真机的做法，至少得三天起。

如果后续想让这套系统更完善，两个方向可以继续深入：一是在HMI里加入数据记录功能，统计每天洗车数量、设备累计运行时间，方便运维做保养计划；二是把PLC接入上位机或云平台，通过Modbus TCP把状态数据上传，远程就能看到设备当前跑到哪一步、有没有报警。这些都是再往上一层的小改造，基础还是那个稳定的状态机程序——先把这一步走扎实，后面怎么扩展都不慌。