真实 PLC 的首次投运不应直接从“下载程序”开始，而应依次建立电气安全、网络可达、设备身份、工程兼容和运行状态的证据。设备发现、ping、程序下载和上位软件读写分别验证不同层次，任何一层成功都不能代替后续层的检查。
安全上电与分段观察
具体设备的合闸顺序必须以电气图、操作规程和现场负责人要求为准，不应从另一套设备照搬。通电前至少确认急停和机械区域安全、柜门和防护完整、无人正在接线维护、气源或动力源是否应保持隔离。
按规定送电后先观察，不立即驱动执行器：
- 总电源、控制电源、PLC、HMI、交换机、工控机和显示器是否分别得电；
- PLC 是
RUN、STOP还是故障状态，模块是否有诊断灯； - 是否出现异味、异响、冒烟、异常发热或反复跳闸。
显示器黑屏不能直接推出整机未上电。可沿“总供电→支路/插排→显示器电源→工控机电源→视频信号”逐段判断；PLC 和 HMI 已亮而显示器无反应，通常只说明控制电源链和计算机显示链需要分别检查。不要通过反复合闸、拆柜或触碰端子来试错。
先建立地址与设备身份清单
投运前记录至少四类对象：
| 对象 | 需要确认 |
|---|---|
| 工程站 | 实际接线的物理有线网卡、IP、掩码 |
| PLC | 铭牌/设备名、型号、接口、实际在线 IP |
| HMI 或上位机 | 控制网接口及其 IP；不要把管理网地址混入控制网 |
| 工程配置 | 项目中的型号、固件、PN/IE 子网、目标 IP 和通信伙伴 |
贴纸、旧工程和现场设备当前地址可能不一致。它们都是待核对的证据，不能仅凭其中一个直接改地址。尤其要区分：
- 工程内配置的目标地址；
- PLC 此刻实际持有的在线地址；
- 上位机自身地址；
- 上位软件配置中“要连接的 PLC 地址”。
最后一项通常应填目标 PLC，而不是运行软件的电脑本机地址。
工程站网卡与基础网络检查
在 TIA Portal 的 PG/PC 接口中选择网线实际连接的物理以太网卡，不要误选 Wi-Fi、VPN、虚拟机或 PLCSIM 虚拟适配器。接口名称只是线索，应结合链路状态、操作系统网络配置和拔插网线后的变化确认。
无路由的常见控制网中，工程站与 PLC 需要地址唯一、掩码相容并处于可直接通信的子网。例如 /24 掩码下，192.168.10.100 与 192.168.10.20 可直接通信，而 192.168.11.20 属于另一子网。临时静态地址还应避免占用现场已有地址，默认网关通常可留空，但应服从现场网络设计。
诊断工具回答的问题不同：
- “可访问的设备”发现目标：说明选定接口上至少存在相应的二层发现路径，并不证明工程地址和应用通信都正确；
ping成功：说明当前 IP 路径和 ICMP 回应正常，并不证明 PLC 程序或 DB 通信正确；ping超时：可能是地址/掩码、物理链路、VLAN、路由、防火墙或目标不响应 ICMP，不能单凭超时断言 PLC 地址一定未写入；- 在线监控变量发生预期变化：才进一步证明具体应用数据链正在工作。
下载前的目标核验
下载可能覆盖现有程序、改变硬件配置、使 CPU 暂停，并影响执行器，因此必须先获得现场授权并核对目标：
- 选择正确的物理网卡，更新可访问设备。
- 对照设备型号、接口、设备名、实际 IP、位置或 MAC 地址等多项标识，防止选错同网段设备。
- 比较在线设备与离线工程的 CPU 型号、固件、模块组态和目标地址。
- 确认现场原程序是否需要先上传或归档，以及覆盖是否被允许。
- 编译工程，阅读加载预览中的停止 CPU、删除/覆盖、硬件不兼容和安全相关提示。
- 只下载已确认的硬件与软件范围；完成后按规程让 CPU 进入预期模式。
“不同步时继续”“上传到项目”和“覆盖下载”代表不同的数据方向和保留策略，不能机械选择。上传会以在线内容影响离线工程；覆盖会以离线工程影响现场设备。选择应由哪一侧是受控基线、是否需要保留现场程序来决定。
只修改离线工程中的 IP，并不保证在线 PLC 已立即采用该地址。地址变更应采用该设备和 TIA 版本支持的明确流程，并在变更前确认不会与其他节点冲突。若需跨子网迁移，先规划工程站在旧地址阶段如何访问设备、变更后如何切换到新网段，避免把“暂时失联”误判为设备故障。
下载后的最小验证
下载完成不等于投运完成。至少验证：
- CPU 处于预期的
RUN/STOP状态，诊断缓冲区没有未处理故障。 - 工程站可以重新在线，在线设备身份和地址与工程一致。
- 一个安全的输入或模拟输入能在 PLC 在线监控中变化。
- 对应的内部状态与输出命令符合联锁；在确认机械安全前不直接试完整自动流程。
- HMI 或仿真平台从一个非安全关键命令/状态开始验证，再逐步扩大范围。
这条链路可表示为：
物理链路 → 地址/子网 → 设备发现 → 工程在线 → 应用数据读写
→ PLC 逻辑与联锁 → 输出映射 → 现场执行与反馈
故障定位应停在第一个失败层，而不是同时改 PLC 地址、电脑地址、DB 和程序逻辑。
第三方上位软件或仿真平台不通信
先监控 PLC 侧的一个输入接口变量，再操作平台中的对应按钮或模式选择：
- PLC 数据变化：网络和写入链大体成立，应继续查 PLC 逻辑、复位条件、输出 DB 或平台显示；
- PLC 数据不变：沿平台目标 IP、所用网卡、协议参数、PLC 访问权限、DB 布局和访问方式检查。
某些外部客户端使用 S7 PUT/GET 或绝对 DB 地址访问。只有协议确实如此时，才需要核对 CPU 的远程 PUT/GET 访问设置，以及接口 DB 是否允许客户端所需的非优化/绝对寻址。关闭优化访问会改变数据布局、性能和接口约束，不应作为所有通信故障的通用修复。机架、插槽、DB 编号、偏移和数据类型也必须来自设备文档与当前工程契约，不能从其他项目照抄。
连接的时间特征可以帮助确定失败层，但不能单独证明根因：
- 从未建立连接：优先检查平台选用的适配器、目标 IP、实例状态、机架/插槽和协议是否匹配；
- 建立连接后在启动仿真或首次读写时立即断开：传输路径大体已建立，优先检查首次应用请求触发的访问权限、协议许可、DB 编号与布局；
- 连接保持但变量不变化：用单个已知变量分别验证读、写方向，再检查偏移、数据类型、映射方向和 PLC 逻辑。
若确认客户端依赖 PUT/GET，启用 CPU 的远程 PUT/GET 访问属于硬件与安全配置变更。修改后应编译并下载包含相关硬件配置的受控范围；只下载程序块可能不会使设置生效。然后通过 CPU 运行状态、诊断缓冲区及一个安全的输入/输出变量确认结果。历史案例 080-虚拟仿真平台连接问题 中，平台表现为上电后短暂连接并立即断开；启用 PUT/GET 并重新下载硬件与软件后，用户确认恢复连接。这个反馈只验证该案例，不表示相同症状必然具有相同根因。
PLC 在线可达而平台不通信，并不矛盾：前者只验证工程工具到 PLC 的链路，后者还依赖平台所在电脑的网卡、目标地址、协议、访问权限和数据布局。
常见误判
- 搜到 PLC，就认为所选工程一定能安全下载。
- 电脑和 PLC 插在同一交换机，就认为它们一定在同一 IP 子网或 VLAN。
- 把上位机贴纸 IP 填入“PLC 地址”字段。
- 工程地址改了，就认为在线设备地址已经同步改变。
ping超时，就断言程序、PLC 或某个具体配置必然有错。- 为恢复通信同时改多项参数，失去对根因的判断能力。
- 看到 CPU
RUN，就跳过诊断、I/O 与联锁检查直接启动设备。
相关知识
- PLC 与 HMI 的接口、画面与联调
- PLC 离散顺序控制的设计与检查
- 机器人仿真到实物的接口分层