简介三菱MES编程软件面向自动化工程师与生产管理人员围绕QJ71MES96模块提供配置、编程与调试支持用于打通MES系统与三菱PLC之间的数据交互实现生产状态、设备运行数据与异常报警的实时采集反馈。压缩包共113个文件约39.27MB以exe安装程序、cab压缩包、dll动态库、dat数据文件、ini配置项及ins安装脚本为主另含pdf手册、示例代码与驱动组件覆盖安装、配置到二次开发的完整链路。软件支持梯形图、结构文本等编程语言可配合Q系列或FX系列PLC及CC-Link、工业以太网构建自动化控制系统。目前已有505人学习下载适合从事自动化工程、生产管理的人员参考帮助快速理解QJ71MES96与MES对接方式掌握定制化应用开发与现场排错思路。1. 三菱MES编程软件从产线数据孤岛到制造执行系统的落地路径很多做产线自动化的朋友第一次听到“三菱MES编程软件”这个词脑子里浮现的往往是GX Works或者GT Designer觉得PLC编程那一套搬过来就能用。实际干过一两个车间项目之后你会发现MES这一层要解决的根本不是梯形图逻辑而是“这条线今天做了多少、良率多少、设备为什么停了、下一张工单该派给谁”这类问题。三菱MES编程软件通常指围绕三菱电机FA产品体系PLC、GOT触摸屏、伺服、机器人做制造执行层开发时用到的一整套工具链和接口方案核心是把底层设备数据通过MC协议、OPC UA或者数据库中间表采集上来再在MES侧做排产、追溯、SPC和看板。它适合两类人一是已经能独立调试三菱PLC、想往上做信息化集成的电气工程师二是做上位机或后端开发、被派来对接产线数据但不懂FA侧协议的软件工程师。这篇文章不讲空泛概念直接按“数据怎么采、程序怎么写、坑怎么避”的顺序拆开讲让你看完能搭出一个最小可用的采集与执行闭环。2. 三菱MES编程软件的数据采集层MC协议与OPC UA怎么选2.1 先搞清楚MES要的数据到底在哪一层产线数据不是只有PLC寄存器。一个典型的装配工位数据至少分布在四个位置PLC的D寄存器和M继电器实时状态、节拍、报警码、GOT触摸屏的配方和报警历史操作工手动录入的批次号、不良原因、伺服或机器人的位置与扭矩曲线工艺参数追溯、以及扫码枪或RFID读头通过串口或以太网送来的条码。MES编程软件要做的第一件事是决定哪些数据走实时通道、哪些走批量通道。实时通道要求秒级甚至百毫秒级刷新比如设备运行状态、当前工单产量批量通道可以分钟级或事件触发比如每完成一件产品上传一次完整工艺参数。我一般的做法是状态类走MC协议直读追溯类走数据库中间表或消息队列配方类走GOT的配方文件导出接口。这样分层之后MES侧不会因为一个扫码枪断线就整个看板卡死。2.2 MC协议直连PLC的最小可用代码三菱MC协议MELSEC Communication Protocol分1E帧、3E帧、4E帧现在新项目基本用3E帧走TCP。下面这段Python用pymcprotocol库读D100开始的10个字和M100开始的8个位是最小采集循环的骨架。import pymcprotocol import time # 连接三菱PLC3E帧端口通常用5000或1025 plc pymcprotocol.Type3E() plc.connect(192.168.1.10, 5000) # 读D100~D109共10个字字单位 word_data plc.batchread_wordunits(headdeviceD100, readsize10) # 读M100~M107共8个位位单位 bit_data plc.batchread_bitunits(headdeviceM100, readsize8) # 解析D100是当前产量D101是目标产量M100是运行标志 current_qty word_data[0] target_qty word_data[1] running bit_data[0] print(f产量 {current_qty}/{target_qty} 运行状态 {running}) plc.close()逻辑说明batchread_wordunits按字批量读一次请求拿多个寄存器比逐个读快一个数量级batchread_bitunits按位读适合状态标志。参数上headdevice写起始地址readsize写数量注意三菱地址格式是字母数字不要写成D0100这种带前导零的形式部分型号会报错。如果PLC是Q系列或L系列3E帧二进制码效率最高如果是FX5U内置以太网口也支持3E帧但连接数有限建议采集程序保持长连接而不是每次轮询都重连。实际产线上我会把采集周期设在200ms到500ms之间再快对MES业务没意义反而增加PLC的通信负荷。2.3 OPC UA方案适合什么场景当产线里不只有三菱PLC还有西门子、欧姆龙或者第三方仪表时MC协议直读就不划算了。常见做法是在边缘侧跑一个OPC UA Server把三菱PLC的数据通过MC协议先汇聚到Server的地址空间再让MES统一走OPC UA订阅。三菱自家的OPC UA Server产品或者第三方KEPServerEX都支持MC协议驱动。配置时注意三个参数订阅发布间隔Publishing Interval建议设100ms到1000ms采样间隔Sampling Interval可以比发布间隔小队列深度Queue Size至少给10否则网络抖动时会丢数据。OPC UA的好处是带时间戳和质量码MES侧能区分“数据是0”和“数据没采到”这在做OEE统计时非常关键。缺点是授权费用和额外一跳延迟如果整条线全是三菱设备MC协议直读更轻。3. 三菱MES编程软件的工单执行与追溯从排产到过站的程序实现3.1 工单下发与PLC侧配方切换的联动MES排产之后工单要落到产线上。最土但最稳的做法是MES写一张中间表PLC侧或者边缘网关轮询这张表发现新工单就把配方号写到PLC的D寄存器PLC程序再根据配方号调用对应的参数块。下面这段SQL是中间表的最小结构字段不多但够用。CREATE TABLE mes_work_order ( wo_id VARCHAR(32) PRIMARY KEY, -- 工单号 product_code VARCHAR(32) NOT NULL, -- 产品编码 recipe_no INT NOT NULL, -- 配方号对应PLC的D200 target_qty INT NOT NULL, -- 目标产量 status TINYINT DEFAULT 0, -- 0待下发 1已下发 2生产中 3已完成 create_time DATETIME DEFAULT CURRENT_TIMESTAMP, dispatch_time DATETIME -- 下发时间 );逻辑说明status字段是状态机核心边缘网关只查status0的记录读到后把recipe_no和target_qty写入PLC对应寄存器然后把status改成1并回写dispatch_time。这里有个血泪经验不要用MES直接写PLC寄存器中间一定要有状态表做缓冲。曾经有个项目MES和PLC直连网络闪断一次工单就丢了操作工以为没下发实际PLC已经收到一半参数做出来一批废品。参数上recipe_no建议用整数而不是字符串PLC侧解析简单target_qty用32位整数别用16位产量大的线一天就超65535。3.2 过站追溯的数据模型与写入时机追溯的核心是“每一件产品在每一个工位留下了什么记录”。最小模型三张表产品序列号表、过站记录表、工艺参数表。过站记录表在扫码枪读到条码、PLC给出工位完成信号时写入。写入时机很讲究不要等产品离开工位再写要在关键工艺动作完成的瞬间写否则一旦卡料这条记录就丢了。下面这段Python是过站写入的伪代码逻辑。def on_station_complete(serial_no, station_id, plc_data): # plc_data包含扭矩、压力、时间等工艺值 record { serial_no: serial_no, station_id: station_id, result: PASS if plc_data[ok_bit] else FAIL, torque: plc_data[torque], timestamp: datetime.now() } # 先写本地缓存再异步同步到MES数据库 local_cache.append(record) if len(local_cache) 50: batch_insert_to_mes(local_cache) local_cache.clear()逻辑说明本地缓存加批量写入是为了防止MES数据库短暂不可用导致产线停线。参数上批量大小50是经验值太小频繁写库太大断电丢数据多。result字段根据PLC的OK位判断不要靠MES侧再算一遍PLC的判断是最实时的。注意serial_no的格式要统一扫码枪读出来的字符串可能带回车换行入库前必须strip否则追溯查询时匹配不上。3.3 与GOT触摸屏的报警历史对接操作工在GOT上处理的报警MES也要拿到。三菱GOT有个报警历史文件可以通过FTP或者SD卡导出格式是CSV。常见做法是边缘网关定时用FTP拉取GOT的报警历史目录解析CSV后写入MES的报警表。CSV字段一般包括报警编号、发生时间、恢复时间、确认时间。解析时注意时间格式GOT导出的时间可能是“2025/01/15 08:30:00”这种入库前转成标准DATETIME。报警编号要和MES侧的报警字典表关联才能显示中文描述。这个环节的坑是GOT的FTP服务默认可能没开需要在GOT设置里手动启用而且同时连接数有限采集程序用完就断不要保持长连接。4. 三菱MES编程软件的避坑与排查五条产线实录4.1 现象MC协议读回来的数据全是0原因PLC侧没有开放MC协议或者连接的是另一个网口。三菱Q系列通常有两个以太网口一个用于编程和HMI一个用于上位机通信IP网段可能不同。解决用PLC编程软件在线确认以太网参数看“开放设置”里有没有把MC协议勾上端口号是否和代码里一致。另外FX5U的内置以太网口需要先在参数里设置“对象设备连接配置”把SLMP即MC协议使能。4.2 现象采集程序跑几天后PLC通信变慢甚至超时原因采集频率太高或者没有做异常重连PLC的通信缓冲区被占满。解决把采集周期从50ms放宽到200ms以上在代码里加心跳和超时重连连接断开后等3秒再重连不要死循环立刻重试。另外批量读的时候一次不要超过960个字这是3E帧单次请求的上限超了要分多次。4.3 现象工单切换时PLC配方号写进去了但没生效原因PLC程序里配方号只在初始脉冲时读取一次运行中改变D寄存器的值不会触发配方切换。解决MES侧写配方号的同时要写一个触发位比如M500置1PLC程序检测到这个上升沿再重新加载配方。这个触发位用完要复位否则下次写配方号不会再次触发。4.4 现象追溯记录里条码重复或者串号原因扫码枪的触发信号和PLC的完成信号时序不对或者操作工连续扫了两个码。解决在PLC侧做防错扫码枪读到码之后先锁住等工位完成信号来了再解锁MES侧对serial_no加唯一索引重复插入直接报错并记录日志不要静默覆盖。另外扫码枪的结束符要统一配置成回车不要用Tab或者自定义字符。4.5 现象GOT报警历史CSV解析出来中文乱码原因GOT导出的CSV编码可能是Shift_JIS或者UTF-8 with BOMPython默认用UTF-8读会乱。解决用chardet库检测编码或者直接指定encodingshift_jis试读读到乱码再换utf-8-sig。更稳的做法是在GOT设置里把导出编码固定成UTF-8但老型号GOT可能不支持那就只能在解析端做兼容。5. 三菱MES编程软件的进阶技巧用边缘缓存扛住网络抖动5.1 为什么要在边缘侧做缓存而不是直连MES产线网络和办公网络往往不在一个可靠性等级上。MES服务器在机房产线交换机在电柜里中间可能经过好几级路由闪断是常态。如果采集程序每次读到数据就直接POST到MES接口网络一抖数据就丢追溯链就断了。我现在的习惯是在边缘网关一台工控机或者树莓派级别的设备上跑一个本地SQLite或者轻量消息队列采集程序只管往本地写另一个同步进程负责把本地数据推到MES推成功了再删本地。这样即使MES宕机半天产线数据也不会丢恢复后自动补传。5.2 本地缓存的表结构和清理策略CREATE TABLE local_cache ( id INTEGER PRIMARY KEY AUTOINCREMENT, data_type VARCHAR(16) NOT NULL, -- station / alarm / param payload TEXT NOT NULL, -- JSON格式的原始数据 create_time DATETIME DEFAULT CURRENT_TIMESTAMP, synced TINYINT DEFAULT 0 -- 0未同步 1已同步 );逻辑说明payload存JSON这样不同数据类型可以共用一张表解析逻辑放在同步进程里做。清理策略是每天凌晨把synced1且create_time超过7天的记录删掉保留一周的已同步数据作为后悔药万一MES侧数据有问题还能回查。未同步的数据永远不删但超过10000条要告警说明同步链路出问题了。参数上SQLite的写入性能足够应付每秒几十条记录如果产线节拍更快可以换成Redis或者本地MQ。5.3 同步进程的重试与幂等设计同步进程从local_cache读synced0的记录逐条或批量调MES接口。这里必须做幂等MES接口根据data_type和payload里的唯一键比如serial_nostation_idtimestamp判断是否已存在存在就返回成功边缘侧把synced改成1。重试策略用指数退避第一次失败等1秒第二次等2秒第三次等4秒最多重试5次之后标记为失败并告警不要无限重试把MES打挂。这个设计在多个项目里救过命有一次MES升级数据库停了40分钟产线照常跑恢复后10分钟内数据全部补传完毕看板上的产量曲线没有断点。5.4 一个验证数据完整性的小技巧每天交接班时让MES自动跑一条对账SQL统计当天每个工位的过站记录数和PLC侧D寄存器里的产量计数做对比。如果差异超过1%就触发告警让人去查。PLC侧的产量计数是设备自己累加的最可信MES侧是采集上来的可能丢。这个对账机制不需要额外硬件就是一段定时任务加一个对比逻辑但能发现90%以上的采集异常。我一般把这个对账结果直接推到班组长的企业微信或者钉钉上不用等IT去查现场自己就处理了。希望帮到你。本文还有配套的精品资源点击获取