4年前做的一个项目近期又扩展，发现扫描周期达到了50-100ms，只好开始优化程序。由于有大约300个模拟量（都是单极性，实时性要求不高）要读取转换，我首先放弃了FC105自己编了个小程序（同时改原来的LAD为STL）转换，然后分周期分批读取，发现扫描周期平均减少了近10ms，现在还想近一步优化，那些方面的更改可以进一步减小扫描周期？用循环和不用循环哪个更快？
抛砖引玉，欢迎大家都来讨论下。

版主的问题提的太专业了！而且最后的总结陈词也很实际。干了这几年自控系统后，个人也是觉得，国内的项目如果按照100分来评价的，打60分和打90分区别真的不大；因为往往甲方只要能够满足其基本要求，其他的美化，优化的措施并不在意。而且往往商务手段要比技术处理更重要。

其实干了这些年自控和西门子的产品，还真没有系统的研究和学习过扫描周期，程序优化这方面的知识。只是跟着前辈们去学习编程习惯。惭愧啊。。。。。。

对于版主的提问，我的回答如下，请指教：
1.扫描的稳定性：只要保证CPU的负荷不是过高的情况（我认为最好不超过80%，我记得默认好像是>90%系统报警）下，扫描的稳定性就可以得到很好的保证；
扫描周期的长短：这个还是要根据不同类型信号的要求满足。我一般吧开关量放在OB35(100ms)里，模拟量放在OB33（500ms）里，对于SOE这样要求1ms的扫描周期，使用特殊的处理模件，特殊处理方式。

2.客观来讲，如果按照同样的扫描处理的话，程序的多少自然会影响扫描周期的长短。版主的意思应该是如何优化程序，处理程序是非常重要的。这个我严重支持。对于这个方面的想法我没有太多的心得，因为我做的项目大多为PCS7，都是模块化的编程。只是对于程序的处理方面我一般尽量少功能多的功能块。同时对于功能块的RUN SEQUENCE优化，我往往都要做，而且按照不同的类型，分成若干个运行组；还有就是对于过程映像区的使用，自从有了PIP区的出现，我就一直使用这种方式；因为在我看来西门子的这发面的优化肯定是有其道理的。
对于前面提到的COMMUCATION JOB，诊断数据区的处理，我一般都是不做的。只有在程序量大，内存小的情况下才去降低这个数据区的；

3.对于扫描周期长的问题，当然升级硬件是最好的选择；但并不是好的硬件，程序的优化就不重要了。还是两者并存是最佳选择。但硬件的升级往往不是以我们的意志为转移的。因此程序的优化还是尤为重要的。

4.对于现在的硬件能力来说，好的编程习惯看起来好像影响并不大。但对于某些特殊情况，比如能力差些的CPU带点数较多的情况下，这个时侯好的编程就会有很大的优势了。至少可以降低CPU的负荷。

5.扫描周期长短的判断标准，我不清楚。版主可否赐教？我一般认为中断扫描肯定比循环扫描时间短。而且程序做好下载到CPU后，可以在线查看扫描周期的长短。如果判断扫描周期长的话，我的第一反映就是优化程序，减少程序量；往往会将开关量的驱动块去掉；将模拟量监视块去掉，自己更改变量属性上传到WINCC中，报警自己编写等方法。

6.在编程序之前往往要考虑CPU的能力，是否能够满足设计I/O点数的需求，是否闭环回路较多，模拟量数量多少这些问题，才会去考虑如何编程的。如果CPU能力很强的话，那自然使用库中的功能块，这样省事，规范。如果能力稍差，就考虑自己去降低程序量的方法。

回答的很肤浅，请各位高手多多指教！

“程序多扫描周期不一定长，程序少扫描周期却不短，刻意追求简短的指令往往适得其反；”---的确是这样，记得以前看过一篇文章，是两个单按钮起停的程序，一个是用位逻辑，一个是用字逻辑（字异或），位逻辑代码多，字逻辑代码少，虽然字逻辑的代码简洁，可它的执行时间却更长一些。
另，用指针做循环可以有效减少代码量，减小内存占用量，我以前一个同事在做一条电镀生产线时，因为不懂STL，就只好用LAD做赋值，当时做了几百个赋值，占用了大量的内存空间，导致最后程序空间不够用，后来改为用STL做循环，空间节省了很多。但因为指针方式访问数据要寻址两次，最终执行时间还比直接赋值要长一些。呵呵，这时就是以时间换空间了。

把单个扫描周期里的循环分配到不同的扫描周期内处理,但是不适用于快速响应的要求,我在做温度处理时基本上都是这种方法

1.OB1循环扫描必定和程序有关。如果使用OB1的话，自然是按照程序的编制顺序扫描，这样不论执行那段子程序，都要执行全部的扫描。这样扫描时间必定长，扫描周期也必定大。因此最好还是使用中断扫描的方式。
2.中断扫描：我不知道我的理解是否正确，请高手们给予指正。
中断扫描是按照既定的时间去执行扫描，比如OB35默认100MS扫描一次。但扫描这一次的时间有多少，就要根绝程序的编制方法与数据量有关系了。如果使用了过程影响区，那寻址方式一定是到OB1 PI,PIP区去查找。这个时候对于过程影响区的优化，也是减少扫描周期的一个有效的方法。
3.对于运行组（PCS7方式）的考虑：OB100的初始化，中断OB的使用，将数据块，功能块按照不同的类型分配成不同的运行组也是对扫描方式的一种优化，原理上应该同过程影响区的寻址方式类似。因此这个工作的也应该可以减少扫描周期；
4.1，2，3讨论的都是用户自定义程序部分的优化措施。但对于一个完整的系统来说，CPU才是核心。系统默认的一些参数往往我们都不会去更改。但在特殊情况下，系统允许更改的一些参数也是可以降低整个程序量（系统数据+用户数据）的，降低一些通讯数据区的大小，诊断数据区的大小等等也会降低程序量，自然也会降低对系统数据的扫描周期。

其实，我认为，对于系统参数的更改方式尤为不可取。尽量不要采取这种方法处理。还是要尽量在程序的编程方式上做文章。
对于程序的编制方法，怎么做是最合理的？我的方法再上面的帖子里已经提到。
我期待着高手们的详细解答！

扫描周期时间包括OB1的全部扫描时间,还包括对OB1进行中断的更高优先级的程序的扫描时间。
扫描时间也包括操作系统的运行时间，有如下内容：
1.过程映像的更新时间，取决于映像区的大小
2.定时器的更新时间，取决于要更新的定时器的数目
3.CPU的通讯功能占用的时间，取决于CPU的通讯功能的数量。
4.操作系统对于周期扫描的控制时间，这是一个固定值
对于优化OB1的扫描时间，可以采用各种编程技巧来实现，比如说减少浮点运算，少用间接寻址，多用STL编程等。至于采用类如把程序放入OB35等定时中断中的方式能减小扫描周期时间，我觉得还需要探讨！因为这时候，操作系统相当于先把OB1暂时挂起，再来执行定时中断的功能,等中断程序执行完之后，再继续执行OB1的程序。这样CPU总的运行时间是不变的，而且可能时间还会加长，因为CPU还要执行保护中断现场和恢复中断现场的功能。
至于减少操作系统的运行时间，结合上面的几条，无非是减少映像区的数量，减少使用的定时器的数量,减少CPU的通讯功能。个人感觉CPU的通讯功能会占用较多的处理时间，是优化的重点。

正如“四书五经”大侠所说，我PCS7做的比较多；
对于PLC的底层的东东确实很肤浅，很不精通。
PCS7虽然在西门子叫做DCS，但实际上是发展与PLC，基本构造和理念也都来源与PLC，因此我认为他们的核心基础理论和底层开发都是一样的。我想这个应该是肯定的。因此对于CPU的优化，程序的优化应该都是基于一个原理。个人感觉PCS7的很多理念应该都是比较先进和优化的，因此我就凭借自己的使用经验表述。不一定对，希望大家多多探讨。

一般来讲，过程控制里顺控，连续控制，逻辑控制确实不多。 因此也常常都是OB1空操作。
对于过程控制领域，我想不使用OB1应该是允许的。
但对于其他领域，例如冶金行业等这些对连续控制，逻辑控制较多的场合，不适用OB1确实是不妥的。


咋就咱们两个呢？其他高手都潜水？？

说说做的做法吧，从老外那儿学来的。
对于模拟量，每个扫描周期执行1个（或者3，4个，尽量少）,大概预算一下你的扫描周期，比如说30ms（最大）,那么，如果这些模拟量要在1秒内都读一次，那你每个周期执行一个模拟量，你可以只用一个模拟量处理多一点的时候来处理1000/30=33个模拟量。如果有300个,那每个扫描周期执行10个.当1秒钟到后，又从第一个开始执行起来。这不就快了很多吗？
对于检测电机故障或者类似的，大量重复的工作的，我也是这样处理，明显就快了很多了。

至于具体怎么实现大家就自己想想咯。

1。程序的算法优化
2。程序的组织优化
3。程序的空间分配优化
4。总线的通讯参数优化
一般情况下，仅仅的软优化，上面的四个方面是基本出发点。

看图更明晰些， 哪些点会影响扫描周期。但个人以为讨论响应时间是否更能对控制系统的效果有个评判。

每个从站4个字节的DP时间

呵呵，我想说的不是如何缩短PLC的周期， 而是说扫描周期有的时候还是比较重要的，要不然小日本宣传PLC的时候怎么总会提到它的扫描速度？
同样的对于我这个项目，原来用的FX-2N，现在改成FX-3U。质量就有明显的提升。