Ethernet和Profinet能在一个网络里共存么？

太长了，就不引用了。以太网或者485/can啥子的跟C/S或者B/S没关系。以太网的最基本的硬件机制是CSMA/CD，这种机制就是允许冲突的，只不过是硬件能检测到，然后“退步”而已。要不然你看看这种机制去吧，我也不好意思大段的复制/粘贴百度百科的内容，随便搜搜就出来了。高铁/动车/绿皮车的问题就比较复杂了，咱哪天另外开一个话题讨论吧。

虽然很多大拿科普了很多技术上的知识，但是楼主说的这些问题，我觉得是没有问题的，因为俺有个项目跟你差不多配置已经完整运行好几年了

膜拜一下！

使用同一根网线、网口，使用不同的协议、写不同的通讯程序，是吗

MODBUS  tcp就是CS架构，设备要么做modbus tcp server要么就是modbus tcp client,一般来说支持这种协议的设备都是server,咱们PLC是作为client去主动连接设备的，然后给设备发送控制字去控制。
不知道你记不记得profinet作为server最多能连几个来着（根据PLC型号好像是各不一样的），作为client最多能连几个来着，为啥要限制呢，理论上IP不同就可以连的呀，是不是考虑到服务器的处理能力了，怕遇上春晚抢红包的尴尬局面。S7通信也是CS架构，工业上用到以太网的基本都是CS。最简单的就是靠IP区分设备，iP相同的设备可以靠端口来区分，IP和端口都相同的可以靠设备发出的心跳来区分，总之建立连接的首要条件就是iP得对的上，端口得对的上，然后协议格式还得对上，如果某个设备连到服务器上不按照服务器的协议格式给数据，服务器会把这个捣乱的设备踢掉。
你走profinet的client设备192.168.1.1连到MODBUS tcp server设备192.168.1.2上的可能性就那几秒，一发数据就被踢了，反之也是一样的道理，冲突怎么来的呀。modbus tcp 的server只服务与modbus tcp设备，PROFINET的是不管的，反之也一样。这种连接都够呛的情况下报文冲突都是次要的，更何况还有数据链路层来保证数据帧的可靠传输，就好比两个网络节点的专线。
唯一造成冲突的就是这两种协议使用了相同的数据缓存区，比如在PLC上同时启用了两种协议，并且把两种协议的接受区和发送区的数据快共用了，会造成逻辑判断异常。这当然是人的问题了，和这种网络下的协议无关，和这种网络结构更扯不上关系。

这有什么不妥吗？PLC配置网口的程序逻辑切换一下，前30秒走通用的TCP/iP，后30秒走modbus tcp，分别和两种协议下的设备连接不难吧？（PLC作为客户端去主动连接设备，设备都做服务器，保持在线）同一个网口，同一根网线，使用不同的协议，写不同的程序。
如果有条件可以下载个以太网助手，体验一下网络连接的花式玩法。可以验证下不按照相关协议的格式发数据会不会被瞬间踢掉线。

一个节点可以同时做server和client。我说的是底层啊，是485和以太网的差别。你这个server和client跟那些都无关了，是高层的协议了。那个本胖要学习海为的PLC去鸟，这个先放一放。

没做过，也不知道可不可行。看到二位争辩的很激烈，学到不少。只有自己实际做过这种案例并平稳运行的，才更有说服力

200smart我做过，标准的tcp/ip和modbus tcp共用，切换配置块就行，分别连接tcp助手，MODBUS SLAVE,并且把连接成功标志传给Q点作为输出（我就是以此来判断是否可以连接成功的）对于TCP啥也不能发，没找正确格式，你发啥内容都是发三五次就掉线，MODBUS tcp 利用助手是可以发点数据进去的。
tcp连接确实会踢掉捣乱的设备，所以写程序的时候一定要做一段自动重连的程序，modbus tcp也是的，时刻检测连接成功标志位，掉了就重连，这种现象发生的原因就是数据帧丢失，这个丢失不是丢了，而是一段完整的报文被截成了两段，前段收到了在允许时间内后段还没收到，数据包不完整，超过时间就认为这个是捣乱的设备，舍弃接受的数据，并将其踢掉，确保服务器正常为良好工作的设备服务。

谢谢"121111115"更为详细的案例解说