关于“优化是不是也要从PLC有所考虑？”，我想答案是肯定的，对于WinCC和S7-300/400通信优化来说，在PLC方面还会考虑到以下几个问题：

1. PLC的循环读服务数（cyclic read services）。这是WinCC和S7-300/400通信时，比较独特的通讯优化方式，类似订阅的概念。基本过程可以简单的这样理解：每当打开/切换一幅画面时，系统会统计这画面中所使用的变量及这些变量的更新周期，将这些变量的请求按更新周期分类，形成“订单”并提交给PLC，PLC接受到“订单”后，按“订单”中所指定的更新周期，分批次的主动将数据定时的发给WinCC，而不需要WinCC再去定时的向PLC发请求。这样就可以有效提高数据交换效率。这里的一个“批次”就可以理解为一个“PLC的循环读服务”，而不同的PLC所支持的循环读服务数也可能有所不同，比如CPU416 最多支持32个，而CPU 412只有16个。多台WinCC同时访问一个PLC时，不但会占用PLC的连接资源，同时也会占用PLC的循环读服务数。

 由于每个批次（循环读服务）所携带的数据数量是受到数据报文尺寸的限制，所以要把想要的PLC数据读上来，PLC就可能就会用到多个循环读服务。比如：当前WinCC画面中只有两个IO域连接了一个PLC 中的同一个地址：MW10，不同的是两个IO域的更新时间一个是500ms，另一个是1s，那么PLC会用两个循环读服务将数据发送给WinCC，一个是500ms的循环读服务，另一个是1s的循环读服务。这样的结果是不但多占用了循环读服务数，同时每个读服务的使用效率都不高。

 画面，变量记录，报警，脚本系统等的变量请求对循环读服务的占用也是相似的。

 关于循环读服务可以参考WinCC的在线帮助，里面有较详尽的解释。

2. WinCC使用的变量在PLC中的地址的是否连续，变量地址是否合理。连续地址意味着数据报文中携带的变量地址信息较少，可以简单理解：与数组的概念类似，起始地址信息+变量个数。虽然WinCC S7协议集具体的报文结构没有公开，而且地址排列也有特殊的算法，但对于地址不连续的情况后大概有何种结果，我想大家也能想到。而且也能用抓包和诊断工具看到变化。

 变量地址是否合理：比如：同一个画面（也可以引申到变量记录，报警，脚本系统等）中所需的变量，在PLC中的地址最好连续排列。而若WinCC需要的所有数据都连续放在一个DB块中，但各画面所访问数据零星的分散在DB块中，这种情况下，一些夹在其间的无用数据也有可能被发给WinCC，即使WinCC并没有请求这些数据。

 所以，变量地址连续、合理，可以有效提高PLC的循环读服务的使用效率，从而提高通讯效率。

 另外, WinCC提供的通道诊断 （channelDiagnosis） 工具有很强的功能，在系统没有出现故障时，也可用来查看当前的通道信息，其中会反映所占用的循环读服务数、循环读服务的更新周期等等。建议可以试一试。