C#上位机与PLC通信时，电脑一定要设置实际的IP地址吗？

[代码铺到天琴座]

我电脑一直是用自动获得IP地址的方式，给PLC灌程序时也是如此。

近来要用C#上位机与PLC通信，发现不成功。而这个C#上位机是几年前开发的，与当时的机器里的PLC通信是成功的，可见程序没问题。现在过了很多年，我电脑里的设置也许被改过了，所以不能与现在机器里的PLC通信。当然这是我猜测。目前我已经离开机器，无法实验，故来相问。

 

 

[代码铺到天琴座]

@吉普赛的歌 谢谢指导！我用的是1214C，“允许来自远程对象的PUT/GET访问”是勾选上了的。今天设置了电脑的IP，还是通讯不上；让电脑自动获取IP，也通信不上。请问电脑上除了IP地址，还有其它必须设置的地方吗？

[吉普赛的歌]

​​为什么必须设置固定IP？​​
​​通信协议要求​​
PLC通信协议（如西门子的S7协议、三菱的MC协议）要求上位机与PLC在同一局域网网段内（例如PLC IP为192.168.0.1，电脑IP需为192.168.0.x）。若电脑通过DHCP获取到不同网段的IP（如192.168.1.x），将无法建立TCP连接。
​​PLC的访问限制​​
多数PLC需配置允许通信的设备IP地址列表。例如西门子S7-1500需在TIA Portal中设置“允许PUT/GET访问”，若电脑IP未固定或未被授权，通信会被拒绝。
​​网络稳定性​​
工业环境强调实时性，DHCP分配的IP可能因租期到期或路由器重启而变化，导致通信中断。固定IP可避免此问题。
🚫 ​​自动获取IP（DHCP）为何可能失败？​​
​​网段不一致​​：DHCP分配的IP可能与PLC网段不同（如PLC在192.168.0.x网段，电脑分配到192.168.1.x）。
​​IP冲突风险​​：DHCP可能分配已被其他设备占用的IP，引发冲突。
​​防火墙/路由器限制​​：企业网络可能隔离了DHCP网段和PLC网段。
🔍 ​​通信失败的常见原因排查​​
根据您的描述（过去成功，现在失败），可能的原因包括：

​​电脑IP变更​​
DHCP分配的IP已脱离PLC网段。例如之前手动设置过IP，后重置为自动获取。
​​PLC IP重置​​
设备维护可能将PLC恢复出厂设置，IP变为默认值（如西门子PLC默认192.168.0.1）。
​​网络配置变更​​
新增路由器、交换机或VLAN划分导致网络拓扑变化。
​​软件/安全设置​​
防火墙阻止了通信端口（如西门子S7端口102、三菱MC端口6000）。
PLC未启用“允许远程访问”（西门子需勾选PUT/GET选项）。
🛠️ ​​解决方案：手动设置电脑IP​​
以下是具体步骤（以Windows为例）：

​​确认PLC的IP地址​​
通过PLC编程软件（如TIA Portal、GX Works3）查看PLC当前IP。
若无法连接，尝试ARP扫描或联系设备维护人员。
​​设置电脑IP​​
​​控制面板​​ → ​​网络和共享中心​​ → ​​更改适配器设置​​ → 右键以太网 → ​​属性​​ → ​​IPv4​​ → ​​使用以下IP地址​​：
IP地址：与PLC同网段（如PLC为192.168.0.1，电脑设为192.168.0.100）。
子网掩码：255.255.255.0（多数情况）。
网关：非必需，但需与PLC网关一致（若有跨网段通信）。
​​关闭防火墙​​
临时禁用防火墙测试通信，若成功则需添加端口例外规则。
⚙️ ​​PLC通信要求对比​​
​​设备/协议​​ ​​默认端口​​ ​​IP设置要求​​ ​​配置工具​​
西门子S7协议 102 同网段固定IP TIA Portal
三菱MC协议（FX5U） 6000 同网段固定IP GX Works3
Modbus TCP 502 同网段固定IP PLC编程软件
💎 ​​建议操作流程​​
​​固定电脑IP​​：按PLC网段手动配置（见前文步骤）。
​​验证基础连接​​：
ping # 确保物理链路通畅
​​检查C#程序配置​​：
确认代码中PLC IP地址与当前一致（如192.168.0.1）。
若用第三方库（如S7.Net Plus），检查Plc类初始化参数。
​​PLC端复查​​：
确认PLC以太网模块已启用（三菱FX5U需在GX Works3开启MC协议）。
西门子PLC需勾选“允许来自远程对象的PUT/GET访问”。
💡 ​​注​​：若现场PLC支持DHCP服务（少数型号），可将电脑设为自动获取，但需确保PLC的DHCP分配的IP符合网段要求。工业环境仍​​推荐固定IP​​以保障稳定性。

🌟 ​​总结​​
电脑必须设置与PLC同网段的固定IP才能稳定通信。您遇到的故障​​大概率是DHCP分配了不同网段IP或PLC配置被重置所致​​。建议在设备现场按上述步骤重新配置IP，并同步检查PLC的通信授权设置。若仍有问题，可通过Wireshark抓包分析TCP连接请求是否被拒绝。

[代码铺到天琴座]

@代码铺到天琴座 报警S7.Net.PlcException:“Couldn't establish the connection to 192.168.0.1. Message: 由于连接方在一段时间后没有正确答复或连接的主机没有反应，连接尝试失败。 192.168.0.1:102”。这是什么意思？

[代码铺到天琴座]

@by_封爱 有没有可能跟PLC下载时的PG/PC接口有关，我现在的是RealTek Gaming.......。我记得早期的不是这个，但是找不到了，只得用RealTek Gaming.......

[代码铺到天琴座]

@by_封爱 谢谢指导！今天我来到机器前，把电脑IP地址设置为192.168.104，结果C#上位机与PLC通信不上；再把电脑IP地址取消了，还是通讯不上。可是明明C#没问题呀，因为几年前跟别的PLC通信上了（都是1214C)。请教问题出在哪里？

[by_封爱]

你得先了解 你写的C# 在跟PLC通讯的时候 是作为 客户端 还是服务端?
如果你是客户端. 那么你的IP无所谓. 只要能ping通 (一般在一个网段内) 即可.
所以你改不改IP 没什么用.
正常来说是这样的.
如果你作为服务端,那么你的IP一定是需要固定的. 但是一般来说 客户端的软件中 是需要配置服务端的IP的.
而你总不能用你那开发电脑作为服务端来跑程序吧.
所以这也不合理.

[AI向善]

先给结论：IP 要不要固定，取决于这台上位机跟 PLC 是不是在同一个网段里；真正决定通信成不成的不是"设没设 IP"，而是这个 IP 加上子网掩码之后，能不能把 PLC 路由到。

先说一个容易被混起来的地方：你给 PLC 灌程序和用 C# 上位机通信，走的是两条不同的路。灌程序走的是 PG/PC 接口，TIA 那边可以自己挑通道，网口不通的时候还能走别的。而上位机这边走的是标准的 TCP，S7 协议默认端口 102，它只认网络可达性，不管你的 IP 是手动填的还是 DHCP 发的。

所以"灌程序能通、上位机不通"这个组合出现的时候，问题基本都在网络层，不在你的 C# 代码上。何况这套代码当年在别的机器上是跑通的，你的判断是对的。

你后来那句"把电脑 IP 地址设置为 192.168.104"其实就是关键线索。这不是一个完整的 IP，少了第四段。Windows 只填前三段是不会生效的，它会退回原来的配置，或者提示地址无效。更常见的是只改了 IP 没改子网掩码，比如 PLC 是 192.168.0.10/255.255.255.0，电脑设成 192.168.1.100/255.255.255.0，IP 段一对不上，两边连 ARP 都发不过去。

排查按三层走，一层不通就别往下试。

第一层是网络可达。先 ping PLC 的 IP。ping 不通，把电脑的 IP 改成跟 PLC 同段、掩码同段再试。PLC 当前的 IP 可以在 TIA Portal 的"在线访问"里读出来，别凭记忆。

第二层是端口。这是最多人卡住的地方：ping 通不代表 S7 通。ping 走的是 ICMP，跟 102 端口是两回事。在 Windows 上直接测端口，命令是 Test-NetConnection 加目标 IP 和 -Port 102，看 TcpTestSucceeded 这一项。

Test-NetConnection 192.168.0.10 -Port 102

TcpTestSucceeded 要是 False，那就说明有东西挡在中间，跟 C# 没关系。1214C 常见的两个挡点：一是 Windows 防火墙的入站规则里 102/TCP 没放行（出站默认放行，所以容易漏掉入站）；二是 CPU 属性里的保护等级和连接资源，PUT/GET 勾了只解决"允不允许读"，不解决"连不连得上"。

还有一个比防火墙更容易被忽略的：多网卡路由抢占。你原来用自动获取 IP，笔记本上通常同时有无线、有线，再加 VMware 或 Hyper-V 的虚拟网卡。这几张卡各自有网关，去 192.168.x.x 的包很可能从无线那张卡出去了，PLC 根本收不到。这就是"自动获取不通、手动设了 IP 还是不通"的经典形态：手动设了 IP，但路由表没变。

看一眼目标网段实际走哪张卡：

route print 192.168.0.*

接口那一列如果不是你插着网线的那块物理网卡，就是被虚拟网卡抢了。临时把无线断开、或者给有线那张卡单独加一条静态路由，通常立刻就好。

第三层才轮到代码参数。S7-1200 系列的机架槽位是固定的 Rack 0 / Slot 1，写错也会连不上：

using (var plc = new Plc(CpuType.S71200, "192.168.0.10", 0, 1))
{
plc.Open();
var v = plc.Read("DB1.DBD0");
}

如果异常是 "Couldn't establish the connection to ..."，那还是网络层的事，别去改 rack/slot；只有报的是协议层错误，才值得回头看参数。

最后回到你最初的问题：电脑的 IP 不必"固定"，但需要跟 PLC 在同一个网段。如果你把电脑设成 DHCP 而路由器恰好也在这个网段、并且发给它的地址没被别的设备占用，一样能通。固定 IP 的价值只是让"这台机器永远在正确的网段"这件事不依赖路由器，排查时能少一个变量。像你这种要长期跑上位机的场景，我建议直接把电脑设成同网段的静态地址，顺手把多余的虚拟网卡禁掉。

你那边 Test-NetConnection 测 102 的结果是什么？如果端口通了但还是报连接失败，把 S7.Net 的原始异常贴一下，我看是卡在哪个层。