|
1.做总体技术方案 ①架构师首先要确定： ②用PLC还是运动控制卡还是IPC直控 ③用EtherCAT还是脉冲还是总线混合 ④视觉放PLC侧还是PC侧 ⑤HMI独立还是上位机统一 ⑥数据存本地还是上传MES ⑦安全方案用安全继电器还是安全PLC ⑧单机架构还是平台化架构 这一步决定项目成败。 比如有些设备节拍高、轴多、视觉复杂，就不适合纯PLC硬扛。有些设备要求稳定、交付快、维护人员偏电工型，那PLC更合适。 这就是架构师要拍板的事。 2.拆分系统边界 架构师要把系统拆清楚： ①PLC负责什么 ②上位机负责什么 ③视觉负责什么 ④机器人负责什么 ⑤MES负责什么 ⑥HMI负责什么 否则项目后期一定互相甩锅。 典型错误是： ①PLC里写了一半工艺逻辑 ②上位机又写一半 ③HMI再偷写一点参数联动 ④最后谁都改不动 架构师要避免这种混乱。 3定义控制模式和状态机 一台设备至少要定义清楚： 上电初始化 /伺服使能 回原 /待机 自动运行 /暂停 手动 报警停机 /急停 /复位/续跑 并且要定义每种状态下： ①哪些动作允许 ②哪些动作禁止 ③画面怎么显示 ④报警如何处理 ⑤恢复路径是什么 很多设备不好调，不是程序员不会写，而是状态机架构没设计好。 4定义模块标准 比如一个标准轴控模块，要统一： ①输入输出接口 ②命令方式 ③状态反馈 ④报警格式 ⑤软限位逻辑 ⑥回原逻辑 ⑦手自动切换逻辑 再比如一个气缸模块，也要统一： ①伸出/缩回命令 ②到位检测 ③超时报警 ④互锁条件 ⑤手动动作规则 这样团队里不同工程师写出来的模块才可以复用。 5规划通信架构 架构师要规划： ①EtherCAT环网还是线型 ②远程IO怎么分布 ③相机和PLC如何通信 ④机器人与PLC如何握手 ⑤HMI与PLC变量如何映射 ⑥MES与设备的接口协议 ⑦报警码、产品码、工单号如何流转 通信架构设计不好，后面会出现： ①信号延迟 ②数据不同步 ③调试困难 ④故障难复现 ⑤扩展困难 6规划异常与报警体系 成熟设备不是“不报警”，而是报警设计得清晰。 架构师要定义： ①报警分级 ②报警编码规则 ③报警触发条件 ④报警解除条件 ⑤是否允许自动恢复 ⑥哪些报警必须人工复位 ⑦报警日志是否追溯 例如区分： ①提示类 ②一般停机类 ③严重停机类 ④安全类 7规划可维护性 这点非常重要。 架构师要考虑： ①变量命名是否统一 ②注释是否规范 ③画面是否便于调试 ④手动界面是否好用 ⑤IO状态能否快速查看 ⑥轴状态能否快速定位 ⑦故障能不能10分钟内找到原因 ⑧更换一个传感器后是否容易恢复 很多设备功能能跑，但现场维护极差。这通常不是调试工程师不行，而是前期架构没做好。 8规划复用与平台化 真正优秀的架构师，不是每台设备从零开始写，而是会沉淀平台： ①标准轴控FB ②标准气缸FB ③标准报警FB ④标准配方模块 ⑤标准权限模块 ⑥标准日志模块 ⑦标准HMI模板 ⑧标准通信模板 这样后面新设备开发速度会越来越快。 9参与关键技术选型 架构师往往要参与这些决策： ①PLC品牌选型 ②伺服方案选型 ③总线协议选型 ④工控机配置 ⑤板卡方案 ⑥相机/镜头/光源方案接口方式 ⑦数据库方案 ⑧软件语言选型（梯形图/ST/C#/C++） 这不是采购工作，而是技术边界和系统能力的决策。 10控制项目技术风险 架构师还要提前识别风险： ①节拍能不能达到 ②多轴同步是否可行 ③视觉处理时间是否够 ④网络负载是否过高 ⑤安全方案是否合规 ⑥恢复逻辑是否完整 ⑦扩展工位后架构会不会崩 这部分很像“技术总监”的思维。 --- 往期热门文章： 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ | 
下一主题
