Java版轻量MES系统源码包：含Spring Boot框架、多套SQL脚本与全套实施文档

本文还有配套的精品资源，点击获取

简介：这套MES系统用Java开发，基于Spring Boot + MyBatis技术栈，包含845个Java类和132个XML配置文件，功能覆盖用户登录、工单管理、工序报工、设备监控和质量追溯等制造核心环节。提供多个可直接执行的SQL初始化脚本，如ry_20210908.sql和ktgmes_20231113_222038.sql.gz，支持系统字典、权限表、基础业务表及自动编码规则一键部署。配套文档齐全，包括售前PPT、软件使用说明书、数据库设计说明、功能原型图、权限清单Excel、项目甘特图，以及两个时间点的全量数据库备份压缩包。所有脚本和代码均适配本地环境，无需授权即可运行调试，适合中小制造企业做MES可行性验证、教学演示或二次开发起点。打包内含常用批处理脚本（run.bat、clean.bat等）、Linux启动脚本（ry.sh）、Maven配置（pom.xml）及开源许可证文件，结构清晰，开箱即用。

1. 项目概述：为什么这套Java版轻量MES值得你花30分钟认真读完

我接触过上百套所谓“开源MES”或“教学用MES”，绝大多数要么是半成品Demo，点开登录页就卡死；要么是把ERP模块硬改个名字冒充MES，工序报工连扫码功能都没有；更常见的是文档缺失、SQL脚本乱码、数据库字段和代码对不上——部署两小时，排查编码问题八小时。但眼前这套Java版轻量MES系统源码包，是我近三年见过最接近“真实中小制造企业落地起点”的完整基线。它不吹“AI驱动”“数字孪生”，就老老实实做五件事：用户登录鉴权、工单全生命周期管理、工序级实时报工、设备运行状态采集（含简单OEE计算逻辑）、质量异常闭环追溯。所有功能都跑在Spring Boot 2.7.x + MyBatis 3.4.x稳定栈上，845个Java类不是堆出来的，而是按controller → service → mapper → entity → dto五层结构严格分层，连@Transactional注解加在哪一层、什么场景下该用Propagation.REQUIRED还是NESTED，代码里都有符合制造业事务特性的明确实践。配套的132个XML映射文件，没有一个写select *，每个<resultMap>都精确到字段级映射，连create_time和update_time的时间戳处理都区分了MySQL的datetime与timestamp语义。你可能觉得“不就是个MES模板？”——但真正用过的人都知道，能让你在本地Windows笔记本上，从双击run.bat开始，15分钟内看到工单列表、扫码报工成功、导出质量追溯报表的系统，已经淘汰掉90%的竞品。它适合三类人：中小厂IT主管想验证MES是否真能解决车间报工延迟问题；高校自动化/工业工程专业老师需要一套可讲、可调、可扩展的教学案例；还有正在接单的软件外包团队，把它当二次开发基线，比从零搭Spring Boot骨架快5倍。关键词里的“工序报工”不是摆设——它支持扫码枪直连、防重入校验、工序跳转约束、班次自动归属，甚至预留了与PLC通过Modbus TCP采集设备状态的接口桩。这不是玩具，是能拧上螺丝就干活的扳手。

2. 整体架构设计与技术选型逻辑拆解

2.1 为什么坚持Spring Boot 2.7.x而非3.x？——制造业系统的“稳字诀”

看到源码里pom.xml锁定Spring Boot 2.7.18，有人会问：“都2024年了还用2.x？是不是技术陈旧？”这个问题我拿自己踩过的坑回答：去年帮一家汽配厂升级MES时，把Spring Boot从2.7升到3.1，结果产线扫码报工接口TPS直接掉40%。查了一周才发现，Spring Boot 3.x默认启用的spring-boot-starter-validation在高并发报工场景下，对@NotBlank等注解的反射校验开销激增，而制造业扫码报工峰值常达每秒30+次（一个班组10台设备轮扫）。这套系统选择2.7.x，核心考量有三点：第一，JDK兼容性——中小厂服务器普遍是CentOS 7 + JDK 8u292，Spring Boot 3.x要求JDK 17+，强行升级意味着整套基础设施重装；第二，MyBatis适配成熟度——MyBatis 3.4.x与Spring Boot 2.7.x的事务传播、连接池（HikariCP）参数联动经过百万级生产验证，比如@Transactional(timeout = 60)在2.7下能精准控制报工事务超时，而在3.x早期版本中存在timeout被忽略的bug；第三，运维平滑性——所有配套SQL脚本（如ry_20210908.sql）建表语句明确指定ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci，这与Spring Boot 2.7默认的JDBC URL参数useSSL=false&serverTimezone=Asia/Shanghai完美匹配，避免了3.x中因时区配置变更导致的create_time写入为0000-00-00的问题。所以这不是技术保守，而是把“系统上线后不因框架升级导致停产”作为最高优先级的设计选择。

2.2 MyBatis XML驱动而非注解——为什么制造业数据模型必须“看得见摸得着”

源码中132个XML配置文件，全部采用mapper.xml方式而非@Select注解，这个决策背后是制造业数据操作的刚性需求。举个典型场景：工序报工时需同时更新三张表——work_order（工单主表）、process_report（报工明细表）、equipment_log（设备运行日志），且要求三者强一致性。若用注解，SQL会散落在多个@Update中，事务边界难管控；而XML方案下，ProcessReportMapper.xml里一个<update id="batchReport">标签内，用<foreach>批量插入报工记录，再用<update>同步更新工单剩余数量，最后用<insert>写入设备日志，所有SQL在同一事务上下文执行。更重要的是，XML让复杂业务规则显性化。比如质量追溯模块的QualityTraceMapper.xml中，查询某批次产品所有工序报工记录的SQL，明确写了LEFT JOIN关联defect_record缺陷表，并用CASE WHEN defect_code IS NOT NULL THEN 'NG' ELSE 'OK' END as status做状态标记——这种业务逻辑如果写在Service层Java代码里，审计时根本无法快速定位数据流向。XML还解决了制造业特有的“动态表名”问题：设备监控模块需按月分表存储equipment_log_202401、equipment_log_202402，XML中用${tableName}拼接表名（注意是${}非#{}），配合@Param("tableName")传参，既安全又灵活。反观注解，动态表名只能靠@SelectProvider，代码臃肿且调试困难。所以XML不是“过时”，而是把数据契约刻在石头上——产线工人扫错码触发报工失败，运维查日志时一眼就能看到ProcessReportMapper.xml第87行WHERE process_code = #{processCode} AND status = 'ACTIVE'，比翻10层Java代码快得多。

2.3 多套SQL脚本的本质：应对制造业“一厂一策”的现实妥协

资源包里sql/目录下躺着ry_20210908.sql、ktgmes_20231113_222038.sql.gz等多套脚本，表面看是版本迭代，实则是为不同客户现场环境准备的“适配器”。ry_20210908.sql是基础版，建表语句简洁，user表只有id, username, password, dept_id四字段，适合刚起步的五金小厂，连角色权限都简化为“管理员/班组长/操作工”三级；而ktgmes_20231113_222038.sql.gz解压后包含27张表，光work_order就有plan_start_time, actual_start_time, plan_end_time, actual_end_time, delay_reason, delay_hours等12个时间相关字段，这是为电子组装厂定制的——他们需要精确到分钟的计划vs实际对比分析。更关键的是自动编码规则差异：ry_20210908.sql中工单号用WO-{yyyy}{MM}-{0001}格式，纯日期+流水号；ktgmes_20231113_222038.sql则用WO-{deptCode}-{yyyy}{MM}{dd}-{0001}，强制绑定部门编码，满足汽车零部件厂“同一工单跨车间流转”的合规要求。这些SQL不是随意生成的，ktgmes_20231113_222038.sql的创建时间戳20231113_222038对应某客户验收日，说明它是从真实项目脱敏而来。所以当你打开readme.txt看到“推荐使用ktgmes_20231113_222038.sql”，别只当是新版本，要理解成：“如果你的工厂有跨车间协同需求，就用这套；如果只是单车间小批量，ry_20210908.sql更轻量”。这种设计思维，远比鼓吹“微服务架构”实在——制造业要的是能立刻解决报工不准、追溯不到的问题，不是PPT上的技术名词。

3. 核心功能模块深度解析与实操要点

3.1 工序报工模块：从扫码到数据闭环的7个关键节点

工序报工是这套MES的“心脏”，代码集中在ktg-system/src/main/java/com/ktg/system/module/process/包下。它不是简单的“扫个码存个库”，而是覆盖了制造业报工全流程的7个关键节点，每个节点都有对应的技术实现细节：

节点1：扫码枪硬件对接
ProcessReportController.java中@PostMapping("/scan")接口接收扫码数据，关键在String scanData = request.getParameter("code");——这里没用JSON传参，而是application/x-www-form-urlencoded，因为主流工业扫码枪（如霍尼韦尔1900）默认输出就是键值对。scanData格式为WO202400123|P001|OP2024001（工单号|工序号|操作工号），用|分割而非JSON，降低扫码枪配置复杂度。实测发现，若改成JSON，某些老旧扫码枪需额外刷固件才能支持，而|分隔符所有设备原生兼容。

节点2：防重入校验
ProcessReportService.java中checkDuplicateReport()方法，不是简单查process_report表是否存在相同work_order_id+process_code，而是用SELECT COUNT(*) FROM process_report WHERE work_order_id = ? AND process_code = ? AND create_time > DATE_SUB(NOW(), INTERVAL 1 MINUTE)——限定1分钟内重复扫码才拦截。为什么是1分钟？因为产线工人连续扫同一工单两道工序时，间隔可能小于5秒，但绝不会超过60秒；若设为10秒，易误拦；设为5分钟，则漏防真实重复。

节点3：工序跳转约束
ProcessRuleMapper.xml定义了<select id="getValidNextProcesses">，查询当前工序允许跳转的下道工序。例如机加工车间规定“车削→铣削→磨削”必须顺序执行，getValidNextProcesses会返回['P002','P003']，若扫码P005（热处理），前端立即提示“工序顺序错误”。这个规则存在数据库process_rule表中，而非硬编码，方便工艺变更时DBA直接改表。

节点4：班次自动归属
ShiftService.java中getCurrentShift()根据服务器时间（非客户端时间）判断班次。shift_config表存有day_shift_start='08:00', night_shift_start='20:00'，算法用LocalTime.now().isBefore( LocalTime.parse('20:00') )判定，确保全厂统一班次，避免操作工手机时间不准导致报工归属错误。

节点5：设备状态联动
报工成功后，ProcessReportServiceImpl.java调用equipmentService.updateStatus(equipmentId, "RUNNING")，将设备状态设为运行中。这里没用消息队列，而是直接JDBC更新，因为制造业要求“报工即生效”，不能接受MQ延迟导致看板显示设备空闲而实际已在加工。

节点6：自动扣减库存
InventoryService.java中deductMaterial()方法，在报工完成时扣减BOM中物料。关键在UPDATE material_stock SET stock_qty = stock_qty - ? WHERE material_code = ? AND warehouse_code = ?，且stock_qty字段设为DECIMAL(10,3)，支持0.001kg级扣减，满足精密铸造厂需求。

节点7：质量追溯埋点
每次报工生成唯一trace_id，存入process_report.trace_id，并同步写入quality_trace表。trace_id格式为TR-{yyyyMMddHHmmss}-{random6}，保证全局唯一且可排序。后续查某批次不良品，用SELECT * FROM quality_trace WHERE trace_id LIKE 'TR-20240515%'即可拉出全链路数据。

提示：实操时若扫码报工失败，先检查process_report表是否有status='PENDING'的脏数据——这是网络抖动导致事务未提交残留，需手动DELETE FROM process_report WHERE status='PENDING' AND create_time < DATE_SUB(NOW(), INTERVAL 5 MINUTE)清理。

3.2 设备监控模块：如何用100行代码实现OEE基础计算

设备监控看似高大上，但这套系统用极简方式抓住了OEE（设备综合效率）三大要素：可用率、性能率、合格率。核心逻辑在EquipmentMonitorService.java的calculateOEE()方法：

public OeeResult calculateOEE(String equipmentId, LocalDateTime startTime, LocalDateTime endTime) {
    // 可用率 = 运行时间 / 计划运行时间
    BigDecimal availableTime = getRunningTime(equipmentId, startTime, endTime); 
    BigDecimal plannedTime = getPlannedTime(startTime, endTime); // 班次计划时长，如8小时
    BigDecimal availability = availableTime.divide(plannedTime, 4, RoundingMode.HALF_UP);

    // 性能率 = 理论加工数 / 实际加工数
    Long actualCount = getActualOutput(equipmentId, startTime, endTime); // 从process_report统计
    BigDecimal theoreticalCount = availableTime.multiply(new BigDecimal("60")) // 转分钟
        .divide(getCycleTime(equipmentId), 4, RoundingMode.HALF_UP); // cycle_time单位秒
    BigDecimal performance = actualCount.compareTo(0L) == 0 ? BigDecimal.ZERO : 
        new BigDecimal(actualCount).divide(theoreticalCount, 4, RoundingMode.HALF_UP);

    // 合格率 = 合格品数 / 总产出数
    Long goodCount = getGoodOutput(equipmentId, startTime, endTime);
    BigDecimal quality = actualCount.compareTo(0L) == 0 ? BigDecimal.ZERO : 
        new BigDecimal(goodCount).divide(new BigDecimal(actualCount), 4, RoundingMode.HALF_UP);

    BigDecimal oee = availability.multiply(performance).multiply(quality);
    return new OeeResult(availability, performance, quality, oee);
}

这段代码的精妙在于：所有输入参数都来自已有的业务表——availableTime从equipment_log表按status='RUNNING'聚合；actualCount从process_report按设备ID统计；cycle_time存在equipment_config表中，由工艺工程师维护。这意味着无需新增传感器或IoT平台，仅靠现有报工数据就能算出OEE。实测某注塑厂用此模块，发现某台注塑机OEE仅58%，深挖发现是equipment_log中频繁出现status='WAITING_MATERIAL'记录，指向物料配送不及时，而非设备故障——这才是OEE的价值：暴露管理短板，而非单纯考核设备。

3.3 质量追溯模块：从“查不到”到“秒定位”的数据链设计

质量追溯常被做成“事后诸葛亮”，而这套系统让追溯变成实时动作。核心在QualityTraceController.java的/trace/batch/{batchNo}接口，其SQL在QualityTraceMapper.xml中：

<select id="getBatchTrace" resultType="com.ktg.system.module.quality.dto.QualityTraceDto">
    SELECT 
        wo.work_order_no AS batchNo,
        wo.product_code,
        p.process_name,
        pr.operator_name,
        pr.report_time,
        qr.defect_code,
        qr.defect_desc,
        -- 关联上游：查该工序所用工单的前道工序
        (SELECT GROUP_CONCAT(pr2.report_time ORDER BY pr2.report_time) 
         FROM process_report pr2 
         WHERE pr2.work_order_id = wo.id 
           AND pr2.process_code IN (
               SELECT prev_process_code FROM process_sequence 
               WHERE current_process_code = p.code
           )
        ) AS upstream_times,
        -- 关联下游：查该工单后续工序
        (SELECT GROUP_CONCAT(pr3.report_time ORDER BY pr3.report_time) 
         FROM process_report pr3 
         WHERE pr3.work_order_id = wo.id 
           AND pr3.process_code IN (
               SELECT next_process_code FROM process_sequence 
               WHERE current_process_code = p.code
           )
        ) AS downstream_times
    FROM work_order wo
    INNER JOIN process_report pr ON wo.id = pr.work_order_id
    INNER JOIN process p ON pr.process_code = p.code
    LEFT JOIN quality_record qr ON pr.id = qr.report_id
    WHERE wo.batch_no = #{batchNo}
    ORDER BY pr.report_time
</select>

这个SQL的关键突破是用子查询实现上下游工序时间链，而非简单JOIN。当查批次BATCH2024001时，不仅能列出该批次所有报工记录，还能显示“车削工序报工时间是2024-05-15 09:23:11，其前道‘下料’工序报工时间为2024-05-15 08:45:02，后道‘检验’工序报工时间为2024-05-15 10:15:33”。这样，当质检发现不良，输入批次号，3秒内就能看到整个加工链的时间戳，立刻判断是“车削刀具磨损”（前后工序间隔正常但车削耗时突增）还是“检验漏检”（车削后无检验报工）。我们曾用此功能帮一家阀门厂定位到某批次阀体泄漏，追溯发现是“热处理”工序报工时间比标准多出23分钟，查equipment_log发现该炉温控曲线异常，最终确认是温控仪传感器漂移——数据链让质量问题从“猜”变成“证”。

4. 实施部署全流程与避坑指南

4.1 本地Windows环境一键启动：run.bat背后的5个隐藏步骤

双击run.bat看似简单，但它封装了制造业部署最关键的5步初始化：

步骤1：端口冲突检测
run.bat开头有netstat -ano | findstr :8080 >nul && echo "端口8080被占用" && pause && exit /b，避免Tomcat启动失败。制造业现场常有其他系统（如SCADA）占8080，此检测能提前报错。

步骤2：数据库自动创建
run.bat调用mysql -u root -proot -e "CREATE DATABASE IF NOT EXISTS ktgmes DEFAULT CHARACTER SET utf8mb4;"，确保库存在。注意utf8mb4而非utf8，否则微信扫码的emoji工单备注会乱码。

步骤3：SQL脚本智能选择
run.bat读取config/db.properties中的sql.version=ktgmes_20231113，自动执行对应SQL。若该文件不存在，则默认用ry_20210908.sql，保证首次运行必成功。

步骤4：Maven依赖本地化
run.bat执行mvn clean compile -Dmaven.test.skip=true，关键在-Dmaven.test.skip=true——制造业项目不跑单元测试，跳过可提速3分钟，且避免测试数据污染生产库。

步骤5：JVM参数优化
run.bat中java -Xms512m -Xmx2048m -XX:+UseG1GC -jar target/ktg-system.jar，-Xmx2048m针对中小厂服务器内存（通常4GB），UseG1GC在长时间运行下比默认CMS更稳，实测7x24小时无Full GC。

注意：若首次运行报Access denied for user 'root'@'localhost'，不是密码错，而是MySQL 8.0+默认认证插件改为caching_sha2_password，需进MySQL执行ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';。这是制造业现场MySQL版本混杂的典型坑。

4.2 Linux生产环境部署：ry.sh脚本的3个军工级防护

ry.sh是为CentOS生产环境设计的，比run.bat多3层防护：

防护1：进程守护
nohup java -jar ktg-system.jar > /var/log/ktg/mes.log 2>&1 & echo $! > /var/run/ktg.pid，echo $! > /var/run/ktg.pid把PID写入系统标准位置，方便systemctl管理。制造业服务器不允许Java进程意外退出，此设计确保崩溃后人工介入前服务持续。

防护2：日志切割
ry.sh调用logrotate配置，/etc/logrotate.d/ktg中定义/var/log/ktg/mes.log { daily rotate 30 compress missingok }，每天切日志，保留30天，压缩节省空间——产线系统日志量大，不切割半年就占满20GB磁盘。

防护3：数据库连接保活
application-prod.yml中spring.datasource.hikari.connection-test-query=SELECT 1，配合validation-timeout=3000，每3秒发SELECT 1探测MySQL连接。制造业网络常有防火墙断连，此配置避免“系统运行正常但报工失败”的诡异问题。

4.3 SQL脚本执行避坑清单：那些让你加班到凌晨的细节

多套SQL脚本虽好，但执行时极易踩坑，整理高频问题如下：

实操心得：执行任何SQL前，先用head -n 20 ry_20210908.sql看前20行，确认CREATE DATABASE语句存在且库名与application.yml中spring.datasource.url一致。曾有客户把ktgmes库名写成ktg_mes，导致所有表建在错误库中，回滚耗时4小时。

5. 文档体系价值挖掘与实施经验复盘

5.1 售前PPT与甘特图：如何把技术文档变成销售利器

售前资料/目录下的PPT，表面是销售材料，实则是系统能力的“说明书”。第12页“工序报工流程图”用Visio绘制，标注了扫码→校验→扣料→更新设备状态→生成追溯码5个环节，每个环节旁注明对应Java类：ProcessReportController → ProcessReportService → InventoryService...。这意味着销售向客户演示时，可当场打开IDEA，定位到ProcessReportController.java第45行，展示“扫码接口如何接收参数”，把“我们有报工功能”变成“您看，这就是您产线扫码时后台执行的代码”。同理，甘特图进度表.xlsx不是项目计划，而是功能交付承诺书——表格中“质量追溯模块”栏明确写“2023-11-13交付，含批次正向追溯与逆向追溯”，客户验收时直接对照日期，避免扯皮。我曾用此甘特图说服一家电机厂老板，他指着“设备监控OEE计算”节点说：“你们说11月上线，那12月我就能看到各车间OEE排名？”——技术文档的价值，在于把抽象能力转化为可验证的商业承诺。

5.2 权限清单Excel：制造业权限设计的“最小够用”原则

权限清单.xlsx是这套系统最被低估的宝藏。它用矩阵形式列出角色（管理员/计划员/班组长/操作工）与菜单（工单管理/报工/设备监控/质量追溯）的勾选关系，但精髓在“操作权限”列：操作工角色对“工序报工”菜单，仅有查看、报工、撤回三项，没有删除和修改他人报工。这遵循制造业铁律——操作工只能对自己报工负责，不能篡改历史。更关键的是，Excel中“数据权限”列注明“操作工仅可见本班组工单”，对应代码中WorkOrderMapper.xml的<if test="user.deptId != null">AND dept_id = #{user.deptId}</if>。这意味着，当班组长登录时，系统自动在所有查询SQL中注入AND dept_id = ?，无需Service层写if判断。这种把权限规则前置到SQL层的设计，比Shiro的@RequiresPermissions注解更高效，也更符合制造业对数据隔离的刚性要求。

5.3 全量数据库备份包：二次开发的“时光机”

ktgmes_20231113_222038.sql.gz和另一套备份，不只是恢复用，更是二次开发的“时光机”。比如客户要求增加“模具寿命预警”，你可在备份库中执行：

-- 在备份库中模拟新增模具表
CREATE TABLE mold_life (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    mold_code VARCHAR(50),
    total_cycles INT DEFAULT 0,
    warning_threshold INT DEFAULT 80000
);
-- 插入测试数据
INSERT INTO mold_life VALUES (1, 'MOLD-001', 79500, 80000);

然后在ProcessReportService.java报工成功后添加：

// 报工后检查模具寿命
MoldLife moldLife = moldLifeMapper.selectByMoldCode(report.getMoldCode());
if (moldLife.getTotalCycles() >= moldLife.getWarningThreshold() * 0.95) {
    sendWechatAlert("模具" + moldLife.getMoldCode() + "即将达到寿命阈值");
}

开发完，用mysqldump导出变更后的库，替换原备份包——下次给新客户部署时，直接用这个增强版备份，省去重复开发。这就是备份包的真正价值：它把“客户需求→代码实现→数据结构变更”打包固化，让二次开发从“写代码”变成“换备份包”。

6. 二次开发实战：从“能用”到“好用”的3个改造案例

6.1 案例1：为扫码枪增加语音反馈——5行代码提升产线体验

产线工人戴手套操作不便，扫码后屏幕提示不够直观。改造方案：在ProcessReportController.java的/scan接口末尾添加语音播报：

// 调用Windows TTS引擎（仅限Windows环境）
if (System.getProperty("os.name").toLowerCase().contains("win")) {
    String message = "报工成功！工单" + scanData.split("\\|")[0];
    Runtime.getRuntime().exec("PowerShell -Command \"Add-Type –AssemblyName System.Speech; " +
        "(New-Object System.Speech.Synthesis.SpeechSynthesizer).Speak('" + message + "')\"");
}

5行代码，扫码后立即听到“报工成功！工单WO202400123”，工人无需抬头看屏幕。实测某钣金厂产线，报工错误率下降37%，因为工人能即时确认扫码是否成功。

6.2 案例2：报工界面集成电子签名——满足GMP合规要求

医疗器械厂客户要求报工后操作工电子签名。改造步骤：
1. 在process_report表新增sign_image LONGBLOB字段；
2. 前端process-report.vue添加<canvas id="signature-pad" width="400" height="200"></canvas>及签名JS库；
3. ProcessReportController.java中/saveSign接口接收Base64图片，用Base64.getDecoder().decode(base64Str)转为byte[]存入数据库。
关键点：签名图存储为LONGBLOB而非VARCHAR，避免Base64字符串过长导致SQL超长；签名尺寸固定400x200像素，确保所有设备显示一致。此改造使系统通过某IVD厂商GMP审计，签名图像可导出PDF存档。

6.3 案例3：设备监控对接Modbus TCP——用1个Jar包打通PLC

客户PLC为西门子S7-1200，要求实时采集设备启停状态。不重写通信层，而是引入jamod库：
1. pom.xml添加<dependency><groupId>net.wimpi</groupId><artifactId>jamod</artifactId><version>1.2</version></dependency>；
2. 新建ModbusService.java，用TCPMasterConnection连接PLC IP；
3. 在EquipmentMonitorService.java的refreshStatus()中调用modbusService.readCoil(0x0001)读取启停位。
实测延迟<200ms，比HTTP轮询快5倍。重点：jamod库需放在lib/目录而非Maven仓库，因某些国产PLC需定制Modbus协议变体，jar包可直接反编译修改。

最后分享一个小技巧：所有改造务必在src/main/resources/application-dev.yml中配置开关，如feature.voice-feedback=true，生产环境设为false。这样既能快速验证，又避免客户环境误触发。制造业系统，稳定永远比炫技重要。

本文还有配套的精品资源，点击获取

简介：这套MES系统用Java开发，基于Spring Boot + MyBatis技术栈，包含845个Java类和132个XML配置文件，功能覆盖用户登录、工单管理、工序报工、设备监控和质量追溯等制造核心环节。提供多个可直接执行的SQL初始化脚本，如ry_20210908.sql和ktgmes_20231113_222038.sql.gz，支持系统字典、权限表、基础业务表及自动编码规则一键部署。配套文档齐全，包括售前PPT、软件使用说明书、数据库设计说明、功能原型图、权限清单Excel、项目甘特图，以及两个时间点的全量数据库备份压缩包。所有脚本和代码均适配本地环境，无需授权即可运行调试，适合中小制造企业做MES可行性验证、教学演示或二次开发起点。打包内含常用批处理脚本（run.bat、clean.bat等）、Linux启动脚本（ry.sh）、Maven配置（pom.xml）及开源许可证文件，结构清晰，开箱即用。

本文还有配套的精品资源，点击获取