借助以太网，PLC间的数据交换可以通过S7、TCP、ISO、ISO-on-TCP等传输协议来实现。而TCP/IP和S7是大家常常使用的两种典型协议，大家在使用上述两种协议通信时常常会有如下一些疑问，例如：
1，S7和TCP有什么区别？
2，S7还是TCP/IP快？
3，为什么通讯设置有些需要设置MAC、IP、TSAP等参数？
4，S7和TCP/IP需要考虑数据一致性吗？
5，S7和TCP/IP的连接资源一样吗？
6，S7-300的S7通信和S7-400的S7通信的区别？
等等。
开设本专题，期望和大家共同交流，彼此帮助，来澄清技术要点，为今后的工作带来更多便利。不局限于以上的问题，欢迎您提出任何相关的疑问或见解。
活动奖励：
此次集中交流将持续至5月4日，其中所有精华帖作者将获得加倍精华奖励积分；最终所有有效留帖的网友将获得加倍发帖积分。更多积分带给您更多奖品兑换的自由。
对于有突出发言贡献的网友，还可以在当前的可兑换奖品中免费挑选任一款奖品。
交流结束后也将专门整理重要内容，供广大网友分享参考。
预祝大家交流愉快，收获丰富！

我觉得西门子PLC之间的通讯，还是S7好一些，毕竟组态更为方便快捷。
TCP的话，如果是PN口的PLC之间的OPEN IE通讯，除了程序中要调用功能块之外，还得生成UDT块配置通讯连接，较为繁琐。

但是，如果涉及到PLC和一些非西门子的上位软件之间的通讯的话，TCP的连接就太方便了，连OPC都省了，上位软件直接加一个TCP的驱动就可以了。


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

关于协议通讯，我认为速度由快到慢应该是profinet(对TCP堆栈结构进行了处理)、ISO、UDP、TCP、ISO on TCP、 S7。 TCP和UDP虽同在第四层，但是有区别的，TCP保证数据能可靠并且按顺序到达，是完全可靠的连接传输，然而资源要求也比较多，结构也比较复杂。TCP首先需要在传输方的两端建立一可靠的连接(通过信号的三次握手)，然后通过数据包的各项校验确保数据完全正确。做过带握手协议的底层编程会帮助理解这个问题。UDP设计初衷就是尽可能快的将数据包发送出去。所以UDP协议显得非常精简。只要建立一个包，构造一个有目标信息的IP头，然后发出去。无需连接。
3"ISO协议是面向于数据块的，而TCP/IP是面向于流的",的确，TCP包是流的，没有边界，ISO发送的是离散的对象，需要有数据结束标志。 西门子PLC的ISO on TCP是附加了RFC1006,但实际上不能说ISO on TCP就是RFC1006，因为ISO on TCP还可以附加RFC983,RFC2126等协议。 针对TSAP，他的全名应该是TCP service access point，也就是TCP的服务访问点。其实这个问题解释起来比较复杂，可以从ISO/OSI参考模型说起。这7层之间如果想通讯，就是通过SAP来完成的，不过每一层的SAP都是具有不同名字，例如IP层的SAP称为ISAP。这些是很专业的术语，OSI/ISO对应的TCP/IP的模型中，TSAP对应的就是Port，即端口号。这也就是说SAP是层层之间的寻址而且要唯一。对于ISO协议来说，没有IP层，那么意味着不能路由，所以寻址只能通过MAC地址。对于访问高层的应用程序就需要TSAP了。不过你在Step7组态时，不需要改变任何的TSAP，因为Step7自动生成了符合ISO协议的TSAP标识。这要下载这些组态信息PLC之间就可以相互识别。 我认为S7协议是一个大包，也就是MPI,PROFIBUS,Ethernet上的S7协议部有区别的，因为S7协议毕竟是第7层的协议，由于所嫁接的底层协议毕竟是不同的。所以这种多样性就是复杂性的一种体现。另外，对于细节协议，S7协议的应答十分两步的，首先是对协议层的应答，接着应答应用层，这也是它的复杂性。Step7在NetPro中作的很普遍，所以不易察觉。 ISO on TCP不需要组态MAC地址这是真的，因为应用层寻址并不是依靠MAC地址，而是依靠IP和Port来完成的。在TCP上加入不是ISO的校验机制，而是ISO的协议与其连接。因为ISO协议与TCP协议是不同的，ISO协议是面向于数据块的，而TCP/IP是面向于流的。其协议的本质就是有没有数据的结束标志。 对于SAP，不用考虑太多，它只是层与层之间的桥梁，所以向下向上都会有SAP，而在Step7中所显示的SAP往往是向上的，因为应用层毕竟是相对独立特殊的，不像TCP/IP那样普遍。在任何时候都需要建立的，只不过在TCP/IP中你看到的是端口号。 对于Step7 TCP的连接可以有两种方式，一种是通过Open IE的方法，通过功能块确定Server/Client的关系来实现动态的一种连接，也可以断开这个连接。PLC对于这个连接个数同样是有限制的。另外一种就是在NetPro中建立TCP连接,当下载组态后，连接自动建立，但这个资源不能动态释放。连接一旦建立，数据就开始通讯了。不过每个包数据的大小并不是我们决定的，而是TCP的滑动窗口算法决定的。所以使用TCP协议时，速度的快慢不是我们所能把握的。另外流的概念就是你所接收的并不一定是你所发送的。而数句块的概念所接收的一定是你所发送的。

确实如此，比如编程方式影响也很大，接收块执行速度过慢，发送速度快于接收，所以应保证发送块速度不快于接收速度，即保证均衡“节拍”。例如把发送块放到OB35中执行，接收块放OB1中来提高接收速度，就会减少数据的通信较长延迟，达到最佳效果。


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

CCP 是循环控制点，就是说操作系统管理扫描周期的一个时间段。
S7300，S7400的扫描周期是分成很多时间片的，每个时间片里除了执行用户程序外，还执行通讯程序和操作系统程序。


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

的确，我也不喜欢用固定脉冲触发，在STEP7 V5.4 SP3 的帮助中有一个TCP通讯例子，但是在V5.4 SP5中例程却没有了。OB1中例程如下：
CALL FC 5 (
ACT:= M100.0,
ID:= 1,
LADDR:= W#16#100,
SEND:= P#DB100.dbx0.0 BYTE 240,
LEN:= 240,
DONE:= M100.1,
ERROR:= M100.2,
STATUS := MW102 );
R M100.0;
SET;
A M100.1;
JC done;
SET;
A M100.2;
JC err;
BEU;
done: S M100.0; BEU;
err: NOP 1;
NOP 1;
S M100.0;
BEU;

OB100中例程如下
SET
S M100.0
通过以上的TCP发送例程去处理的通讯的话，应比定时脉冲触发要好，但有一个问题，FC5的DONE信号应该是CP发送数据完成信号，就是说接收方确认了发送方的数据。这时候再继续发送下一包数据，就不会产生发送拥堵的情况。呵呵，我觉得这样才能更好的保证发送和接收的平衡。
我觉得例程中对于错误的处理简单了些，比如说对于8302H号错误，说明接收方已经来不及处理发送方的数据了，这时候还要继续发送？？这时候应该根据实际各错误代号分别做出处理，或者在界面上提示出错信息，由操作人员要选择处理方法。


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

二者处在的ISO/OSI模型中层面不同,WINCC中的S7属于PG/OP的S7(加载了ISO或TCP)是第7层,而STEP7组态时有ISO属于第4层,STEP7中的S7(加载了ISO或TCP)也属于第7层,就是说对于以太网,应用层的S7协议可以基于ISO也可以是TCP协议,其实STEP7中硬件组态中,那个复选框选择<设置MAC地址/使用ISO协议>是否"打钩",就是选择是选择ISO协议还是TCP协议,相当于WINCC中的INDUSTRIAL太网通讯（ISO协议）和TCP/IP两种协议.如下图




管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

建立一个UDT就可以了。然后DB块里增加一个UDT类型，然后在DB块里的Data View里修改下几个参数值就可以了，比如IP地址，设备类型，作为服务器还是客户机，端口号。别的基本不用动。有几个连接就建几个


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

是不是检测通讯是否正常，如果超过一定时间通讯中断，PLC就释放TCP连接资源呢？


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

KEEP ALIVE如同一个心跳信号,TCP通讯的一端发送这个心跳信号来判断TCP连接是否正常。前面讲到TCP通讯时网线断了再恢复的时候会收到旧的数据。这时如果把KEEP ALIVE超时时间设的小一些，当网线断了的时候就会在短时间内判断出TCP连接出错，并且TCP协议会自动关闭连接。当网线恢复正常时，TCP连接会重新建立，重新发送、接收数据，这样就不会收到旧的数据了。呵呵，TCP能够自己干的很好的事，干吗再去调用AG_CTRL判断呢!
不知道理解的对不对，谢谢技术支持!


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

谢谢凡烨和各位的解答！
看来对于优化CPU通讯负荷来说，还是OPEN IE方式好一些，通讯完成后可以通过FB66注销服务，把连接资源释放掉，减轻CPU负担。不象NETPRO IE的静态连接那样对通讯资源永久占用。但可以利用一个连接执行多个通讯任务（可根据具体工艺情况，各个任务根据条件“互锁”），弥补这个不足，毕竟连接资源是有限的。另外300的连接资源远少于400，所以有CP多路复用功能因仅占用CPU一个S7连接资源也能使连接资源相对“宽松”一些。


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

确实，这几个问题都是与之前的讨论相关，譬如数据一致性等。
1、S7通信：
BSEND/BRCV:
done信号的产生：数据发送是分段的，每个分段接收方都有应用层的回复确认，最后一个分段确认之后，发送方产生一个done上升沿信号，而且一次发送只产生1个done上升沿信号。done信号表示本次通信任务结束，即数据已被成功的发送到对方的数据接收区。
USEND/URCV：
done信号的产生：数据的发送在应用层没有对方的回复确认，所以新发送任务存在覆盖上次发送数据的可能。done信号表示本次通信任务的结束，即数据已被发送到对方的接收缓存区（注意：不是对方的数据接收区），至于数据有没有从对方的缓存区读取到接收区，USEND/URCV这种机制就不管了。所以不是很靠谱啊。
PUT/GET：
done信号的产生：与BSEND/BRCV类似，也是数据被成功接收到数据接收区之后认为是本次任务的结束，产生Done上升沿信号，不同的是通信量小，不分段发送。
S7done信号的作用及使用：用done信号来保证发送数据的一致性，将done信号串到发送数据更新（赋新值）的条件中，即没来done信号之前，不允许发送数据的更新。
NDR信号：NDR信号表示数据从接收缓存读取到本方数据接收区。

OPEN IE TCP：
done及busy信号的产生：数据的传送要途径 本方发送缓存---->本方网络堆栈区---->对方网络堆栈区---->对方接收缓存；数据只要从本方发送缓存成功的压入本方网络堆栈即认为数据已发送，即产生done上升沿信号；如果后面的堆栈区包括对方接收缓存都满了，从本方发送缓存数据没有压栈成功，则产生busy信号。
NDR信号：NDR信号表示数据从接收缓存读取到本方数据接收区。
done及busy信号的使用：用于数据流量控制，避免网络堆栈区堆满。
先谈这么多，欢迎讨论啊。


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

一楼不落的看完各位大侠的留言，有如下想法：（个人意见）
很多朋友的在问工业以太网和以太网有什么区别，区别为：实时性（主要）和防干涉、防护等级等。
其很多地方都有自己的出入和偏差。甚至是西门子先入为主的偏差。西门子上的ISO=工业以太网 这个是有偏差的，甚至说前面这个等号也是大家经常就这么认为的也是一个偏差。并不是说不使用IP层（标准说法应该是网络层），仅使用数据链路层（MAC）就是工业以太网。也不能说使用了IP协议，可以路由的就不是工业以太网了。只表面现象看上去确实如此，因为大多自动化控制的工程人员都不甚了解OSI模型和TCP/IP模型，他们不知道即便是用了IP协议，在报文中也是有携带MAC的。因为他们很少接触到arp与rarp这两个协议（IP和MAC互相解析的两个协议）。
我所理解的工业以太网实际上是没有一个准确标准和协议的（虽然在06年07年北京有个国际性的关于工业以太网的标准化结果），工业以太网：要求是实时性高，而传统的以太网采用的是CSMA/CD(带冲突检测的载波侦听多路访问),当你的带宽越大，负载（信息点，即信息源）越少，实时性越高。这牵扯到冲突域等等一些列的概念。而现在西门子和德国的另外几家（抱歉，名字记不住，E文不好）在交换机硬件上和软协议上所做的工作都是为了提高其实时性。工业以太网是一整套技术的综合，比如通信设备线路的防护等级，信号干扰的屏蔽。这也是经常为什么我们鄙视那些使劲鼓吹某个项目是怎么怎么的厉害的优良的工业以太网云云的人，因为他们用的交换机居然是普通的桌面交换机，双绞线也是劣质，非屏蔽，RJ45接头也是非屏蔽的……
个人意见，仅供参考。（鄙视自己，觉得有点愤青啊！）再次感谢大家的回答，我学习了很多东西。特别是前面有个大侠说西门子的“路由”是两个概念。这让我豁然开朗，我很长一段时间来都不明白西门子的技术支持工程师说的“路由”，原来我理解的一直是网际路由。可爱西门子将不同介质间的数据传送也叫“路由”。现在我明白了！ 这个也就是偏差！可爱！


管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

呵呵，对计算机也有爱好了。可惜，末了。我还是干了一个我零基础的专业！
回答你的问题，如下是我的建议：
1.在组织相关讨论之前应该邮件告知大家，让更多的人参与。
2.在描述和回答相关问题的时候应该尽量多写字，写清楚，写仔细，写通俗，做到明明白白。因为其实参与的人还是很多，不是每个看了帖子的人都在回复。其中大多看帖的人和我一样确实没有基础，但是他们也应该是讨论的参与者，至少可以提出问题，即便是这些问题在各位高手看来是太基础的问题。所以希望大家问个明白，也希望高手们答个清楚，你不是在回答一个人，而是日后看这个帖子的很多人。
3.给大家多指点学习的方向文档。毕竟我们大家做的都是工业用的，甚至的西门子专有的技术。baidu，google也有回天乏术的时候。你们慷慨给个连接，或者是给个E-mail让大家有所提升，以后自然有更多人可以和你一起深入的讨论。
在这里我不怕各位笑话举真实一例：
2年多点前，我毫无电气，自动化控制基础的第一次接触工控，第一次接触除电冰箱以外的西门子——WinCC。第一天我看电子文档，我问了身旁一个老同事个问题。请问内部变量和外部变量有何却别？同事答：外部变量是外部的变量，内部变量是内部的变量（真实的，我一字不落的记得！）。4个月后，我已经啃完了wincc高级编程组态手册，干完了一套轧机生产线的HMI，基本上公司对外的wincc相关技术支持都是我在做了（我们是系统集成商）。
公司新来了一位同事，领导安排我带他，他的师父就是那位老同事。他就在当天问了我4个月前的那个问题。我让他先问他师父，回答结果一样一字不落——外部变量是外部的变量，内部变量是内部的变量。看来那老同事不是不想回答我了，而是思维定式了。我慢慢回答了他这个在各位看来简单至极的问题：简单理解，WinCC内部变量是储存在计算机上的变量，他们是内存中开辟的某一段地址的临时存储，具有掉电不记忆的特征。WinCC外部（过程）变量是在存储在PLC上，如有必要可以保存在PLC上，而不会像在计算机上的内部变量一样，重启就没有了！……
虽然我当时这样回答可能也不是很好，但是我至少自己知道这是两种态度，两种回答问题的方式，所以也就有了两种答案。所以我自己总是尽量在4008104288的时候将自己的问题描述的详细些。so，我们在论坛里面讨论问题的时候，尽量说得清楚点，参与的人也就更多。这里也再次对CS工程师们的辛苦便是感谢！

是啊，很多资料都是告诉你一个结果，却不告诉你内因。
所以，在应用中，都知道应该怎么怎么做，但却很迷糊为啥要这么做。长久更形成思维定势，失去了刨根问底的动力。
说到底，还是基础知识薄弱，理论知识太差。这也不能完全怪我们，自小到大的教育就这样，只看直接的结果，却忽略内功的修炼。直接造成理论和实践脱节，一直达不到融会贯通。

所以，很感谢这样的帖子，能给像我这样的人普及下一些理论知识。但是，看前面很多大侠都很谦虚，因“水平原因”不愿意加入到帖子中来，我想，这就和帖子“重在参与交流”的目的相违了吧。我就一直在鸭子跟鹅闹，我所认识和理解的虽然可能幼稚可笑，但起码也能起到一些反面的例子吧。我之前的一些迷惑也渐渐开朗，虽然完全理解尚需时日，但进步依然不小。再次感谢凡侠，以及各位大侠，还是希望都能各抒己见，畅所欲言，因为这样的机会难得！