说在前面的话
受限于浅薄的见识, 许多的经历和结论并不能代表总体情况, 仅供记录和参考, 笔者就是个菜鸟, 大佬轻喷.
工作前背景
- 双非本科机械设计制造及其自动化专业
- 零c#基础
工作公司概况
- 定性: 非标自动化设备供应商
- 经营范围: 3C电子产品类产线
- 客户群体: 手机厂商及其代工厂
工作内容
- 设备电路图绘制
- PLC程序编写和调试维护
- 上位机程序编写和维护
经历和总结
经历
一句话总结: 最初是艰难, 入门后突飞猛进, 现阶段的沉淀和突破.
入门阶段:
- 补完控制原理, 了解各元件的职能和工作原理, 构建一个清晰的控制路线图.
- 从零开始入门C#, 在校期间c语言是水过的, 开始接触C#的各种"庞杂"的概念, 包括但不限于| 面向对象 | 类 | 成员 | 方法 | 事件 | 委托 | 泛型 | 实例 | 接口 | 序列化和反序列化 | 线程 | 异步 | 锁 | 反射......学习的过程并不是一帆风顺的, 整个学习阶段都会有几朵乌云笼罩在身旁, 每当啃下一个概念之后, 在往后看又是眉头紧皱, 印象最为深刻的是泛型的概念花了可能有一个月的时间才 "顿悟".
C#入门书籍推荐《C#图解教程》，比入门到精通系列要更精妙一些.
网络资源强烈推荐刘铁锰老师的C#入门视频!
发展阶段:
- 经过了入门之后已经能看懂大部分的业务代码, 这个阶段是更多的实践, 在调试中大量的代码编写中修正自己的错误认知和用法.
- 已经开始可能判断一段代码或者一个类的质量, 以及可能的改进方向.
独立阶段:
- 经过长时间的沉淀和学习, 已经可以看懂除部分高阶用法之外的所有代码, 于是, 可以开始书写属于自己的篇章了.
- 基于自己的理解对现有业务代码中及其 "别扭" 的部分进行优化或者重写.
- 创造新的标准和体系, 尝试突破现有平台的限制.
- 深入此前浅尝的领域.
关于设备
- 设备类型:
- 包装: 供料器
- 点胶: 点胶阀, 测高仪
- 贴装: 供料器
- 镭焊: 激光器
- 测试: 各种相关仪器
- 硬件构成:
- 运动控制卡
- PLC
- 各类电机及其驱动器
- CCD相机及其配套光源控制器或视觉控制器
- 数字量输入输出元件
- 模拟量输入输出元件
- 气缸
- 机器人
- 打印机
- 点胶阀
- 供料器
- 主要程序构成:
- 工艺流程运动控制
- 次级模块及元器件通讯和交互
- 生产数据处理
- MES系统交互
- 功能性模块的实现
关于上位机技术栈 (应用层)
- 运动控制原理: 辅助代码编写的外部知识支撑.
- 串口通讯和TCP通讯: 和各种次级传感器和产品进行交互.
- Http通讯: 主要是和甲方工厂的工艺流程管理系统进行交互.
- 数据库: 生产数据的存储和查询.
- UI: 当前主要是工作在winform和WPF框架, 需要会基本的控件创建和管理.
- 文件处理: 基本的文件CRUD, 文件的打包, 配置文件储存和解析.
关于一个完整项目的流程
- 订单: 项目组接收甲方需求.
- 评审: 各研发部门根据需求展开项目评审, 初步探讨实现方式和工艺路线.
- 定向: 敲定大致的设计方向(改制已有项目占比75%~, 全新设备和工艺路线占比25%~).
- 设计: 机构设计 & 电气设计 & 工控上位机设计 同时开工, 开始进入高强度的工作.
- 出货: 下单所有BOM, 待到料后装配组开始组装, 组装完成后调试组和软件组开始介入设备调试硬件和软件, 直至达到出货要求.
- 打样: 设备发货到甲方现场, 项目管理组 & 软件组 & 机构组 分别派人随同前往甲方现场, 进行较长时间的调试.
- 验收: 经过长时间的设备软件和硬件调试, 甲方会阶段性"跑料", 测试设备功能和重要指标, 期间发现和关闭各项问题点, 达到验收标准后进行验收, 设备转入量产.
- 量产: 取决于项目的规模分为两种情况
(1). 打样的设备就是量产设备, 验收后直接转入量产, 无陆续订单.
(2). 打样设备作为量产前样机, 达成客户预期后, 客户下单进行大批量生产, 开始复制打样成果, 批量下单- 组装 - 调试 - 出货.
我司各岗位出差比例
- 项目管理组(PM): 90% 跟随项目立项开始到进入量产, 甚至后期量产后还有常驻甲方的人员.
- 软件组:80% 从项目立项之后的程序编写到稳定量产前的时间段基本都围绕在设备旁.
- 机构组:50% 主要工作是机构设计, BOM下单, 响应机构异常和设计更变.
- 售后组: 基本都围绕在甲方公司, 基本可以算作是甲方的常驻人员, 负责设备全生命周期的异常维护, 保证生产的顺利进行.
作为上位机开发, 对行业现状的思考(仅限于3C非标自动化领域)
- 比较依赖于客户群体, 若是客户群体不好过了, 我们不能好过.
- 跨行入侵的门槛较高, 但市场饱和致使行业内卷化程度缓慢增加.
- 技术栈相对于互联网行业较为老旧, 但是借鉴和吸收的过程中需要谨慎, 不然步子迈大了容易扯着蛋.
- 前期技术压力突出, 中后期效率压力占多, 需求和异常可以平心应对, 但因各种小问题和长期的封闭内网车间工作环境憋得慌.
- 慢慢深入会发现挺多悖论
-
程序的可维护性:
对于程序编写者而言, 首要工作是保证业务逻辑的实现, 这本没有什么问题. 但是一旦涉及到维护的问题, 但是因为一般维护程序和编写程序的不是一批人, 甚至不在同一 "水平" , 面对已有正在生产的程序, 维护者是没有任何动力去重写现有逻辑实现的, 仅仅是应对出现的问题, 和新增功能;
但仅仅是debug和增加新功能就已经能搞出很多问题了, 纵然每个人的代码风格不同, 实现方式也不同, 但是糟糕的代码质量是维护者的噩梦, 却不会对程序的编写者造成任何影响, 甚至在维护者搞不定时叫编写者介入, 反而似乎更能体现编写者的 "高明", 实际情况是程序的编写者或是有意或是无意, 将程序内容写得难懂, 项目完结时不会对他的绩效造成任何影响, 甚至可能在将来维护者无法解决时出面还能 "反衬" 编写者的能力, 这一个利害链就决定了编写者的行为, 必然是不会主动朝着提高代码质量的方向走. 这是个无解的悖论, 维护者作为后来者, 必定掉入前者 "埋" 的坑里, 作为后者, 必须发挥主观能动性, 才能跳出这个怪圈. -
非标自动化上位机的标准化:
非标自动化的命脉在 "非标" 一词上, 只有满足客户和需求的才能算上是好的东西, 这个在机构上可能是无法满足的, 每个项目的设备, 哪怕是同一款的设备的改造升级, 因为各种原因, 都不可能达成一个标准化, 但是作为设备的灵魂, 上位机控制软件的标准化在达成上有两座大山, 一座名为"技术", 一座名为"工作". 技术上的困难是由于编写者的水平客观存在的, 工作上的困难就复杂了, 背后是各种各样的考量, 常见的想法是:标准化增加了个人的可替代性, 容易被中年危机; 标准化的成果并不能表现在项目的成功上;
-
杂念
- 非标自动化, 重在非标, 此"非标"为需求的非标, 因为很多时候客户都不十分清楚自己想要什么样的效果, 选择什么方案, 需求和方案直到大面积量产前都在不停变化.
- 工艺运动控制; 下位设备交互; 生产
- 一方面非工业控制方面的编程从业者一没有工作经验, 二对设备工艺的陌生, 三对控制流程及原理的陌生, 四对真实设备运行时的恐惧; 以上造成了相当一部分的卷王或是主动或是被动, 没能进入到工控行业, 但不可否认的是, 得益于互联网产业的高度发展, 前端后端的高度成熟, 工控行业有太多的方案可以借鉴学习, 并且可以长时间吸收, 但是要选择性吸收, 因为工控行业有自己的特殊性, 并不是所有先进的方案都适用于工控, 大步吸收地同时也要谨慎.
- 卷才是常态.