# 电动扳手系统架构重构方案 ## 📊 当前架构问题分析 ### 现状 1. **设备管理**:前端本地存储(device_manager.py) 2. **在线检测**:前端调用后端API,后端执行连接检测 3. **拧紧过程**:前端执行(wrench_gui.py) 4. **数据存储**:后端负责 ### 问题 - 前端调用后端检测在线状态,增加网络延迟 - 后端需要导入WrenchController,职责不清晰 - 设备配置分散在前端,不便于集中管理 --- ## 🎯 重构目标架构 ### 职责划分 #### 🖥️ **客户端(Frontend)职责** 1. ✅ **在线状态检测**:直接连接扳手检测,无需经过后端 2. ✅ **拧紧过程控制**:设定扭矩、启动扳手、等待结果 3. ✅ **实时数据采集**:接收扳手返回的实时数据 4. ✅ **UI交互**:显示工单、螺栓列表、进度 #### 🌐 **服务端(Backend)职责** 1. ✅ **设备管理**:设备列表、配置的增删改查 2. ✅ **工单管理**:工单的创建、认领、查询 3. ✅ **结果存储**:保存拧紧结果到数据库 4. ✅ **数据查询**:提供历史数据查询接口 5. ❌ **不再负责**:设备在线检测、扳手连接 --- ## 🔧 具体重构步骤 ### 步骤1:修改客户端在线检测逻辑 **修改文件**:`frontend/wrench_gui.py` **当前代码**(第1196-1253行): ```python def start_device_status_check(self): """启动设备状态检测(后台线程)""" def check_status(): while True: # 调用后端API检测设备状态 check_url = f"{self.api_base_url}/wrench-devices/{device_id}/check-status" check_response = requests.post(check_url, timeout=3) ``` **重构后**: ```python def start_device_status_check(self): """启动设备状态检测(后台线程)- 客户端直接检测""" def check_status(): while True: # 从后端获取设备列表 devices = self.fetch_devices_from_backend() # 客户端直接检测每个设备的在线状态 for device in devices: status = self.check_device_online(device) device['status'] = status # 可选:将状态上报给后端(仅用于记录) self.report_device_status(device['id'], status) self.wrench_devices = devices self.root.after(0, self.update_device_combo) time.sleep(10) threading.Thread(target=check_status, daemon=True).start() def check_device_online(self, device): """客户端直接检测设备在线状态""" try: config = { "ip_address": device.get('ip_address'), "port": device.get('port', 7888), "address_code": device.get('address_code', 1) } wrench = WrenchController(device_config=config) is_online = wrench.connect() if is_online: wrench.disconnect() return 'online' return 'offline' except: return 'offline' ``` ### 步骤2:简化后端设备API **修改文件**:`backend/app.py` **删除或简化**: ```python # 删除check-status接口(第376-427行) # 或改为可选的状态上报接口 @app.route('/api/wrench-devices//status', methods=['POST']) def report_device_status(device_id): """客户端上报设备状态(可选,仅用于记录)""" data = request.get_json() status = data.get('status', 'offline') db.update_wrench_device_status(device_id, status) return jsonify({"success": True}) ``` **保留的接口**: - `GET /api/wrench-devices` - 获取设备列表 - `POST /api/wrench-devices` - 创建设备 - `PUT /api/wrench-devices/` - 更新设备 - `DELETE /api/wrench-devices/` - 删除设备 ### 步骤3:移除后端对WrenchController的依赖 **修改文件**:`backend/app.py` **删除导入**: ```python # 删除这行 from wrench_controller import WrenchController ``` **删除相关代码**: - 第376-427行:`check_device_status` 函数 - 第429-460行:`query_device_sn` 函数(如果有) ### 步骤4:优化延时配置 **修改文件**:`config.json` **添加延时配置**: ```json { "api": { "base_url": "http://localhost:5000/api" }, "delays": { "wrench_init": 1.5, "param_set": 2.0, "retry": 1.0, "bolt_complete": 0.5, "status_check_interval": 10 } } ``` **修改文件**:`wrench_controller.py`(第448行) ```python def set_torque_parameters(self, ...): # 发送命令 self._send_command(bytes(data)) # 从配置读取延时 delay = self.config.get('delays', {}).get('param_set', 2.0) time.sleep(delay) ``` **修改文件**:`frontend/wrench_gui.py`(第932行) ```python def work_thread(self): # 启用远程控制 self.wrench.enable_remote_control(True) # 从配置读取延时 init_delay = self.load_delay_config('wrench_init', 1.5) time.sleep(init_delay) ``` --- ## 📋 重构后的架构图 ``` ┌─────────────────────────────────────────────────────────────┐ │ 客户端 (Frontend) │ ├─────────────────────────────────────────────────────────────┤ │ 1. 从后端获取设备列表 │ │ 2. 直接连接扳手检测在线状态 ✅ │ │ 3. 设定扭矩参数 ✅ │ │ 4. 启动扳手、等待结果 ✅ │ │ 5. 采集实时数据 ✅ │ │ 6. 提交结果到后端 │ └─────────────────────────────────────────────────────────────┘ ↕ HTTP API ┌─────────────────────────────────────────────────────────────┐ │ 服务端 (Backend) │ ├─────────────────────────────────────────────────────────────┤ │ 1. 设备管理 (CRUD) ✅ │ │ 2. 工单管理 (CRUD) ✅ │ │ 3. 结果存储 ✅ │ │ 4. 数据查询 ✅ │ │ 5. 不再负责:设备连接、在线检测 ❌ │ └─────────────────────────────────────────────────────────────┘ ``` --- ## ✅ 重构优势 1. **职责清晰**:客户端负责硬件交互,服务端负责数据管理 2. **性能提升**:在线检测无需经过后端,减少网络延迟 3. **解耦合**:后端不再依赖WrenchController,便于部署 4. **灵活配置**:延时参数可配置,适应不同扳手型号 5. **易于扩展**:客户端可以直接添加更多硬件交互功能 --- ## 🚀 实施建议 ### 优先级 1. **高优先级**:修改客户端在线检测(步骤1) 2. **高优先级**:优化延时配置(步骤4) 3. **中优先级**:简化后端API(步骤2) 4. **低优先级**:清理后端依赖(步骤3) ### 风险控制 - 保留后端check-status接口作为备用 - 分阶段实施,每步测试后再进行下一步 - 保留旧代码注释,便于回滚 ### 测试要点 - 多台客户端同时检测设备状态 - 不同型号扳手的延时适配 - 网络断开时的容错处理