值班护士最怕什么不是忙是信息不对称——夜里有三个床位同时按铃走廊尽头那间的灯到底亮没亮刚处理完五床的换药一回头七床的呼叫又响了到底哪个先按的这类问题本质上就是呼叫信号在“产生、传递、应答”三个环节上出现了丢信息、没记忆、无优先级。我之前在某医院项目里做的就是一套基于博途1200 PLC的四病房八床位呼叫控制系统用S7-1200加护士站面板把八个床位的呼叫按钮、状态指示灯、蜂鸣器和应答复位逻辑全部整合进来。这篇文章就把整个项目的需求拆解、硬件选型、程序架构和调试经历完完整整梳理一遍适合正在做小型离散控制系统、或者想用博途从零搭一套完整项目的朋友作为参考。这套项目功能上并不复杂但麻雀虽小五脏俱全多个呼叫源的锁存、优先级判断、应答清除、掉电保持、声光联动全是实际工程里的高频需求。与其只讲某个指令怎么用我更想把“为什么这么设计”“调试时哪里会翻车”都讲透毕竟做项目最值钱的部分从来不在手册里。1. 项目背景与需求分析病房呼叫系统到底要解决什么问题1.1 需求场景拆解医院病房的呼叫系统本质是一个典型的“多点输入、集中输出、人工应答”的离散控制场景。病人或家属按下床头按钮护士站需要立即知道是哪个病房、哪个床位发出的呼叫同时通过声音和光信号引起值班人员注意。处理完呼叫后护士需要能主动清除该床位的呼叫状态系统才能进入等待下一次呼叫的待机状态。这里的核心难点不是单点呼叫的处理而是多个床位同时呼叫时信息不能丢失、顺序不能混乱。举个例子晚上九点三床、六床、八床几乎同时按下呼叫按钮。如果面板上只有一个铃响护士赶到护士站时根本不知道是哪几个床位在呼叫。如果指示灯全部常亮就无法区分“新呼叫”和“已看过的呼叫”。这些问题都要靠程序逻辑去解决而不是简单地把按钮接上PLC就完事。这个项目里我把它定义为“四病房八床位”架构每个病房两个床位共八个呼叫单元。每个单元包含床头呼叫按钮、护士站对应指示灯。四个病房门口上方安装门灯护士站配置蜂鸣器。所有信号统一接入护士站的一台PLC和一块操作面板。1.2 功能需求与设计指标在动手写程序之前一定要先把功能需求一条一条列出来否则调试的时候会出现“逻辑改了又改最后自己也搞不清怎么回事”的情况。我当时整理的需求清单如下第一呼叫锁存功能。病人按下呼叫按钮后即使按钮马上松开系统也必须保持“该床位正在呼叫”的状态直到护士主动应答清除。这个功能是呼叫系统的底线如果做不到病人按完按钮手一松指示灯灭了等于白按。第二声光联动。任意床位呼叫时对应的护士站指示灯亮起走廊门灯闪烁或常亮蜂鸣器发出提示音。四个病房的门灯要能直接看出是哪个病房在呼叫。第三优先级处理。紧急呼叫卫生间拉绳按钮必须优先于普通呼叫。当普通呼叫和紧急呼叫同时发生时声光指示偏向紧急呼叫普通呼叫不能被覆盖而是在面板上继续保留显示。第四应答与清除。护士处理完呼叫后通过护士站面板上的应答按钮清除对应的呼叫状态。应答操作必须精准对应到具体床位不能按一个按钮把所有呼叫全部清掉——那会让还没处理的呼叫信息丢失。第五掉电保持。病区的供电偶尔会因为检修或其他原因中断系统恢复供电后中断前未被处理的呼叫状态要能恢复显示。这需要PLC保持性存储区的配合。有了以上五条需求硬件规模基本就定了八个输入点普通呼叫四个输入点卫生间紧急呼叫一个输入点消音按钮若干输入点应答选床位操作八个输出点护士站指示灯四个输出点门灯一个输出点蜂鸣器。提示床头呼叫按钮和卫生间的紧急呼叫按钮要区分开。卫生间的按钮一般是拉绳式而且必须带自复位功能不能用自锁式按钮否则病人拉完绳子后状态无法自动复位系统逻辑会混乱。把这些需求理清楚硬件选型和IO点表规划就顺理成章了。2. 硬件选型与IO点表规划从零配置一套可落地的电气方案2.1 CPU与模块选型依据对这个项目来说S7-1200家族里1214C是性价比很合适的选择。它的本体自带14个数字量输入和10个数字量输出项目需求大约需要14个输入、9个输出不含备用点本体刚好能覆盖不需要额外挂扩展模块。如果选择1211CIO点数不够上1215C当然也可以但多出来的点位基本用不上成本反而高。CPU供电方式上我选择了DC/DC/DC版本也就是24V直流供电、24V输入、24V晶体管输出。为什么不选继电器输出版看负载特性护士站指示灯是DC 24V的LED灯蜂鸣器也是小功率器件晶体管输出完全能带得动。晶体管输出的响应速度快而且模块体积更小。不过有一点必须注意——晶体管输出不能直接驱动大功率负载所有输出点要通过中间继电器去转接负载保护PLC输出点。实际接线时我在每个输出点和一个DC 24V中间继电器线圈之间串联继电器的触点再去驱动指示灯和蜂鸣器这样即使负载侧短路也不会烧坏PLC的输出回路。还有一个很重要的选型思路通讯接口。S7-1200本体集成PROFINET口后续如果增加护士站触摸屏比如KTP400 Basic直接网线对接不需要额外通讯模块。即使暂时不上HMI留一个以太网口做程序的在线监视和下载调试也是必须的。我做项目基本默认预留HMI扩展能力这是很划算的规划方式。2.2 IO点表与地址分配硬件方案确定之后就要把IO点表完整地梳理出来。这一步看似简单却是整个项目的地基。地址分配合理与否直接影响程序的可读性和后续维护的友好度。地址分配遵循一个原则同类型信号尽量连续排列且预留备用点。我当时分配的点表如下信号类型 | 地址 | 说明 普通呼叫按钮 | I0.0-I0.3 | 病房1至病房4每个病房1号床 普通呼叫按钮 | I0.4-I0.7 | 病房1至病房4每个病房2号床 卫生间紧急按钮 | I1.0-I1.3 | 病房1至病房4的卫生间拉绳按钮护士站消音按钮 | I1.4 | 仅关闭蜂鸣器不清除呼叫状态 护士站总清按钮 | I1.5 | 确认所有已处理呼叫后批量清除备用 护士站指示灯 | Q0.0-Q0.7 | 对应八个床位的呼叫指示灯 病房门灯 | Q1.0-Q1.3 | 病房门口上方LED门灯 蜂鸣器 | Q1.4 | 护士站面板蜂鸣器为什么要特意把普通呼叫按钮分成两组I0.0-I0.3是第一床、I0.4-I0.7是第二床因为这样在写程序时可以用字节的位模式直接判断哪个病房的哪个床位在呼叫。比如I0.0对应病房1一床I0.4对应病房1二床两个位组合起来程序里判断病房维度会更方便。这种“人为制造规律”的做法写程序时会体会到很大好处。2.3 接线层面的注意事项硬件接线环节有几个坑踩过才知道。第一床头按钮的接线要采用常开触点接入PLC输入公共端。不要用常闭触点因为一旦按钮线缆断开常闭接线方式会让PLC侧误认为按钮一直被按住呼叫状态永远无法复位。第二卫生间紧急按钮的线缆要用屏蔽双绞线而且屏蔽层单端接地。卫生间环境湿度高拉绳按钮的线缆敷设路径又长屏蔽不好容易在雷雨天气或大型设备启停时感应干扰导致误呼叫。第三所有指示灯的负极要单独汇流到电源负极导轨不要和按钮的COM端混在一起。混接可能造成地电位差使得某个灯莫名奇妙微亮。注意S7-1200晶体管输出自带短路保护和诊断功能但它在输出过载时会触发模块报错并停止该通道的输出。所以并不要因为“自带保护”就省掉中间继电器保护的是PLC输出点不是负载侧的安全隔离。3. 核心控制逻辑设计自锁、优先级、应答与记忆机制3.1 呼叫锁存与复位逻辑呼叫锁存是整个系统最简单也最核心的逻辑。病人按下按钮I点得到一个上升沿程序将这个床位的“呼叫标志”置位。护士按下对应床位的应答按钮程序将该床位标志复位。这里面的关键点是按钮是瞬动信号而呼叫标志是保持性信号两者之间的“信号转换”需要由S/R指令来完成。S7-1200里最简单的写法是置位复位指令// 每个床位独立的锁存逻辑以1号床为例 tag_呼叫按钮_I0_0 // 输入床位呼叫按钮 tag_应答按钮_护士站 // 输入护士站应答操作选择 SET_BF // 或者直接用置位指令 S tag_Call_Flag_Bed1 // 复位条件 R tag_Call_Flag_Bed1但工程上不要直接在OB1里堆十几个网络。我更推荐把单个床位的处理逻辑封装成一个FC或FB每个床位调用一次输入输出通过接口参数传递。这样一个床位一片逻辑改一个床位不会影响其他床位排查问题时可以直接在调用处看到每个实例的输入输出状态。所谓“应答按钮”在硬线面板方案里是一个自复位按钮加上一个八位选择开关。护士先旋转选择开关到对应床位再按应答按钮程序根据选择开关的编码值来决定复位哪个床位标志。这个方案简单可靠成本也低。如果后续升级到触摸屏方案就直接在HMI上点击对应床位的按钮把应答信号送到PLC。3.2 多床位同时呼叫的优先级处理八个床位同时呼叫的场景在实际运行的病区里确实存在尤其是上午换药时段。这时候护士站面板不能乱逻辑必须足够清晰。我的方案是“全量显示声音分级”。具体来说护士站面板上八个病床的指示灯全部亮起每个指示灯对应一个床位谁在呼叫看灯就知道不存在信息丢失。但是蜂鸣器的鸣叫方式不搞“一锅粥”当系统检测到有呼叫信号时蜂鸣器以0.5Hz的频率间隙鸣叫直到护士按下消音按钮后停止。如果存在卫生间紧急呼叫蜂鸣器切换为连续长鸣且不受消音按钮控制必须由护士确认并复位紧急呼叫标志后才停。为什么不用“只亮最新呼叫床位”的方案因为护士处理呼叫的顺序往往不是按呼叫时间而是按病情的轻重缓急。全部显示护士一抬眼就能全览局面自己决定先处理谁。如果只显示最新的早期的呼叫反而被覆盖了这是医疗场景不能接受的。指示灯的状态还要区分“新呼叫”和“已应答待处理”。我的做法是新呼叫产生时对应指示灯以1Hz频率闪烁护士按下消音按钮后蜂鸣器停止但所有正在呼叫的指示灯转成常亮。这样护士一眼就看出哪个床位是新按的、哪个已经响过一阵了。这个区分在夜间尤其重要——闪烁的灯比常亮的灯更容易引起注意。3.3 紧急呼叫与普通呼叫的区分逻辑卫生间紧急呼叫属于优先级最高的信号它的逻辑设计需要单独处理不能和普通呼叫混在一起。第一紧急呼叫的锁存标志必须独立。普通呼叫可以通过护士站总的清除按钮批量复位但紧急呼叫不能因为“批量清除”就跟着被清掉必须单独确认后才能复位。我在程序里把紧急呼叫标志和普通呼叫标志分开存放在两个不同的保持性字节里任何批量操作都只针对普通呼叫区。第二门灯的颜色要区分。四病房的门灯我选的是红绿双色LED灯。普通呼叫时亮绿色紧急呼叫时亮红色。护士在走廊上远远看过去就能根据颜色判断是否需要跑着过去。第三紧急呼叫的复位条件。护士到达卫生间后通过卫生间门口安装的复位按钮来清除该病房的紧急呼叫标志。这个复位按钮装在卫生间门外高度约1.2米既能防止病人误触又方便护士操作。3.4 掉电保持与记忆功能医院病房区偶尔会进行线路检修配电切换瞬间设备会断电几十秒。病人呼叫到一半设备断了电等恢复供电后呼叫状态丢了——这在护理流程里是不能接受的。S7-1200的保持性存储区能解决这个问题。具体操作是在PLC属性中设置保持存储区范围把呼叫标志所在的DB块设置为“保持”或者直接在DB变量属性里勾选“掉电保持”。这样PLC断电后这些数据会被保存在CPU内置的断电保持存储器中。恢复供电后程序从保持区域读取数据变量的值还是断电前的状态。这里有个容易忽略的细节保持性存储区是有限的大型DB块不能全部勾选保持。我在这里只对“呼叫标志”“紧急标志”“应答时间戳”等少量关键结构体变量勾选了保持性普通中间变量不保持。设计DB结构时就要考虑到这一点把需要掉电保持的变量集中在同一个结构体中方便统一设置。4. TIA Portal编程实现OB、DB与程序块的组织方式4.1 项目创建与硬件组态要点TIA Portal的版本选择上我用的是V15.1对应S7-1200固件版本4.2。开发前要注意博途版本和PLC固件版本必须兼容否则组态时可能出现“模块无法识别”的问题。创建项目后第一步是在设备组态中添加CPU 1214C DC/DC/DC。硬件组态里需要设置的项目包括PROFINET接口的IP地址比如192.168.0.10、子网掩码255.255.255.0以及数字量输入点的输入滤波时间。输入滤波默认是3.2ms对普通按钮应用没问题。但有的病床按钮弹簧老化后接触抖动严重3.2ms不够容易出现一次按下被采集成多个上升沿的情况。这种场景可以考虑把滤波时间调到6.4ms或12.8ms。硬件组态保存后不要急着写程序。先做一个最简单的测试程序把所有输入点直接连接到输出点测试按钮和指示灯一一对应是否正常。这一步能把接线问题全部暴露出来比直接写完整逻辑再去排查方便得多。我第一个版本的测试很简单就是一条赋值语句Q0.0 : I0.0按一个按钮亮一个灯。确认全通后再删掉开始写正式逻辑。4.2 程序块结构设计程序组织上我用了一个OB1作为主程序内部调用若干个FC和FB。把逻辑拆分成功能块的好处是调试时能精确定位——蜂鸣器逻辑有问题就只看蜂鸣器FC不用在上百个网络的OB1里翻。结构规划如下OB1主程序扫描周期内依次调用各功能块FC1呼叫锁存处理处理八个床位的呼叫锁存与复位FC2优先级与声光控制根据呼叫标志决定指示灯、门灯、蜂鸣器的输出状态FC3应答输入解析解析护士站选择开关编码生成对应床位的复位指令DB1呼叫状态数据块存储所有呼叫标志、时间戳、系统状态DB2HMI通讯数据块供HMI/监控表读取的映射区其中DB1是系统的“大脑”所有关键数据都集中在这里。它内部设计成一个结构体的数组长度为8每个元素对应一个床位。4.3 核心程序段实现思路以单个床位的锁存逻辑为例在FC1里我采用临时变量循环展开的方式每个床位写三段式逻辑第一段检测呼叫按钮的上升沿。用Edge指令比如R_TRIG捕捉按钮信号捕捉后立刻调用置位指令将该床位的呼叫标志置为TRUE。为什么必须用上升沿因为病人可能长时间按住按钮也可能手一抖按了两下。如果用电平判断直接置位按钮一直按着时逻辑会一直执行置位相当于系统无法区分“按了一下”和“按住不放”。加上上升沿无论按钮被按多久多快只产生一次有效的呼叫锁存动作。第二段检测复位条件。护士站选择对应床位并按下应答按钮后形成该床位的复位信号上升沿将对应的呼叫标志复位。复位后指示灯熄灭门灯恢复待机。如果同一床位出现“按钮还没松开护士就已经应答”的极端情况逻辑上要以复位优先因为护士的实际处置优先级高于病人的持续按压。第三段将呼叫标志映射到输出。这个不建议在锁存FC里做而是放到FC2统一处理。FC2读取DB1中的八个呼叫标志分别对应到Q0.0-Q0.7。同时根据八个标志的“或”结果驱动蜂鸣器根据每个病房的两个床位标志的“或”结果驱动门灯。程序块之间的数据传递是通过DB1完成的调用关系清晰监控表里能一眼看到全部标志的实时状态。4.4 蜂鸣器与门灯的定时逻辑蜂鸣器不能一直响设计成间歇鸣叫能让声场更友好。S7-1200中没有像S7-200那样的“闪烁”指令需要自己用两个定时器搭第一个定时器TON设置0.5秒作为“鸣叫时间”。第二个定时器TON设置0.5秒作为“静音时间”。两个定时器交替使能形成0.5Hz的占空比。这里要注意的是这两个定时器的使能条件必须同时受“有呼叫”和“消音状态”两个标志控制。消音按钮按下后消音标志置位定时器整体失能蜂鸣器输出被拉低。门灯的逻辑要复杂一点——普通呼叫绿色常亮紧急呼叫红色闪烁。红色闪烁的0.5Hz逻辑和蜂鸣器一样用定时器搭。但门灯和蜂鸣器分开控制的好处是如果两个病房同时有呼叫门灯都亮蜂鸣器只响一套不会因为多个信号叠加导致蜂鸣器声音紊乱。4.5 HMI画面设计要点可选方案如果项目预算允许我建议直接在护士站加一块KTP400 Basic触摸屏替代硬线面板。这样原先需要选择开关和按钮的操作屏可以直接在HMI上实现而且还能附带显示呼叫持续时间、处理状态等额外信息。HMI画面的核心布局思路是四个病房分成四个区域每个区域里两个床位块。每个床位块用一个大按钮展现无呼叫时显示灰色背景、白色床位号有呼叫时显示红色背景、闪烁的床位号。点击该按钮即对该床位进行应答复位。紧急呼叫状态用单独的黄色块覆盖点击后进入紧急复位确认画面避免误操作。HMI与PLC之间的数据交互全部通过DB2完成。PLC侧把呼叫标志映射到DB2HMI侧只读写DB2。这样即使修改了PLC内部的数据结构也不会影响HMI的变量连接维护成本低很多。5. 调试方法与实际问题排查从仿真到实机那些容易翻车的细节5.1 用PLCSIM做逻辑验证时需要注意的差异正式上电调试前我用PLCSIM把逻辑先跑了一遍。仿真有它的价值——可以验证程序的基本逻辑和分支结构有没有低级错误比如变量类型不匹配、置位复位顺序颠倒等等。但仿真和实机的差异必须心中有数否则容易把仿真通过当成万事大吉。差异主要在两点第一仿真环境里没有机械触点的抖动问题按钮按下去就是干净的电平变化实机则可能抖几下。第二仿真时IO信号由模拟表强制给定没有真实的电磁干扰和压降问题程序在仿真里跑得再完美也不代表接线和现场环境没问题。所以仿真只验证逻辑验证完必须做完整的实机测试。5.2 实机调试中常见的六个问题实机调试阶段我遇到或排查过的问题大致有六类逐一说一下第一置位和复位优先级冲突。S7-1200的置位指令S和复位指令R如果放在不同网络里执行顺序不同会导致结果不同。比如一个网络里先执行复位另一个网络里再执行置位那么同一扫描周期内如果两个条件同时成立最终状态取决于谁后执行。我在最初的版本里把置位逻辑和复位逻辑放在两个网络里结果出现在特定时序下呼叫标志变成“置了又复、复了又置”的不稳定状态。解决办法是把同一床位的置位和复位放进同一个网络用RS或SR触发器的指令功能块来显式定义优先级。第二按钮抖动导致的多重触发。第一个版本用的是单纯的电平判断加置位测试时发现快速按两下按钮第二下会在已置位的情况下再触发一次置位导致应答后呼叫状态不清除。排查后确认是上升沿检测不够干净。加上R_TRIG指令后程序只对信号的第一次上升沿响应问题消失。第三消音按钮逻辑错误。最初把消音按钮设计成“按下蜂鸣器停”但护士松开按钮后蜂鸣器又开始响。原因是我没有对消音按钮做锁存——消音信号必须持续有效直到下一个呼叫到来或护士手动复位为止。后来改成按下消音按钮置位消音标志消音标志使蜂鸣器输出强制失能有新的呼叫产生时自动复位消音标志让蜂鸣器重新发声。第四掉电保持没有生效。组态里明明勾选了保持但断电重启后呼叫标志还是丢了。排查发现在硬件配置里设置保持存储区时我没有勾选对应的DB块导致实际编译后DB没有被分配到掉电保持区域。需要在DB属性里逐变量确认不能只改PLC属性。第五门灯闪烁频率异常。两个定时器搭的闪烁逻辑在个别病房出现快慢不一。原因是闪烁频率程序里用了M区定时器但多个病房公用了一个定时器位导致互相干扰。改为每个病房独立使用一组定时器地址后恢复正常。第六输入点滤波时间设置过大。一开始把滤波时间调到20ms结果护士按下应答按钮后大约有半秒的响应延迟手感很差。这个项目里按钮都是接插件触点质量尚可最终把滤波时间定在6.4ms既不产生误触发响应也跟手。5.3 必要的可靠性设置与例行检查调试完成后不要急着交付。有几个可靠性相关的设置必须过一遍一是看门狗时间。S7-1200默认的扫描周期监控时间是100ms正常运行肯定没问题但一旦程序里出现死循环或者定时器异常系统会进入STOP状态。这个默认值保留即可不必刻意调大。二是强制表检查。调试过程中我用强制表强制过IO信号交付前必须把所有强制项删除否则某个输入可能一直处于被强制状态造成误判断。这个错误在初次做项目时很容易漏交付后系统表现怪怪的查半天才发现是强制残留。三是程序备份。最终版本的程序要导出成归档文件保存在本地和网盘各一份。同时导出一份变量表和IO点表的Excel版本留给现场运维人员做参考。接线图和点表是后续维护最需要的东西别只留程序文件。我更建议把这个项目里所有“排查经验”整理成一个简单的检查清单比如“先查接线、再查滤波、最后查强制表”贴在PLC控制柜内侧对后续运维会非常有帮助。6. 项目扩展思路从八床位到整个病区6.1 床位与病房数量扩展这套系统的逻辑本质是“每床位一个锁存块”所以扩展起来非常顺。如果某个病区从八个床位扩展到二十四个床位处理器可以选择1215C或1217CCPU本体IO不够用就补一个SM1223数字量输入输出模块。原来的FC1锁存逻辑可以继续复用因为每个调用实例都是独立的背景数据块新床位无非是新增几个调用实例而已。唯一要重新考虑的是护士站面板或者HMI画面的布局。硬线面板的开关和指示灯数量多了之后操作区会非常大这时换成触摸屏方案会更合理——屏幕尺寸不变画面翻页或滚动即可硬件成本提升有限但用户体验和扩展灵活性都大幅提升。6.2 与HIS系统对接和数据统计病房呼叫系统如果只停留在“灯亮铃响”的层面其实还有大量管理价值没有被利用。S7-1200支持PROFINET和OPC UA可以把呼叫时间、应答时间、处理时长实时上传到上层系统。做护理管理时这些数据可以用来统计各床位的呼叫频次、高峰时段甚至评估护士的响应效率。我当时做完基础呼叫功能后顺手在PLC里加了一个“呼叫时间戳”变量数组——每次呼叫产生时记录系统运行秒数应答时再记录一次两者差值就是呼叫持续时间。这个数据先放到DB里后续接上位机或HMI时直接读出来显示和统计。虽然这个项目后来没有真正接HIS但数据结构提前预留了后面改造成本很低。6.3 无线呼叫与移动护理终端如果院方希望进一步优化可以考虑无线呼叫方案病人佩戴无线呼叫器信号通过网关接入S7-1200的以太网口。PLC侧的逻辑基本不用变只需要把网关传过来的床位号映射成原有的呼叫标志即可。护士站终端从固定面板升级成移动PDA应答操作也从现场按键变成PDA上的点击确认。这套方案的硬件成本会比纯硬线系统高一些但换来的是护士在任何位置都能收到呼叫并处理行动效率改善非常明显。从我个人的实践体会来看无论做哪个行业的控制系统最难的不是会写几个PLC指令而是对整个现场场景的理解。医院病房呼叫系统虽然看着简单但真正把它做成让临床护士觉得“顺手、不误报、信息清晰”的系统背后靠的全是对需求细节的死磕。这些细节项目结束后不会出现在任何官方文档里但它们恰恰是整个项目最有价值的部分。如果你也正在做类似的呼叫系统或离散控制项目希望这篇内容能帮你少走一些弯路。