简介《ANDON系统操作维护说明手册》是一份面向汽车制造业生产线操作员、班组长及设备维护人员的专业文档系统讲解源自丰田生产系统的ANDON实时监控与快速响应机制。手册内容覆盖系统介绍、系统构成、总装车间ANDON系统使用方法详细说明了ANDON板显示内容、运行模式、SIP呼叫站操作流程及ANDON板内容的更改方法并结合上汽通用五菱项目实际场景展开有助于操作员掌握从呼叫发起、信号显示到停线联锁的完整工作逻辑。安全部分尤为细致针对触电风险、机械伤害、电缆损伤等常见隐患给出了禁止性操作提示与应急处理原则例如设备运行时不得打开控制柜门盖、禁止接触旋转部件、开启大屏前须断开220V电源等还强调了故障修复后的重启确认要求。资源为单个doc格式文档压缩包内仅1个文件、容量958KB内容集中适合快速查阅现有115人浏览学习。无论是新员工岗前培训还是现场作业中的安全自查这份手册都能提供清晰、可落地的操作依据。1. ANDON系统操作维护说明手册一张看板背后要维护的是一条完整的异常响应链车间里最怕的不是ANDON系统坏了而是它“半坏不坏”按钮按下去看板没亮喇叭不响但PLC又好像收到了信号。《ANDON系统操作维护说明手册正文.doc》这类文档就是为这种现场问题存在的。它不教你建系统而是把信号怎么从工位走到看板、中间经过哪些环节、每环看什么数、坏了先查谁按可执行逻辑写清楚。适合倒班设备员、新接手产线的维护工程师、跟线实施顾问读。这篇记录沿“链路是什么、日常怎么操作、配置怎么改、故障怎么排”的顺序把手册里最容易被跳过但最值钱的部分拆出来。2. ANDON系统到底在维护什么从信号链路到看板刷新的四个组成2.1 安灯系统的典型链路呼叫信号怎么从工位走到看板ANDON最早是丰田生产方式里的安灯拉绳但现在的ANDON系统早就不是一根绳加一块板子了。我在现场见过的项目普遍由四个部分组成呼叫终端按钮、拉绳、脚踏开关、采集与逻辑层现场IO模块、PLC或者少数直接用服务器采集、显示与提醒层LED看板、工控机屏幕、语音播报器、数据与追溯层ANDON服务器、数据库、Web报表。维护手册整本就在讲这四层之间怎么传输信号、怎么判断故障在哪一层。一条典型的呼叫链路是这样走的工位操作工按下呼叫按钮24V直流信号进到最近的IO模块IO模块通过PROFINET、CC-Link、EtherCAT这类总线把点位上送给PLCPLC按程序做防抖处理、判断呼叫类型和工位归属然后在数据块里置位对应的“呼叫请求”看板控制器和服务器通过工业以太网轮询这个数据块看到变化后驱动LED看板变颜色、喇叭播报、服务器往数据库写一条事件记录。注意这里每一步都有可能是故障点而手册的价值就是把这些故障点显性化。为什么中间一定要经过PLC而不是直接把按钮接到看板上因为直接接看板只解决了“显示”但做不到超时升级、多级呼叫、跨线统计、按班次报表这些生产管理功能。PLC加了之后维护人员手里多了一个可以强制输入、强制输出、在线监控的逻辑分析口。但也多了一个黑匣子程序版本不同、数据块命名不同、注释不全都会让“信号明明进来了看板却不动”这种问题变得很难查。所以我在给维修班做培训时第一句话永远是你能把链路画出来故障就已经解决一半。画不出来就只能靠换备件碰运气那是玄学。维护手册正文里通常会给一张简化链路图如果你拿到的doc文件里没有图就自己打开PLC在线监控和看板通讯状态把每一段的信号状态抄在一张纸上这也算把缺失的文档补上了。2.2 手册里最该先看的三张图网络拓扑、IO清单、看板地址表拿《ANDON系统操作维护说明手册正文.doc》这种文档不要从头一页页读。先找三张表找到了再读别的找不到就去现场对照着读程序注释。这三张图对应着你日常维护的三个问题设备在哪、信号在哪、显示在哪。第一张是网络拓扑图。它告诉你PLC、IO站、看板控制器、ANDON服务器、工程师站各自在哪个IP段交换机端口够不够是否跨了网段。排查“看板和PLC偶尔断连”这种问题首先就是拿一张拓扑图从一个节点ping到另一个节点。常见故障里很大比例不是设备坏了而是二期项目扩容时把网段改了维护手册没有同步更新导致后来的人拿着旧文档白查半天。第二张是IO清单。生产线上几台设备、每个工位有哪些按钮和拉绳、对应的PLC输入点是什么、输出点控制哪个指示灯全在这一张表里。这张表通常是在Word里嵌了一个Excel表格缩得很小打印出来根本看不清。我的习惯是把它单独导出来放大贴在PLC柜门内侧再备份一份到手机。很多“看板一直亮红灯”的问题打开IO清单一查对应PLC输入点能监控到信号一直在那就是复位信号没到而不是看板的问题。第三张是看板地址表。LED看板或者工控机看板画面每个分区显示哪条产线、哪个工位、哪个呼叫类型颜色变化对应的数据库字地址是什么都在这里。维护时最常遇到“看板显示的位置和实际工位反了”或者“呼叫类型颜色错乱”多半是地址映射表被改过但手册没更新。所以我强调手册不是拿来供奉的是拿来和你现场的PLC程序、看板组态一件件核对的。这三张图核对完你基本就能回答“ANDON系统操作维护”这个标题里的大半问题。剩下的日常工作就是基于这些地址表去做检查、复位和排故而不是靠老师傅的记忆。2.3 把操作维护手册拆成现场巡检表四层对应四个自检项手册写得很厚但现场一个月真正能用到的动作可能就十几个。我一般会把手册压缩成一张A4巡检表做成塑封卡片挂在控制柜上。巡检表按前面说的四个层来分每一层都有明确的判断标准和处置动作这样倒班员工也能看懂。物理层检查工位拉绳、按钮、脚踏开关外观是否完好按下后是否能听到微动开关“嗒”的一声松手后是否自动复位。拉绳开关如果带自锁拉出来之后必须手动旋转复位这个动作新手最容易漏导致看板一直处于呼叫状态。控制层观察PLC面板和IO模块指示灯RUN灯常亮ERR灯和某个通道的指示灯不应该以异常方式闪烁。如果PLC面板上有BAT灯亮说明电池电量低了这个不是马上故障但会丢程序必须安排更换。网络层从维护电脑ping服务器和看板控制器的地址丢包率应该是0每一次ping的延时都应该很稳定如果时好时坏重点排查网线接头和交换机端口车间的叉车压线和老鼠啃线是重灾区。显示层看板是否有心跳指示某些系统在看板角落有个小点每隔几秒闪一下喇叭的音量旋钮是否被误调播报是否清楚。巡检频次要根据产线运行状态定。连续生产的线交接班一次每两小时对典型工位抽查一次单班生产的线开线前全部检查中午休息做一次语音测试。很多系统的问题不是瞬间坏的而是慢慢退化比如喇叭音量越来越小、看板LED开始有点缺、拉绳微动开关接触电阻变大这些用巡检表能提前发现而不是等到“响铃不良”被车间投诉。这里还要补一句关于doc文件版本管理的提醒手册正文.doc往往不是一成不变的。你改过一次PLC程序、调过一次超时时间就一定要在手册里更新对应的章节。否则半年后这份手册就会变成和你现场系统脱节的“僵尸文档”照着做反而会误操作。维护手册的维护本身就是维护工作的一部分。3. 日常操作从交接班检查到异常呼叫的标准动作3.1 交接班检查为什么先查“感知层”而不是查软件我见过不少交接班只做一件事看一下看板有没有电。看板一亮就觉得系统没问题然后十点喇叭不响才发现看板虽然是亮的但语音线路早就断了。交接班检查的核心应该是“信号走得通”而不是“屏幕亮不亮”。因为看板亮只代表显示层上电而物理层的按钮、拉绳、喇叭可能都是坏的。交接班检查我按下面这张表来做。它不算长但每一项都对应一个后续故障风险。检查时最好两个人配合一个在工位按按钮一个在看板下看变化这样链路才能真正从一头通到另一头。检查类别 | 检查点 | 合格标准 | 异常处置 物理信号 | 各工位按钮/拉绳/脚踏 | 按下后工位指示灯亮弹回灵活 | 调整角度、清洁触点、更换开关 PLC状态 | CPU与IO模块面板 | RUN灯常亮无ERR灯无BAT灯 | 查看CPU诊断缓存区预约停机换电池 看板显示 | 上电自检画面 | 显示版本号、线别、日期时间正确 | 记录版本与服务器配置比对必要时重新同步 语音播报 | 抽查两个远端喇叭 | 播报声音清晰、无破音、音量足够 | 调节功放音量检查喇叭接线 网络通信 | 维护电脑ping服务器/看板 | 丢包率0%延时稳定 | 更换网线、重启交换机端口为什么要先查这些感知层因为感知层的故障往往不影响其他功能看板还能显示上一分钟的历史数据但新的呼叫进不来这种“假活”状态最容易误导人。手册通常会把“先物理、后逻辑、再软件”写在排故总则里实际执行时最容易被跳过因为物理检查要走到现场而看软件在办公室就能完成。你不走到按钮旁边就永远不知道那个拉绳手柄被卡在了半程位置。交班时还有一个容易被忽略的动作把夜班发生的故障和临时改过的参数在本子上交接。很多ANDON系统没有完善的报警推送夜班处理问题的人可能直接按下PLC某个点强制复位了却没有告诉白班。交接班如果只看系统当前状态就会漏掉“某个保护点被强制”这种潜在风险。所以我要求倒班员工交班时必须把动过的点位写下来哪怕只在微信群里发一句话也行。3.2 异常呼叫、响应闭环与复位的标准动作正常生产时操作工发现物料、设备或质量异常会拉动工位旁的拉绳或按下呼叫按钮ANDON系统的标准响应是这样一步步走的第一步呼叫终端触发工位信号灯亮起表示这个工位已经发出请求。第二步看板对应分区变红或变黄多数系统里红色代表停线类呼叫黄色代表质量提示绿色代表正常运行。第三步语音播报“XX工位物料呼叫”让班组长和物流人员即使不看板也知道去哪。第四步班组长或钳工到位处理问题。第五步处理完成后由该工位操作工或现场组长按复位按钮或将拉绳开关旋回原位。第六步看板分区恢复正常系统在数据库里记下“呼叫时刻、响应时刻、闭环时刻”这条完整记录。这里最关键的参数是“响应超时时间”。我经手的项目里普通呼叫超时一般设60到180秒超时后看板从黄色变红色语音会再播报一遍有的系统还会自动发短信给主管。超时值太长异常处理会拖沓太短系统频繁升级会变成“狼来了”。这个值在手册里通常叫“响应时间设定”但具体放在PLC还是服务器脚本里每个项目不一样。改它之前一定要先确认是哪个逻辑层控制。还有一件关于复位的原则复位操作必须在发出呼叫的工位附近完成。很多维护人员看着看板分区红了就跑到看板控制柜前按一个总复位这样虽然画面恢复了但问题可能根本没解决系统却认为已经闭环了。这是最典型的误操作等于把生产异常记录给抹掉了。所以我在制度上规定看板柜总复位只用于系统联调生产期间严禁用发现一次考核一次。这条规矩写进维护手册的“操作纪律”里比写多少技术描述都有用。3.3 看板与声光报警的手动测试别等到真故障才试很多线是从开着机就没测过ANDON直到客户审核那天去看板才发现喇叭不响。手动测试这事不能等到真故障才做至少要安排每周一次。测试有两种方式一种是在PLC侧强制输出点来触发看板画面适合测试显示层和播报另一种是到工位按真实按钮适合测试完整链路。两者不能互相替代。我常用的测试流程是先挑一个离PLC最远的工位因为最远的工位线缆最长、端子最多最容易出问题。测试前和当班班长打好招呼确认这个工位当前没有在制件避免误触发停线。然后到工位按下呼叫按钮同时让另一人在看板下观察。顺序这样排看按钮指示灯是否亮看PLC输入点是否由0变1看看板分区是否变色听喇叭是否播报最后到数据库客户端查最近一条记录是否写入。全部符合说明从物理到追溯这一段是通的。强制输出测试看板时要注意一点测试前记录哪些点在强制测试结束后必须把所有强制点恢复并且PLC再切回RUN模式。我吃过亏测试完忘了释放一个看板分区的强制点结果半夜产线没人看板分区一直亮着第二天被班长投诉系统“灵异”。所以强制点一定要点名记录测完一个确认一个不能只凭记忆。这个测试如果发现某个分区不亮先查LED模块的排线再查对应PLC输出点别上来就换新的LED板。LED看板很多是模块化组装某一列不亮大概率是驱动芯片或者排线的问题整块换板成本高且不一定是出厂原配。手册里一般有“看板异常显示对照表”列了半亮、缺列、跳字分别对应什么故障这是最快的一条路。4. 维护窗口的配置变更改呼叫分区、超时时间和看板显示4.1 配置变更前先分清三层触发层、逻辑层、显示层有一次同事改看板上的超时时间只改了显示文字“1800”结果PLC里的定时器还是900秒于是系统实际900秒就升级了看板却倒计时到1800秒两边对不上。这个问题就出在没分清配置到底归属哪一层。ANDON系统的配置看似集中实则散在三层里层与层之间往往是单向依赖。触发层在工位IO侧包括按钮是常开还是常闭、是按一瞬间还是长按2秒触发、拉绳开关是否带自锁。这些配置大多在PLC的输入逻辑里写死改一处可能影响多个工位。逻辑层在PLC程序或服务器脚本负责判断呼叫类型、超时时间、升级规则、响应闭环逻辑是所有参数里最核心的一层。显示层在看板画面和语音播放条目只负责把逻辑层的结果画出来改它不影响实际判断但如果只改这一层就会出现“显示和实际不一致”的翻车现场。所以在动任何参数前先问一句这个值当前是哪个层在真正执行判断方法是做一个最小验证比如超时时间你到PLC在线监控里找到对应的定时器看它的设定值是多少或者到服务器看配置文件的当前项。两处都对不上就以逻辑层为准并把显示层同步改正。手册里如果有参数表先照着参数表核对没有就自己在doc里补一张备注上“本参数当前由PLC/服务器控制”避免下一个人重蹈覆辙。4.2 改呼叫超时时间和分区归属两种常见实现路径呼叫超时时间最常见的实现路径有两条PLC定时器方式和服务器配置方式。PLC定时器方式适合老项目逻辑都在PLC里。改法是用编程软件在线监控找到对应数据块或定时器变量修改预置值然后下载到CPU并切回RUN模式。注意在线下载动作不是没有风险的有些CPU型号在下载程序块时会瞬间停机正在运行的产线会跟着停。所以这个动作必须放在停线窗口或者提前确认CPU支持在线修改运行中的定时器值。我一般会先导出一份当前程序备份再操作下载成功后还要在触摸屏或看板上确认新值生效。服务器配置方式更常见于近几年的项目。ANDON服务器上跑一个数据采集服务它从PLC读状态同时按一个配置文件里的参数决定升级策略。配置文件可能叫config.ini、andon.properties或者类似的名字每个厂商习惯不同不要依赖名字猜内容按手册正文里标注的路径去找。改的时候先备份原文件再改目标行最后重启服务或触发热加载。以下是一段典型配置示例字段解释写在注释里; ANDON服务配置片段具体字段按现场手册为准 [timeout] normal_call900 ; 普通呼叫超时900秒未响应则升级 upgrade_call300 ; 升级后300秒仍未处理推送主管 [retry] voice_max_retry3 ; 语音播报最多重试3次 retry_interval10 ; 两次播报之间间隔10秒改完配置文件后一定要做一次验证在测试工位发起呼叫故意不处理它看系统是否按新的秒数升级再正常处理确认闭环时不会误报。注意修改了normal_call这类参数后旧的已发起呼叫不会因为配置变更而改变所以要等当前呼叫排空再测试不要拿一个已经挂起的异常来做对比。分区归属变更比超时时间更敏感。它决定的是每个工位在哪个看板分区、以什么颜色和文字显示。常见做法是把“工位编号→分区编号→看板寄存器地址”做成一张映射表存在PLC数据块或者看板组态软件里。如果只是把一个工位从A区挪到B区需要同时改PLC侧的映射表、看板侧的分区配置、服务器侧的报表归属三层必须同步否则会出现看板位置对了但数据库报表还记在旧分区的现象。变更前把三层映射表截图留底是最好的后悔药。4.3 配置备份与回滚维护手册的“后悔药”做配置变更最怕的是“改了但不知道改了什么”。所以我在维护条例里强制要求每一步变更都按“备份、修改、验证、记录”四步走。别嫌麻烦感到麻烦的时候特别容易出事。我先说备份。PLC程序用编程软件直接把整个工程上传保存服务器配置直接把文件复制一份文件名加上日期和小尾巴如“config_20250601_超时时间调整.bak”。这样一来哪怕后续改坏了也能快速恢复到改之前的状态。注意备份不仅要保存修改后的版本还要保留修改前的版本后者才是回滚要用的东西。很多实施公司交付时只给一份最终程序没有历史版本这是项目验收时的常见漏洞。然后是回滚动作。如果修改完发现验证不通过第一步是把当前版本导出留个“坏版”现场证据第二步用之前的备份覆盖回去第三步重新下载/重启第四步再做一次完整链路验证确认恢复原状。不要只在界面上把数值改回去有些服务的配置在启动时缓存了不改配置就重启等于白做。回滚后还要在手册或维护记录里写一笔“本次变更失败原因待查”避免后人再踩一遍。最后是文档同步。这条太容易漏了。改完一个参数无论最后用的是新值还是回滚的旧值都要更新《ANDON系统操作维护说明手册正文.doc》里的对应章节。如果手册是Word文件直接在正文里用修订模式改如果没有电子版至少在维护台账里写清楚。否则等下一任维护工程师接手他拿着一本旧手册去对系统会发现很多“对不上”的地方然后他把旧值当成标准值改回去系统又错一次这种连锁踩坑特别常见。5. ANDON系统常见故障排查从现象到根因的四个必查位置5.1 排查的通用顺序先物理后逻辑不要动不动就重启服务器ANDON系统故障排查最忌一上来就重启服务器。服务器重启大概率能解决部分症状但也会把现场日志和故障现场销毁等下一次同样故障发生时还是两眼一抹黑。我给自己定的顺序是物理层、逻辑层、网络层、应用层逐层排除。先说物理层。到现场先看按钮、拉绳有没有物理卡滞看IO模块通道指示灯是否和真实动作对应。很多故障的根源就是一根线断了或一个触点氧化而不是系统逻辑出错。例如“只有某个工位呼叫不亮”多半是这一路输入接线松动或开关坏了而不是PLC程序有问题。物理层排查靠眼睛和万用表最快也最准。物理层没问题再看逻辑层。打开PLC在线监控查看对应工位的输入点有没有信号输出点有没有被驱动。如果输入口没有信号说明问题还在物理层前面输入口有信号但输出不正常才轮到怀疑程序。同理超时升级依赖定时器和数据块逻辑顺序可以通过在线监控逐一看到不要靠猜。这个黑匣子一旦打开故障在哪一段就清楚了大半。网络层主要看PLC、看板控制器、服务器之间是否通信稳定。如果故障现象是“看板偶尔刷新慢、语音断断续续”大概率不是设备故障而是网络丢包。从维护电脑分别ping三个节点ping 30个包看丢包率和最大延时。丢包高就查交换机端口、网线接头和是不是有静电干扰必要时测一下双绞线的线序。应用层最后查。只有前几层都正常才去看服务器服务有没有起来、数据库连接是否正常、看板程序有没有死循环。很多人先把看板软件重启了问题暂时消失但过几天复发那是因为根因在物理层或网络层重启只是掩盖症状。排查顺序写进手册排故章节是对的但现场执行时更需要坚持。5.2 高频踩坑记录现象、原因、解决这里按“现象→原因→解决”写几条最常见的踩坑记录。每一条都是我用时间换来的写出来就是为了让你少走一点弯路。踩坑一拉绳拉了看板没反应但PLC输入点监控有动作。现象操作工拉动拉绳工位指示灯闪了一下但看板分区不变语音不播报。原因拉绳开关的当前位置处于“半触发”状态触点时通时断PLC虽然采集到了抖动信号但程序里的防抖逻辑没有判定为一次有效呼叫或者信号被误当成误触发而滤掉了。解决首先检查拉绳开关是否回到了正确位置如果开关老化造成触点接触不良就更换开关其次在PLC在线监控观察该点是否有水平偏低的情况比如DC24V电压不足信号在临界区跳动。现场最有效的处理是换一个新的拉绳开关并重新紧固端子而不是去改程序防抖时间。踩坑二看板一直显示红色按复位按钮没用。现象某个分区长时间亮红操作工说已经复位了但看板不恢复。原因复位按钮的常开触点接触不良或复位信号接到了PLC的另一个输入点按钮实际接的线和IO清单不一致还有可能是复位按钮在防尘罩里被压住导致信号被持续触发。解决先到PLC监控对应复位点看按按钮时输入点是否立即变化。不变化检查接线和触点变化了但看板不恢复则要看复位逻辑是否要求“呼叫必须在已超时或未超时状态”等额外条件。查完再决定是清IO接线还是更新IO清单文档。踩坑三语音播报只响第一句后面全部静音。现象每次呼叫喇叭播报第一条“XX工位呼叫”是正常的再往后的升级播报和提示音全都没有。原因语音播报服务的一次会话卡死或者播报音频文件被损坏/被误删也可能是语音板卡通道被上一次异常占用没有释放。解决先重启播报服务并清空队列再测试已损坏的音频文件是否能播放。这类问题优先查服务器上的语音服务日志日志里会记录是没找到文件还是设备打开失败对症处理比反复重启可靠。踩坑四看板正常、语音正常但数据库里没有当天的呼叫记录。现象现场看板信息都对晚上查统计报表却发现整天的记录缺失。原因数据库磁盘写满、连接池被耗尽或者是服务器时间跳变把记录写到了“其他日期”导致按当天查询查不到。解决先看数据库所在磁盘剩余空间清理日志和临时表再在数据库客户端直接查询最近一条记录的实际时间。如果记录存在但日期不对多半是服务器时间同步问题修正系统时钟并重启采集服务。这条坑很隐蔽因为它不影响实时生产直到做月报时才发现。5.3 日志怎么看硬件报警、看板心跳、数据库写入维护手册里通常会有一章讲日志但很多doc文件把这部分写在最后以至于没几个人认真看过。我在这里把它提前讲完。ANDON系统有三个日志源PLC诊断缓存区、看板/服务器运行日志、数据库事件表。三者的作用各不相同但排查时要配合使用。PLC诊断缓存区能看到硬件报警比如IO模块掉线、通道短路、CPU通信故障。用编程软件在线连接打开诊断缓存区先把报警列表截图再看看每个报警的时间戳。注意有些老PLC报警是英文简写不一定直接对应中文故障需要对照手册附录的报警代码表。如果报警记录显示IO模块掉线又恢复那多半是总线接头接触不良这个线索比看板日志更早暴露问题。看板/服务器运行日志记录的是通信心跳和业务事件。看板心跳日志通常会这样一行行刷下去2025-06-01 08:00:01 [INFO] heartbeat ok, board01, rssi-45dBm 2025-06-01 08:00:11 [WARN] heartbeat missing, 10s 2025-06-01 08:00:23 [ERROR] heartbeat lost, 30s, switch to PLC reconnect看到心跳持续正常说明看板和服务器通信链路没问题看到WARN或ERROR就说明网络层已经不稳定只是还没坏到完全断连。不要忽略这种“时好时坏”的心跳它往往是网线老化或交换机端口松动的先兆。数据库事件表则记录每一次呼叫的完整时间线查询最近一条记录能确认采集服务和数据库连接是否正常。如果看板正常但数据库没记录优先查这条链路的连接。6. 进阶验证用一个模拟呼叫验证整个ANDON链路是否健康6.1 模拟呼叫的完整步骤定期巡检只能发现“已经坏了”的问题而模拟呼叫能发现“快要坏了”的问题。我一般每季度做一次带记录的全链路模拟呼叫选择一条有代表性的产线在停线保养日进行。具体步骤很简单但每一步都对应一个检查目标。第一步提前通知当班班长和看板管理人员确认当前工位没有在制件避免真实呼叫造成停线误会。第二步挑选一个离PLC控制柜最远的工位线缆最长、端子最多最能反映出接线和信号衰减问题。第三步先断开按钮端子用一根短接线模拟按钮闭合或者直接按真实按钮看工位指示灯是否亮起。第四步让另一人在PLC侧监控输入点变化在看板侧观察颜色变化在服务器旁核对数据库记录和语音播报。第五步按正常流程复位确认看板恢复、记录闭环。第六步撤掉短接线和临时工具恢复现场接线确认工位可正常生产。模拟呼叫的记录表可以做成这样每次验证后由维护人员和当班班长各签一次字。这张表本身就形成了一个可追溯的文档比单纯在手册里写“系统正常”更有价值。观测点 | 预期结果 | 异常时动作 按钮/拉绳指示灯 | 按下即亮 | 查端子、换开关 PLC输入点 | 由0变1 | 查现场接线 看板分区 | 颜色变化且位置正确 | 查分区映射表 语音播报 | 播报清晰、无重复 | 查播报服务、喇叭 数据库记录 | 呼叫和闭环时间都有 | 查数据库连接、磁盘空间6.2 验证结果与周报模板做完模拟呼叫后我会把结果汇总成一张周报表格发到设备群和车间管理群。格式越简单越好重点是让人能一眼看到哪条线“未通过”以及为什么。表格列这样几项日期、线别、工位、呼叫类型、响应时长、闭环时长、验证结论、异常说明、操作人。其中响应时长是从呼叫发出到班组长到场的时间闭环时长是到复位的总时间。这两个值如果在模拟呼叫中与正常设定误差过大说明系统计时有问题而不是人的问题。周报里要特别标出“连续两次未通过”的项目。比如某个工位连续两次模拟呼叫时语音播报延迟超过10秒那即使当次还算正常也要安排更换喇叭或检查功放因为退化是渐进的过程不能等到彻底不响再处理。把验证记录和历史故障放在一起看能发现一些规律性的东西某条线的网络闪断总是在雨天出现某个区域的按钮总是三个月坏一批。这些规律写在维护手册的备注页里比任何报警都更能帮助你做预防性维护。我在这个项目上吃过最大的亏就是上线初期自信满满觉得系统刚调通不会有问题没做模拟呼叫就去忙别的。结果三个月后客户审核时其中一个工位的呼叫按钮线被机器人压断看板却因为用了一台带缓存的控制器还显示“已呼叫”一直到审核员去现场按按钮才发现根本没信号。后来我养成了一个习惯不管系统多稳定每次停线保养日都亲自做一次模拟呼叫并且把“模拟呼叫验证记录”当作维护手册的一部分归档。希望这篇记录能帮你把这个动作变成自己的习惯把那些“半坏不坏”的隐患在影响生产之前揪出来希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 10:43:59 · 阅读 1.2k ANDON系统操作维护指南：从信号链路到故障排查全解析
简介《ANDON系统操作维护说明手册》是一份面向汽车制造业生产线操作员、班组长及设备维护人员的专业文档系统讲解源自丰田生产系统的ANDON实时监控与快速响应机制。手册内容覆盖系统介绍、系统构成、总装车间ANDON系统使用方法详细说明了ANDON板显示内容、运行模式、SIP呼叫站操作流程及ANDON板内容的更改方法并结合上汽通用五菱项目实际场景展开有助于操作员掌握从呼叫发起、信号显示到停线联锁的完整工作逻辑。安全部分尤为细致针对触电风险、机械伤害、电缆损伤等常见隐患给出了禁止性操作提示与应急处理原则例如设备运行时不得打开控制柜门盖、禁止接触旋转部件、开启大屏前须断开220V电源等还强调了故障修复后的重启确认要求。资源为单个doc格式文档压缩包内仅1个文件、容量958KB内容集中适合快速查阅现有115人浏览学习。无论是新员工岗前培训还是现场作业中的安全自查这份手册都能提供清晰、可落地的操作依据。1. ANDON系统操作维护说明手册一张看板背后要维护的是一条完整的异常响应链车间里最怕的不是ANDON系统坏了而是它“半坏不坏”按钮按下去看板没亮喇叭不响但PLC又好像收到了信号。《ANDON系统操作维护说明手册正文.doc》这类文档就是为这种现场问题存在的。它不教你建系统而是把信号怎么从工位走到看板、中间经过哪些环节、每环看什么数、坏了先查谁按可执行逻辑写清楚。适合倒班设备员、新接手产线的维护工程师、跟线实施顾问读。这篇记录沿“链路是什么、日常怎么操作、配置怎么改、故障怎么排”的顺序把手册里最容易被跳过但最值钱的部分拆出来。2. ANDON系统到底在维护什么从信号链路到看板刷新的四个组成2.1 安灯系统的典型链路呼叫信号怎么从工位走到看板ANDON最早是丰田生产方式里的安灯拉绳但现在的ANDON系统早就不是一根绳加一块板子了。我在现场见过的项目普遍由四个部分组成呼叫终端按钮、拉绳、脚踏开关、采集与逻辑层现场IO模块、PLC或者少数直接用服务器采集、显示与提醒层LED看板、工控机屏幕、语音播报器、数据与追溯层ANDON服务器、数据库、Web报表。维护手册整本就在讲这四层之间怎么传输信号、怎么判断故障在哪一层。一条典型的呼叫链路是这样走的工位操作工按下呼叫按钮24V直流信号进到最近的IO模块IO模块通过PROFINET、CC-Link、EtherCAT这类总线把点位上送给PLCPLC按程序做防抖处理、判断呼叫类型和工位归属然后在数据块里置位对应的“呼叫请求”看板控制器和服务器通过工业以太网轮询这个数据块看到变化后驱动LED看板变颜色、喇叭播报、服务器往数据库写一条事件记录。注意这里每一步都有可能是故障点而手册的价值就是把这些故障点显性化。为什么中间一定要经过PLC而不是直接把按钮接到看板上因为直接接看板只解决了“显示”但做不到超时升级、多级呼叫、跨线统计、按班次报表这些生产管理功能。PLC加了之后维护人员手里多了一个可以强制输入、强制输出、在线监控的逻辑分析口。但也多了一个黑匣子程序版本不同、数据块命名不同、注释不全都会让“信号明明进来了看板却不动”这种问题变得很难查。所以我在给维修班做培训时第一句话永远是你能把链路画出来故障就已经解决一半。画不出来就只能靠换备件碰运气那是玄学。维护手册正文里通常会给一张简化链路图如果你拿到的doc文件里没有图就自己打开PLC在线监控和看板通讯状态把每一段的信号状态抄在一张纸上这也算把缺失的文档补上了。2.2 手册里最该先看的三张图网络拓扑、IO清单、看板地址表拿《ANDON系统操作维护说明手册正文.doc》这种文档不要从头一页页读。先找三张表找到了再读别的找不到就去现场对照着读程序注释。这三张图对应着你日常维护的三个问题设备在哪、信号在哪、显示在哪。第一张是网络拓扑图。它告诉你PLC、IO站、看板控制器、ANDON服务器、工程师站各自在哪个IP段交换机端口够不够是否跨了网段。排查“看板和PLC偶尔断连”这种问题首先就是拿一张拓扑图从一个节点ping到另一个节点。常见故障里很大比例不是设备坏了而是二期项目扩容时把网段改了维护手册没有同步更新导致后来的人拿着旧文档白查半天。第二张是IO清单。生产线上几台设备、每个工位有哪些按钮和拉绳、对应的PLC输入点是什么、输出点控制哪个指示灯全在这一张表里。这张表通常是在Word里嵌了一个Excel表格缩得很小打印出来根本看不清。我的习惯是把它单独导出来放大贴在PLC柜门内侧再备份一份到手机。很多“看板一直亮红灯”的问题打开IO清单一查对应PLC输入点能监控到信号一直在那就是复位信号没到而不是看板的问题。第三张是看板地址表。LED看板或者工控机看板画面每个分区显示哪条产线、哪个工位、哪个呼叫类型颜色变化对应的数据库字地址是什么都在这里。维护时最常遇到“看板显示的位置和实际工位反了”或者“呼叫类型颜色错乱”多半是地址映射表被改过但手册没更新。所以我强调手册不是拿来供奉的是拿来和你现场的PLC程序、看板组态一件件核对的。这三张图核对完你基本就能回答“ANDON系统操作维护”这个标题里的大半问题。剩下的日常工作就是基于这些地址表去做检查、复位和排故而不是靠老师傅的记忆。2.3 把操作维护手册拆成现场巡检表四层对应四个自检项手册写得很厚但现场一个月真正能用到的动作可能就十几个。我一般会把手册压缩成一张A4巡检表做成塑封卡片挂在控制柜上。巡检表按前面说的四个层来分每一层都有明确的判断标准和处置动作这样倒班员工也能看懂。物理层检查工位拉绳、按钮、脚踏开关外观是否完好按下后是否能听到微动开关“嗒”的一声松手后是否自动复位。拉绳开关如果带自锁拉出来之后必须手动旋转复位这个动作新手最容易漏导致看板一直处于呼叫状态。控制层观察PLC面板和IO模块指示灯RUN灯常亮ERR灯和某个通道的指示灯不应该以异常方式闪烁。如果PLC面板上有BAT灯亮说明电池电量低了这个不是马上故障但会丢程序必须安排更换。网络层从维护电脑ping服务器和看板控制器的地址丢包率应该是0每一次ping的延时都应该很稳定如果时好时坏重点排查网线接头和交换机端口车间的叉车压线和老鼠啃线是重灾区。显示层看板是否有心跳指示某些系统在看板角落有个小点每隔几秒闪一下喇叭的音量旋钮是否被误调播报是否清楚。巡检频次要根据产线运行状态定。连续生产的线交接班一次每两小时对典型工位抽查一次单班生产的线开线前全部检查中午休息做一次语音测试。很多系统的问题不是瞬间坏的而是慢慢退化比如喇叭音量越来越小、看板LED开始有点缺、拉绳微动开关接触电阻变大这些用巡检表能提前发现而不是等到“响铃不良”被车间投诉。这里还要补一句关于doc文件版本管理的提醒手册正文.doc往往不是一成不变的。你改过一次PLC程序、调过一次超时时间就一定要在手册里更新对应的章节。否则半年后这份手册就会变成和你现场系统脱节的“僵尸文档”照着做反而会误操作。维护手册的维护本身就是维护工作的一部分。3. 日常操作从交接班检查到异常呼叫的标准动作3.1 交接班检查为什么先查“感知层”而不是查软件我见过不少交接班只做一件事看一下看板有没有电。看板一亮就觉得系统没问题然后十点喇叭不响才发现看板虽然是亮的但语音线路早就断了。交接班检查的核心应该是“信号走得通”而不是“屏幕亮不亮”。因为看板亮只代表显示层上电而物理层的按钮、拉绳、喇叭可能都是坏的。交接班检查我按下面这张表来做。它不算长但每一项都对应一个后续故障风险。检查时最好两个人配合一个在工位按按钮一个在看板下看变化这样链路才能真正从一头通到另一头。检查类别 | 检查点 | 合格标准 | 异常处置 物理信号 | 各工位按钮/拉绳/脚踏 | 按下后工位指示灯亮弹回灵活 | 调整角度、清洁触点、更换开关 PLC状态 | CPU与IO模块面板 | RUN灯常亮无ERR灯无BAT灯 | 查看CPU诊断缓存区预约停机换电池 看板显示 | 上电自检画面 | 显示版本号、线别、日期时间正确 | 记录版本与服务器配置比对必要时重新同步 语音播报 | 抽查两个远端喇叭 | 播报声音清晰、无破音、音量足够 | 调节功放音量检查喇叭接线 网络通信 | 维护电脑ping服务器/看板 | 丢包率0%延时稳定 | 更换网线、重启交换机端口为什么要先查这些感知层因为感知层的故障往往不影响其他功能看板还能显示上一分钟的历史数据但新的呼叫进不来这种“假活”状态最容易误导人。手册通常会把“先物理、后逻辑、再软件”写在排故总则里实际执行时最容易被跳过因为物理检查要走到现场而看软件在办公室就能完成。你不走到按钮旁边就永远不知道那个拉绳手柄被卡在了半程位置。交班时还有一个容易被忽略的动作把夜班发生的故障和临时改过的参数在本子上交接。很多ANDON系统没有完善的报警推送夜班处理问题的人可能直接按下PLC某个点强制复位了却没有告诉白班。交接班如果只看系统当前状态就会漏掉“某个保护点被强制”这种潜在风险。所以我要求倒班员工交班时必须把动过的点位写下来哪怕只在微信群里发一句话也行。3.2 异常呼叫、响应闭环与复位的标准动作正常生产时操作工发现物料、设备或质量异常会拉动工位旁的拉绳或按下呼叫按钮ANDON系统的标准响应是这样一步步走的第一步呼叫终端触发工位信号灯亮起表示这个工位已经发出请求。第二步看板对应分区变红或变黄多数系统里红色代表停线类呼叫黄色代表质量提示绿色代表正常运行。第三步语音播报“XX工位物料呼叫”让班组长和物流人员即使不看板也知道去哪。第四步班组长或钳工到位处理问题。第五步处理完成后由该工位操作工或现场组长按复位按钮或将拉绳开关旋回原位。第六步看板分区恢复正常系统在数据库里记下“呼叫时刻、响应时刻、闭环时刻”这条完整记录。这里最关键的参数是“响应超时时间”。我经手的项目里普通呼叫超时一般设60到180秒超时后看板从黄色变红色语音会再播报一遍有的系统还会自动发短信给主管。超时值太长异常处理会拖沓太短系统频繁升级会变成“狼来了”。这个值在手册里通常叫“响应时间设定”但具体放在PLC还是服务器脚本里每个项目不一样。改它之前一定要先确认是哪个逻辑层控制。还有一件关于复位的原则复位操作必须在发出呼叫的工位附近完成。很多维护人员看着看板分区红了就跑到看板控制柜前按一个总复位这样虽然画面恢复了但问题可能根本没解决系统却认为已经闭环了。这是最典型的误操作等于把生产异常记录给抹掉了。所以我在制度上规定看板柜总复位只用于系统联调生产期间严禁用发现一次考核一次。这条规矩写进维护手册的“操作纪律”里比写多少技术描述都有用。3.3 看板与声光报警的手动测试别等到真故障才试很多线是从开着机就没测过ANDON直到客户审核那天去看板才发现喇叭不响。手动测试这事不能等到真故障才做至少要安排每周一次。测试有两种方式一种是在PLC侧强制输出点来触发看板画面适合测试显示层和播报另一种是到工位按真实按钮适合测试完整链路。两者不能互相替代。我常用的测试流程是先挑一个离PLC最远的工位因为最远的工位线缆最长、端子最多最容易出问题。测试前和当班班长打好招呼确认这个工位当前没有在制件避免误触发停线。然后到工位按下呼叫按钮同时让另一人在看板下观察。顺序这样排看按钮指示灯是否亮看PLC输入点是否由0变1看看板分区是否变色听喇叭是否播报最后到数据库客户端查最近一条记录是否写入。全部符合说明从物理到追溯这一段是通的。强制输出测试看板时要注意一点测试前记录哪些点在强制测试结束后必须把所有强制点恢复并且PLC再切回RUN模式。我吃过亏测试完忘了释放一个看板分区的强制点结果半夜产线没人看板分区一直亮着第二天被班长投诉系统“灵异”。所以强制点一定要点名记录测完一个确认一个不能只凭记忆。这个测试如果发现某个分区不亮先查LED模块的排线再查对应PLC输出点别上来就换新的LED板。LED看板很多是模块化组装某一列不亮大概率是驱动芯片或者排线的问题整块换板成本高且不一定是出厂原配。手册里一般有“看板异常显示对照表”列了半亮、缺列、跳字分别对应什么故障这是最快的一条路。4. 维护窗口的配置变更改呼叫分区、超时时间和看板显示4.1 配置变更前先分清三层触发层、逻辑层、显示层有一次同事改看板上的超时时间只改了显示文字“1800”结果PLC里的定时器还是900秒于是系统实际900秒就升级了看板却倒计时到1800秒两边对不上。这个问题就出在没分清配置到底归属哪一层。ANDON系统的配置看似集中实则散在三层里层与层之间往往是单向依赖。触发层在工位IO侧包括按钮是常开还是常闭、是按一瞬间还是长按2秒触发、拉绳开关是否带自锁。这些配置大多在PLC的输入逻辑里写死改一处可能影响多个工位。逻辑层在PLC程序或服务器脚本负责判断呼叫类型、超时时间、升级规则、响应闭环逻辑是所有参数里最核心的一层。显示层在看板画面和语音播放条目只负责把逻辑层的结果画出来改它不影响实际判断但如果只改这一层就会出现“显示和实际不一致”的翻车现场。所以在动任何参数前先问一句这个值当前是哪个层在真正执行判断方法是做一个最小验证比如超时时间你到PLC在线监控里找到对应的定时器看它的设定值是多少或者到服务器看配置文件的当前项。两处都对不上就以逻辑层为准并把显示层同步改正。手册里如果有参数表先照着参数表核对没有就自己在doc里补一张备注上“本参数当前由PLC/服务器控制”避免下一个人重蹈覆辙。4.2 改呼叫超时时间和分区归属两种常见实现路径呼叫超时时间最常见的实现路径有两条PLC定时器方式和服务器配置方式。PLC定时器方式适合老项目逻辑都在PLC里。改法是用编程软件在线监控找到对应数据块或定时器变量修改预置值然后下载到CPU并切回RUN模式。注意在线下载动作不是没有风险的有些CPU型号在下载程序块时会瞬间停机正在运行的产线会跟着停。所以这个动作必须放在停线窗口或者提前确认CPU支持在线修改运行中的定时器值。我一般会先导出一份当前程序备份再操作下载成功后还要在触摸屏或看板上确认新值生效。服务器配置方式更常见于近几年的项目。ANDON服务器上跑一个数据采集服务它从PLC读状态同时按一个配置文件里的参数决定升级策略。配置文件可能叫config.ini、andon.properties或者类似的名字每个厂商习惯不同不要依赖名字猜内容按手册正文里标注的路径去找。改的时候先备份原文件再改目标行最后重启服务或触发热加载。以下是一段典型配置示例字段解释写在注释里; ANDON服务配置片段具体字段按现场手册为准 [timeout] normal_call900 ; 普通呼叫超时900秒未响应则升级 upgrade_call300 ; 升级后300秒仍未处理推送主管 [retry] voice_max_retry3 ; 语音播报最多重试3次 retry_interval10 ; 两次播报之间间隔10秒改完配置文件后一定要做一次验证在测试工位发起呼叫故意不处理它看系统是否按新的秒数升级再正常处理确认闭环时不会误报。注意修改了normal_call这类参数后旧的已发起呼叫不会因为配置变更而改变所以要等当前呼叫排空再测试不要拿一个已经挂起的异常来做对比。分区归属变更比超时时间更敏感。它决定的是每个工位在哪个看板分区、以什么颜色和文字显示。常见做法是把“工位编号→分区编号→看板寄存器地址”做成一张映射表存在PLC数据块或者看板组态软件里。如果只是把一个工位从A区挪到B区需要同时改PLC侧的映射表、看板侧的分区配置、服务器侧的报表归属三层必须同步否则会出现看板位置对了但数据库报表还记在旧分区的现象。变更前把三层映射表截图留底是最好的后悔药。4.3 配置备份与回滚维护手册的“后悔药”做配置变更最怕的是“改了但不知道改了什么”。所以我在维护条例里强制要求每一步变更都按“备份、修改、验证、记录”四步走。别嫌麻烦感到麻烦的时候特别容易出事。我先说备份。PLC程序用编程软件直接把整个工程上传保存服务器配置直接把文件复制一份文件名加上日期和小尾巴如“config_20250601_超时时间调整.bak”。这样一来哪怕后续改坏了也能快速恢复到改之前的状态。注意备份不仅要保存修改后的版本还要保留修改前的版本后者才是回滚要用的东西。很多实施公司交付时只给一份最终程序没有历史版本这是项目验收时的常见漏洞。然后是回滚动作。如果修改完发现验证不通过第一步是把当前版本导出留个“坏版”现场证据第二步用之前的备份覆盖回去第三步重新下载/重启第四步再做一次完整链路验证确认恢复原状。不要只在界面上把数值改回去有些服务的配置在启动时缓存了不改配置就重启等于白做。回滚后还要在手册或维护记录里写一笔“本次变更失败原因待查”避免后人再踩一遍。最后是文档同步。这条太容易漏了。改完一个参数无论最后用的是新值还是回滚的旧值都要更新《ANDON系统操作维护说明手册正文.doc》里的对应章节。如果手册是Word文件直接在正文里用修订模式改如果没有电子版至少在维护台账里写清楚。否则等下一任维护工程师接手他拿着一本旧手册去对系统会发现很多“对不上”的地方然后他把旧值当成标准值改回去系统又错一次这种连锁踩坑特别常见。5. ANDON系统常见故障排查从现象到根因的四个必查位置5.1 排查的通用顺序先物理后逻辑不要动不动就重启服务器ANDON系统故障排查最忌一上来就重启服务器。服务器重启大概率能解决部分症状但也会把现场日志和故障现场销毁等下一次同样故障发生时还是两眼一抹黑。我给自己定的顺序是物理层、逻辑层、网络层、应用层逐层排除。先说物理层。到现场先看按钮、拉绳有没有物理卡滞看IO模块通道指示灯是否和真实动作对应。很多故障的根源就是一根线断了或一个触点氧化而不是系统逻辑出错。例如“只有某个工位呼叫不亮”多半是这一路输入接线松动或开关坏了而不是PLC程序有问题。物理层排查靠眼睛和万用表最快也最准。物理层没问题再看逻辑层。打开PLC在线监控查看对应工位的输入点有没有信号输出点有没有被驱动。如果输入口没有信号说明问题还在物理层前面输入口有信号但输出不正常才轮到怀疑程序。同理超时升级依赖定时器和数据块逻辑顺序可以通过在线监控逐一看到不要靠猜。这个黑匣子一旦打开故障在哪一段就清楚了大半。网络层主要看PLC、看板控制器、服务器之间是否通信稳定。如果故障现象是“看板偶尔刷新慢、语音断断续续”大概率不是设备故障而是网络丢包。从维护电脑分别ping三个节点ping 30个包看丢包率和最大延时。丢包高就查交换机端口、网线接头和是不是有静电干扰必要时测一下双绞线的线序。应用层最后查。只有前几层都正常才去看服务器服务有没有起来、数据库连接是否正常、看板程序有没有死循环。很多人先把看板软件重启了问题暂时消失但过几天复发那是因为根因在物理层或网络层重启只是掩盖症状。排查顺序写进手册排故章节是对的但现场执行时更需要坚持。5.2 高频踩坑记录现象、原因、解决这里按“现象→原因→解决”写几条最常见的踩坑记录。每一条都是我用时间换来的写出来就是为了让你少走一点弯路。踩坑一拉绳拉了看板没反应但PLC输入点监控有动作。现象操作工拉动拉绳工位指示灯闪了一下但看板分区不变语音不播报。原因拉绳开关的当前位置处于“半触发”状态触点时通时断PLC虽然采集到了抖动信号但程序里的防抖逻辑没有判定为一次有效呼叫或者信号被误当成误触发而滤掉了。解决首先检查拉绳开关是否回到了正确位置如果开关老化造成触点接触不良就更换开关其次在PLC在线监控观察该点是否有水平偏低的情况比如DC24V电压不足信号在临界区跳动。现场最有效的处理是换一个新的拉绳开关并重新紧固端子而不是去改程序防抖时间。踩坑二看板一直显示红色按复位按钮没用。现象某个分区长时间亮红操作工说已经复位了但看板不恢复。原因复位按钮的常开触点接触不良或复位信号接到了PLC的另一个输入点按钮实际接的线和IO清单不一致还有可能是复位按钮在防尘罩里被压住导致信号被持续触发。解决先到PLC监控对应复位点看按按钮时输入点是否立即变化。不变化检查接线和触点变化了但看板不恢复则要看复位逻辑是否要求“呼叫必须在已超时或未超时状态”等额外条件。查完再决定是清IO接线还是更新IO清单文档。踩坑三语音播报只响第一句后面全部静音。现象每次呼叫喇叭播报第一条“XX工位呼叫”是正常的再往后的升级播报和提示音全都没有。原因语音播报服务的一次会话卡死或者播报音频文件被损坏/被误删也可能是语音板卡通道被上一次异常占用没有释放。解决先重启播报服务并清空队列再测试已损坏的音频文件是否能播放。这类问题优先查服务器上的语音服务日志日志里会记录是没找到文件还是设备打开失败对症处理比反复重启可靠。踩坑四看板正常、语音正常但数据库里没有当天的呼叫记录。现象现场看板信息都对晚上查统计报表却发现整天的记录缺失。原因数据库磁盘写满、连接池被耗尽或者是服务器时间跳变把记录写到了“其他日期”导致按当天查询查不到。解决先看数据库所在磁盘剩余空间清理日志和临时表再在数据库客户端直接查询最近一条记录的实际时间。如果记录存在但日期不对多半是服务器时间同步问题修正系统时钟并重启采集服务。这条坑很隐蔽因为它不影响实时生产直到做月报时才发现。5.3 日志怎么看硬件报警、看板心跳、数据库写入维护手册里通常会有一章讲日志但很多doc文件把这部分写在最后以至于没几个人认真看过。我在这里把它提前讲完。ANDON系统有三个日志源PLC诊断缓存区、看板/服务器运行日志、数据库事件表。三者的作用各不相同但排查时要配合使用。PLC诊断缓存区能看到硬件报警比如IO模块掉线、通道短路、CPU通信故障。用编程软件在线连接打开诊断缓存区先把报警列表截图再看看每个报警的时间戳。注意有些老PLC报警是英文简写不一定直接对应中文故障需要对照手册附录的报警代码表。如果报警记录显示IO模块掉线又恢复那多半是总线接头接触不良这个线索比看板日志更早暴露问题。看板/服务器运行日志记录的是通信心跳和业务事件。看板心跳日志通常会这样一行行刷下去2025-06-01 08:00:01 [INFO] heartbeat ok, board01, rssi-45dBm 2025-06-01 08:00:11 [WARN] heartbeat missing, 10s 2025-06-01 08:00:23 [ERROR] heartbeat lost, 30s, switch to PLC reconnect看到心跳持续正常说明看板和服务器通信链路没问题看到WARN或ERROR就说明网络层已经不稳定只是还没坏到完全断连。不要忽略这种“时好时坏”的心跳它往往是网线老化或交换机端口松动的先兆。数据库事件表则记录每一次呼叫的完整时间线查询最近一条记录能确认采集服务和数据库连接是否正常。如果看板正常但数据库没记录优先查这条链路的连接。6. 进阶验证用一个模拟呼叫验证整个ANDON链路是否健康6.1 模拟呼叫的完整步骤定期巡检只能发现“已经坏了”的问题而模拟呼叫能发现“快要坏了”的问题。我一般每季度做一次带记录的全链路模拟呼叫选择一条有代表性的产线在停线保养日进行。具体步骤很简单但每一步都对应一个检查目标。第一步提前通知当班班长和看板管理人员确认当前工位没有在制件避免真实呼叫造成停线误会。第二步挑选一个离PLC控制柜最远的工位线缆最长、端子最多最能反映出接线和信号衰减问题。第三步先断开按钮端子用一根短接线模拟按钮闭合或者直接按真实按钮看工位指示灯是否亮起。第四步让另一人在PLC侧监控输入点变化在看板侧观察颜色变化在服务器旁核对数据库记录和语音播报。第五步按正常流程复位确认看板恢复、记录闭环。第六步撤掉短接线和临时工具恢复现场接线确认工位可正常生产。模拟呼叫的记录表可以做成这样每次验证后由维护人员和当班班长各签一次字。这张表本身就形成了一个可追溯的文档比单纯在手册里写“系统正常”更有价值。观测点 | 预期结果 | 异常时动作 按钮/拉绳指示灯 | 按下即亮 | 查端子、换开关 PLC输入点 | 由0变1 | 查现场接线 看板分区 | 颜色变化且位置正确 | 查分区映射表 语音播报 | 播报清晰、无重复 | 查播报服务、喇叭 数据库记录 | 呼叫和闭环时间都有 | 查数据库连接、磁盘空间6.2 验证结果与周报模板做完模拟呼叫后我会把结果汇总成一张周报表格发到设备群和车间管理群。格式越简单越好重点是让人能一眼看到哪条线“未通过”以及为什么。表格列这样几项日期、线别、工位、呼叫类型、响应时长、闭环时长、验证结论、异常说明、操作人。其中响应时长是从呼叫发出到班组长到场的时间闭环时长是到复位的总时间。这两个值如果在模拟呼叫中与正常设定误差过大说明系统计时有问题而不是人的问题。周报里要特别标出“连续两次未通过”的项目。比如某个工位连续两次模拟呼叫时语音播报延迟超过10秒那即使当次还算正常也要安排更换喇叭或检查功放因为退化是渐进的过程不能等到彻底不响再处理。把验证记录和历史故障放在一起看能发现一些规律性的东西某条线的网络闪断总是在雨天出现某个区域的按钮总是三个月坏一批。这些规律写在维护手册的备注页里比任何报警都更能帮助你做预防性维护。我在这个项目上吃过最大的亏就是上线初期自信满满觉得系统刚调通不会有问题没做模拟呼叫就去忙别的。结果三个月后客户审核时其中一个工位的呼叫按钮线被机器人压断看板却因为用了一台带缓存的控制器还显示“已呼叫”一直到审核员去现场按按钮才发现根本没信号。后来我养成了一个习惯不管系统多稳定每次停线保养日都亲自做一次模拟呼叫并且把“模拟呼叫验证记录”当作维护手册的一部分归档。希望这篇记录能帮你把这个动作变成自己的习惯把那些“半坏不坏”的隐患在影响生产之前揪出来希望帮到你。本文还有配套的精品资源点击获取