工业自动化项目里控制层的硬件选型一直是个让人头疼的事。传统做法是PLC管逻辑、网关管协议转换、工控机管上位监控和数据处理三套硬件各司其职柜内空间占得多接线复杂采购成本高后期维护还得分别对付三个厂家的技术支持和固件升级。这几年储能、光伏、充电桩这类分布式能源项目爆发式增长现场设备数量多、协议杂、部署周期紧传统三件套的弊端被放大了好几倍。ARMxy模块化工业控制器就是在这个背景下进入我视野的——它把PLC的逻辑控制、网关的协议转换、工控机的边缘计算能力整合到一台设备上用模块化IO和软件定义的方式重新定义了控制层的硬件形态。这篇文章不打算复述产品手册而是从实际项目落地的角度把选型逻辑、架构设计、协议对接、部署调试这几个环节拆开来讲适合正在做储能EMS、产线自动化、设备数据采集的工程师参考也适合刚接触工业控制、想了解现代控制器演进方向的朋友建立认知框架。1. 三件套架构在储能与自动化项目中的真实痛点1.1 柜内空间与供电冗余的隐性成本先说一个很多人忽略的问题柜内空间。传统方案里PLC本体加上扩展IO模块通常要占掉35mm导轨上20到30厘米的宽度网关设备再占10到15厘米工控机如果是无风扇嵌入式的那种至少也要15到20厘米再加上开关电源、断路器、接线端子一个600×800的标准控制柜经常被塞得满满当当。储能项目尤其明显PCS、BMS、消防、空调、电表这些子系统都要接入IO点数和通信接口数量比普通产线高出一大截柜子越做越大成本跟着涨。供电也是个麻烦事。PLC一般走24V直流工控机可能是12V或者19V网关又是另一个电压柜内得配多路电源或者DC-DC转换模块。每多一路电源就多一个故障点多一份接线工作量多一笔采购成本。我之前做过一个2MWh的工商业储能项目光是控制柜内的电源模块和接线就花了将近两天时间调试阶段还因为某路电源纹波过大导致网关频繁掉线排查了大半天才定位到问题。ARMxy这类模块化控制器的思路是把这些功能收敛到一套硬件平台上统一供电、统一散热、统一通信背板。柜内只需要给它一路24V供电剩下的IO扩展、通信接口都通过模块化插槽解决。这个改变看起来简单实际算下来柜内空间能省30%到40%电源和接线成本能降一半左右。1.2 协议碎片化带来的集成噩梦储能和自动化项目里设备协议之杂是出了名的。PCS厂家可能用Modbus RTUBMS用Modbus TCP或者CAN电表用DL/T 645或者Modbus空调用BACnet消防主机用私有协议再加上各种传感器、变频器、伺服驱动器一个项目里出现五六种协议是常态。传统做法是PLC负责逻辑控制网关负责把非标协议转成PLC能读的格式工控机再通过OPC UA或者Modbus TCP从PLC和网关取数据做上位展示和云端上传。这套架构的问题在于数据要经过多次转换和转发延迟大、故障点多。更麻烦的是网关的协议库往往是固定的遇到冷门协议或者厂家自定义的报文格式要么等网关厂家更新固件要么加一个协议转换模块项目周期根本等不起。我遇到过好几次现场调试时发现某台设备的Modbus寄存器地址和厂家提供的文档对不上网关的配置界面又不支持灵活调整最后只能临时用Python脚本在工控机上做协议适配绕了一大圈。ARMxy这类控制器的优势在于它本身就是一个可编程的边缘计算平台协议解析可以用软件灵活实现。Modbus、OPC UA、MQTT、CAN这些标准协议直接支持遇到私有协议或者非标报文可以在设备上写脚本做解析不用额外加硬件。这个能力在储能项目里特别值钱因为储能现场的设备迭代快今天用A厂家的BMS明天可能换成B厂家的协议适配的灵活性直接决定了项目交付速度。1.3 运维层面的三套系统割裂从运维角度看PLC、网关、工控机三套系统各自独立意味着三套配置工具、三套固件升级流程、三套故障排查逻辑。PLC的程序下载要用厂家的编程软件网关的配置要用Web界面或者专用工具工控机的系统维护又是另一套。现场出了问题先要判断是哪个环节的故障然后找对应的工具和文档效率很低。更现实的问题是很多中小型项目的运维人员只有一两个人不可能同时精通三套系统的维护。设备一旦出问题往往要等厂家技术支持远程或者到场停机时间拉长。ARMxy把这三层整合到一个平台上之后配置、编程、调试都在同一个环境里完成运维人员只需要掌握一套工具链学习成本和维护成本都大幅下降。2. ARMxy模块化控制器的架构逻辑与选型依据2.1 核心板加扩展底板的模块化设计ARMxy的硬件架构可以理解为“核心板扩展底板IO模块”三层结构。核心板负责运算和通信通常基于ARM Cortex-A系列处理器跑Linux系统扩展底板提供各种物理接口比如以太网、RS485、CAN、DI/DO、AI/AOIO模块则根据项目需求灵活插拔需要多少路数字量输入、多少路模拟量输出就配多少块对应的模块。这种设计的好处是“按需配置”。传统PLC的IO扩展虽然也支持模块化但CPU本体的通信能力和运算能力是固定的选了某个型号的CPU通信接口数量和类型就定死了。ARMxy的核心板通常自带多个以太网口和串口扩展底板再补充其他接口灵活性高很多。储能项目里经常需要同时接PCS、BMS、电表、空调、消防好几个子系统通信接口不够用是常态模块化设计能省去很多外扩网关的麻烦。选型的时候要重点关注几个参数核心板的CPU型号和主频决定了能跑多复杂的算法和多大规模的数据处理内存和存储决定了能存多少历史数据和日志扩展底板的接口类型和数量决定了能直接对接多少设备IO模块的通道数和精度决定了能采集多少信号。这些参数不是越高越好而是要跟项目规模匹配。一个几百千瓦时的储能项目用中端核心板加适量IO模块就够了没必要上高端型号成本会失控。2.2 软件定义控制与硬实时性的平衡ARMxy跑的是Linux系统这意味着它的控制逻辑是用软件实现的而不是传统PLC那种硬实时扫描周期。很多人会担心Linux系统的实时性能不能保证控制指令会不会延迟这个问题要分场景看。对于储能EMS这类应用控制周期通常在100毫秒到1秒级别Linux系统配合实时补丁比如PREEMPT_RT完全可以满足。对于高速产线控制比如需要微秒级响应的伺服同步传统PLC或者专用运动控制器仍然是更稳妥的选择。ARMxy的定位不是替代所有PLC而是在那些对实时性要求不那么极端、但对通信和计算能力要求更高的场景里发挥优势。实际项目里我通常会把控制逻辑分成两层硬实时部分比如急停、安全联锁交给专用的安全继电器或者小型PLC处理软实时部分比如功率调度、策略优化、数据采集交给ARMxy。这样既保证了安全性又发挥了ARMxy的灵活性。这个思路在储能项目里特别适用因为储能系统的核心控制逻辑是功率分配和充放电策略对实时性的要求远没有产线那么苛刻。2.3 什么场景适合用什么场景不适合ARMxy不是万能药选型时要清楚它的边界。适合的场景包括储能EMS、光伏监控、充电桩管理、设备数据采集网关、边缘计算节点、中小型自动化产线控制。这些场景的共同特点是设备数量多、协议杂、需要数据上云、对实时性要求适中。不太适合的场景包括高速运动控制比如多轴伺服同步、安全等级要求极高的场合比如电梯控制、核电、极端环境比如高温高湿高振动的重工业现场除非选用加固型号。这些场景传统PLC或者专用控制器仍然是更合适的选择。我个人的经验是如果一个项目的IO点数在200点以内、通信设备在20台以内、控制周期在50毫秒以上ARMxy这类模块化控制器基本都能胜任而且综合成本比三件套方案低不少。超过这个规模就要具体评估了可能需要多个控制器组网或者混合架构。3. 储能EMS项目中的协议对接实操3.1 Modbus RTU与TCP的混合组网储能项目里Modbus是最常见的协议PCS、BMS、电表、空调几乎都支持。但同样是Modbus有的设备走RTU串口有的走TCP网口有的两者都支持。ARMxy通常有多个RS485口和以太网口可以同时处理RTU和TCP设备。配置的时候有个细节要注意RS485总线上的设备数量和波特率要匹配。一条485总线上挂太多设备会导致通信不稳定一般建议不超过32台波特率根据线缆长度和设备响应速度选9600或者19200比较稳妥。如果设备数量多可以用多个485口分组ARMxy的模块化设计在这方面很灵活需要几个串口就插几个串口模块。Modbus TCP的设备直接通过以太网接入要注意IP地址规划和端口号。有些设备的Modbus TCP默认端口不是502配置的时候要确认清楚。另外Modbus TCP的并发连接数也有限制设备多了要考虑轮询策略避免同时发起太多连接导致响应超时。代码层面在ARMxy上可以用Python的pymodbus库快速实现Modbus主站功能。下面是一个读取PCS运行状态的示例from pymodbus.client import ModbusTcpClient from pymodbus.client import ModbusSerialClient # Modbus TCP 连接PCS tcp_client ModbusTcpClient(192.168.1.100, port502) tcp_client.connect() # 读取PCS的功率、电压、电流等寄存器 result tcp_client.read_holding_registers(address1000, count10, slave1) if not result.isError(): power result.registers[0] * 0.1 # 假设比例因子为0.1 voltage result.registers[1] * 0.1 current result.registers[2] * 0.01 print(fPCS功率: {power}kW, 电压: {voltage}V, 电流: {current}A) # Modbus RTU 连接BMS rtu_client ModbusSerialClient( port/dev/ttyS2, baudrate9600, parityN, stopbits1, bytesize8, timeout1 ) rtu_client.connect() bms_result rtu_client.read_holding_registers(address0, count20, slave2)这段代码的关键点在于比例因子要根据设备手册确认不同厂家的寄存器定义差异很大超时时间要设置合理太短容易误判掉线太长会拖慢轮询周期异常处理要完善通信失败时要有重试和告警机制。3.2 OPC UA在跨品牌设备集成中的角色OPC UA这几年在工业领域普及得很快很多新出的PLC、变频器、传感器都开始支持。它的优势在于跨平台、自带信息模型、安全性好。储能项目里如果PCS或者BMS支持OPC UA直接对接会比Modbus省事很多因为不用手动解析寄存器地址直接读节点就行。在ARMxy上实现OPC UA客户端可以用Python的opcua库或者open62541的Python绑定。配置的时候要注意几个点端点URL的格式、安全策略的选择、证书管理。测试阶段可以先用None安全策略跑通生产环境一定要启用签名和加密否则数据裸奔有风险。OPC UA的节点ID格式各厂家不一样有的是ns2;sDevice1.Power有的是ns3;i1001配置前要拿到设备的地址空间文档或者用UAExpert这类工具先浏览一遍。我一般会在调试阶段用UAExpert连上设备把需要的节点ID记下来再写到ARMxy的配置里这样不容易出错。3.3 私有协议与CAN总线的处理思路储能BMS很多走CAN总线协议是厂家自定义的。ARMxy如果带CAN接口可以直接接BMS的CAN总线用Python的python-can库做报文解析。关键是要拿到BMS的CAN通信协议文档知道每个CAN ID对应什么数据、字节序是大端还是小端、有没有校验位。import can bus can.interface.Bus(channelcan0, bustypesocketcan) def parse_bms_message(msg): if msg.arbitration_id 0x100: # 假设0x100是电池电压电流报文 voltage (msg.data[0] 8 | msg.data[1]) * 0.1 current (msg.data[2] 8 | msg.data[3]) * 0.1 - 3000 soc msg.data[4] return {voltage: voltage, current: current, soc: soc} return None for msg in bus: data parse_bms_message(msg) if data: print(data)私有协议的处理没有通用方案只能根据文档逐条解析。我的经验是先在CAN分析仪上抓包对照文档确认每个报文的含义再写解析代码。调试阶段一定要把原始报文和解析结果同时打印出来方便核对。遇到解析不对的情况优先检查字节序和比例因子这两个是最容易出错的。4. 从柜内接线到云端上传的部署链路4.1 硬件安装与接线规范ARMxy的安装方式通常是DIN导轨卡扣跟PLC一样。接线的时候要注意几个细节电源输入要加保险丝和防反接保护虽然是24V低压但接反了照样烧板子RS485总线要加终端电阻一般120欧姆总线两端各一个以太网线要用工业级的屏蔽线普通网线在电磁干扰大的柜内容易丢包。DI/DO的接线要看清楚是源型还是漏型ARMxy的IO模块一般支持两种方式但接线方式不同。AI/AO要注意信号类型4-20mA和0-10V的接线不一样接错了读数会完全不对。我见过有人把4-20mA的传感器接到0-10V的输入通道上读数一直是满量程排查了半天才发现是跳线没设置对。接地也是个容易被忽视的问题。控制柜的PE接地要可靠ARMxy的接地端子要单独接到柜体接地排上不要跟其他大功率设备的接地混在一起。储能现场电磁环境复杂接地做不好通信误码率会明显上升。4.2 系统镜像烧录与基础环境配置ARMxy出厂一般预装了Linux系统但项目上通常需要自己烧录定制镜像把需要的库和工具提前装好。烧录工具一般是厂家的专用软件通过USB或者TF卡烧录。烧录前要确认镜像版本和硬件版本匹配版本不对可能起不来。系统起来之后第一件事是配置网络。ARMxy通常有多个网口要规划好哪个口接内网设备、哪个口接外网或者上级网络。如果项目要求数据上云还要配置4G/5G模块或者WiFi。网络配置建议用静态IPDHCP在工业现场不够可靠IP变了会导致通信中断。然后是安装依赖库。Python环境一般自带但pymodbus、opcua、python-can这些库要手动装。如果现场没有外网要提前把pip包下载好用离线方式安装。我一般会做一个安装脚本把所有依赖一次性装完省得现场一个个敲命令。#!/bin/bash # ARMxy 基础环境配置脚本 pip install pymodbus3.5.2 pip install opcua0.98.13 pip install python-can4.2.2 pip install paho-mqtt1.6.1 pip install pyserial3.5 # 配置CAN接口 ip link set can0 type can bitrate 250000 ip link set can0 up # 配置静态IP nmcli con mod eth0 ipv4.addresses 192.168.1.10/24 nmcli con mod eth0 ipv4.gateway 192.168.1.1 nmcli con mod eth0 ipv4.method manual nmcli con up eth0这个脚本只是示例实际项目里要根据硬件型号和网络规划调整。CAN总线的波特率要和BMS匹配储能BMS常用250k或者500k设置错了通信不上。4.3 数据采集程序的部署与自启动数据采集程序写好后要配置成开机自启动否则断电重启后程序不会自动跑。Linux下常用的方式是systemd服务。写一个service文件指定程序的路径、运行用户、重启策略然后enable一下就行。[Unit] DescriptionEnergy Storage Data Collector Afternetwork.target [Service] Typesimple Userroot WorkingDirectory/opt/ems ExecStart/usr/bin/python3 /opt/ems/main.py Restartalways RestartSec10 [Install] WantedBymulti-user.target这个配置的关键点是Restartalways程序崩溃后会自动重启保证数据采集不中断。RestartSec10表示重启前等10秒避免频繁重启。日志可以通过journalctl查看方便排查问题。程序本身要做好异常处理通信失败、数据解析错误、数据库写入失败这些情况都要有日志记录和告警。储能项目对数据连续性要求高采集程序挂掉几分钟可能就丢了一批关键数据影响后续的收益结算。4.4 数据上云的MQTT与断线重连策略数据上云一般走MQTTARMxy作为客户端把采集到的数据发布到云平台。MQTT的好处是轻量、支持断线重连、适合低带宽场景。配置的时候要注意几个参数keepalive时间、clean session标志、QoS等级。keepalive一般设60秒太短会增加网络负担太长会导致断线检测不及时。clean session设false这样断线重连后能收到离线期间的消息如果broker支持。QoS根据数据重要性选关键数据用QoS 1或者2普通监测数据用QoS 0。断线重连是MQTT部署的重点。网络不稳定的时候客户端要能自动重连并且把断线期间的数据缓存下来重连后补发。paho-mqtt库自带重连机制但缓存补发要自己实现。我的做法是在本地用SQLite存一份数据发送成功后再删除断线重连后先补发缓存数据再发实时数据。import paho.mqtt.client as mqtt import sqlite3 import json import time def on_connect(client, userdata, flags, rc): print(fConnected with result code {rc}) client.subscribe(ems/command) def on_disconnect(client, userdata, rc): print(Disconnected, will auto reconnect) client mqtt.Client(client_idarmxy_ems_001, clean_sessionFalse) client.on_connect on_connect client.on_disconnect on_disconnect client.connect(cloud.example.com, 1883, 60) client.loop_start() def publish_with_cache(topic, payload): conn sqlite3.connect(/opt/ems/cache.db) cursor conn.cursor() cursor.execute(CREATE TABLE IF NOT EXISTS cache (id INTEGER PRIMARY KEY AUTOINCREMENT, topic TEXT, payload TEXT, timestamp REAL)) try: result client.publish(topic, payload, qos1) if result.rc ! mqtt.MQTT_ERR_SUCCESS: cursor.execute(INSERT INTO cache (topic, payload, timestamp) VALUES (?, ?, ?), (topic, payload, time.time())) conn.commit() except Exception as e: cursor.execute(INSERT INTO cache (topic, payload, timestamp) VALUES (?, ?, ?), (topic, payload, time.time())) conn.commit() conn.close()这段代码展示了基本的缓存补发逻辑实际项目里还要考虑缓存清理、补发顺序、并发写入等问题。储能项目的数据量不大SQLite足够用如果是高频采集场景可以考虑用更高效的存储方案。5. 调试阶段最容易踩的五个坑5.1 串口设备地址冲突与轮询超时RS485总线上如果两台设备地址设成一样通信会随机失败而且很难排查因为有时候能通有时候不通。调试的时候要一台一台接确认地址唯一后再接下一台。有些设备的地址是通过拨码开关设置的有些是通过软件配置的要确认清楚。轮询超时也是常见问题。一条485总线上挂了十几台设备如果每台设备的超时时间都设1秒轮询一轮就要十几秒数据刷新率很低。优化方法是根据设备响应速度分别设置超时时间响应快的设200毫秒慢的设500毫秒并且把关键设备放在轮询队列前面。5.2 Modbus寄存器地址的偏移陷阱Modbus协议里寄存器地址有0-based和1-based两种表示方式文档里写40001实际访问地址可能是0也可能是40000不同厂家不一样。这个坑我踩过好几次明明按文档写的地址读就是读不到数据换成另一个偏移量就对了。解决办法是先用Modbus调试工具比如Modbus Poll手动测试确认正确的地址偏移再写到代码里。另外保持寄存器Holding Register和输入寄存器Input Register的功能码不同读保持寄存器用03功能码读输入寄存器用04功能码搞错了也读不到数据。5.3 浮点数与字节序的解析错误Modbus传输浮点数通常用两个16位寄存器但字节序和寄存器顺序各厂家不同。有的高字在前有的低字在前有的字节交换有的不交换。解析错了读出来的数完全是乱的。常见的四种组合ABCD大端高字在前、CDAB大端低字在前、BADC小端高字在前、DCBA小端低字在前。调试的时候四种都试一遍哪个读数合理就是哪个。我一般会写一个测试脚本把四种解析方式的结果都打印出来对照设备实际值判断。5.4 网络风暴与广播报文泛滥储能现场如果接了很多以太网设备广播报文可能会泛滥导致网络性能下降。特别是有些设备默认开启LLDP、STP这些协议报文会周期性地广播。ARMxy的网口如果没做隔离可能会被这些广播报文淹没影响正常通信。解决办法是划分VLAN把不同子系统的设备隔离开或者在ARMxy上配置防火墙规则限制广播报文的转发。如果项目规模不大用交换机做端口隔离也能缓解。5.5 断电重启后的配置丢失有些配置是存在内存里的断电就丢。比如CAN接口的波特率设置、静态IP配置、防火墙规则如果没做持久化重启后设备就失联了。ARMxy上要把这些配置写到启动脚本或者systemd服务里保证每次开机自动生效。我遇到过最坑的一次是现场调试完一切正常断电重启后ARMxy的网口IP变成了默认的192.168.1.100跟现场网络冲突导致整个控制柜的设备都通信异常。后来发现是网络配置没持久化nmcli的修改没保存到配置文件。这个教训告诉我任何配置修改后都要重启验证一遍确认能自动恢复。6. 成本对比与项目收益的实算6.1 硬件采购成本的直接对比以一个典型的500kWh工商业储能项目为例控制层需要接入PCS、BMS、电表、空调、消防五个子系统IO点数大约80个DI/DO、20个AI。传统三件套方案的硬件清单大致是PLC本体加IO模块约8000元协议网关约3000元嵌入式工控机约5000元加上电源、接线端子、导轨等辅材约2000元合计约18000元。ARMxy方案核心板加扩展底板约6000元IO模块约4000元辅材约1000元合计约11000元。硬件成本直接省了7000元左右降幅接近40%。这还没算柜内空间节省带来的柜体成本下降以及接线工作量减少带来的人工成本节省。6.2 调试与运维的隐性成本节省硬件成本只是冰山一角调试和运维的成本往往更高。传统方案里PLC编程、网关配置、工控机系统部署是三套独立的工作需要不同技能的人员调试周期长。ARMxy方案里所有配置和编程都在一个平台上完成一个人就能搞定调试周期能缩短30%到50%。运维阶段传统方案出故障要分别排查三个设备ARMxy只需要排查一个。固件升级、配置备份、日志查看都在同一个界面里运维效率提升明显。对于一个有几十个储能站点的运营商来说这些隐性成本的节省累积起来非常可观。6.3 什么情况下三件套仍然更划算也不是所有项目都适合ARMxy。如果项目对实时性要求极高比如高速产线的运动控制传统PLC的硬实时性能仍然是更可靠的选择。如果项目规模很小只需要几个IO点和一个通信口用一个小型PLC加一个串口服务器可能更便宜。如果项目现场已经有成熟的PLC系统改造升级的迁移成本可能高于收益。选型的核心逻辑是看项目的通信复杂度、数据处理需求和部署规模。通信设备多、协议杂、需要边缘计算和上云的项目ARMxy这类模块化控制器优势明显简单逻辑控制、单机设备、实时性要求苛刻的场景传统PLC仍然是稳妥选择。7. 从单机到组网的扩展思路7.1 多台ARMxy的级联与主从架构单个ARMxy的IO和通信能力有限大型项目需要多台组网。常见的架构是主从模式一台主控制器负责协调和上云多台从控制器负责各自区域的设备接入和控制。主从之间通过以太网或者CAN总线通信协议可以用Modbus TCP或者MQTT。主从架构的关键是数据同步和故障切换。主控制器挂了从控制器要能接管关键控制逻辑或者至少保证数据不丢失。我的做法是在从控制器上也存一份关键数据主控制器定期同步状态主控失联时从控进入安全模式保持当前状态并尝试重连。7.2 边缘计算与云端协同的分工ARMxy作为边缘节点可以承担一部分数据预处理和本地决策的工作减轻云端压力。比如储能站的功率调度策略可以在本地实时执行云端只负责下发策略参数和收集统计数据。这样即使云端通信中断本地控制仍然正常。边缘和云端的分工原则是实时性要求高的、数据量大的、涉及安全的逻辑放在边缘全局优化、跨站点协调、长期数据分析放在云端。这个分工不是固定的要根据项目需求和通信条件调整。通信条件好的项目云端可以承担更多计算通信不稳定的项目边缘要能独立运行。7.3 远程升级与批量部署的工程化实践储能项目往往有多个站点每个站点的控制器都需要部署相同的程序。手动一台台配置效率太低需要工程化的批量部署方案。常见做法是做一个标准系统镜像包含所有依赖和基础配置现场只需要烧录镜像、修改站点特定的参数比如IP地址、设备地址就能快速上线。远程升级要谨慎升级失败可能导致设备变砖。我的做法是保留一个回滚分区升级前先备份当前系统升级失败自动回滚。升级包要经过充分测试最好先在测试站点验证确认没问题再批量推送。升级时间选在业务低谷期避免影响正常运行。8. 几个实际项目中的经验沉淀做储能和自动化项目这些年用ARMxy这类模块化控制器替换传统三件套最大的感受是“集成度带来的效率提升是实实在在的”。但集成度高也意味着单点故障的影响更大一台设备挂了控制、通信、数据采集全停。所以冗余设计很重要关键项目要配双机热备或者至少准备一台备用机。另一个体会是软件定义的控制系统对开发人员的要求更高了。传统PLC编程有梯形图、功能块这些标准化工具工程师培训几天就能上手。ARMxy上写Python或者C需要开发人员有编程基础还要懂Linux系统。团队如果没有这方面的人才前期学习成本不低。我的建议是先从数据采集和协议转换这类相对简单的场景入手积累经验后再逐步承担控制逻辑。最后说一个细节文档和注释。ARMxy上的程序是软件代码不像PLC梯形图那么直观。项目交付时代码的文档和注释一定要写清楚否则后期维护的人看不懂出了问题排查起来很痛苦。我一般要求团队在代码里标注每个函数的用途、每个寄存器的含义、每个配置项的作用虽然写的时候费时间但长远看省下的时间更多。