ＰＬＣ用户普遍反映编程困难，这里面的一个重要原因是程序的可重用性太差。
在其他计算机行业中，程序都是划分成模块来开发的。首先开发许多函数和过程，然后把它们组装成完整的程序。整个程序呈现出一个良好的层次性结构，程序复杂性得到良好的控制。此外，程序开发中可以大量使用前人开发的程序库，所以，复杂的任务也可以通过简单的方式来解决。
在ＰＬＣ程序语言中，虽然也有过程和函数机制，但是程序员很少使用它们进行编程。许多ＰＬＣ任务也不方便用函数和过程来表达。
比如，中华工控网上的一个案例：用一个按钮控制ｎ（n=10）个灯的开关：
http://bbs.gongkong.com/Details/201212/2012121822254300001-1.shtml
如果是在计算机的其他领域，类似的问题肯定会用一个带参数ｎ的过程来写，设置n=10就控制10个灯，
设置n=5，就控制5个灯。可是在这个题目的众多解决方案中，没有一种是采用这种方式书写的。
带参数的过程可以保留起来，便于在其他场合重新使用。使用者也不必知道
程序的具体实现原理，只需要调用这个过程，设定参数，就可以使用这个过程。这样一来，程序设计
就得到简化。再进一步，人们可以用大量过程和函数构造程序库，把常见工作归结在程序库中，其他
用户在需要时直接调用程序库中的程序，极大地方便了编程。
但是在PLC领域中，构造过程并不方便，因此也就更不能构造程序库。所以，每次编程都需要从头做起，
这样一来，编程当然就困难了。
为了解决这样的问题，我们的建议是构造可重用的程序，下面是我们做的一个网页：
http://www.lingcore.com/plc/lib/
这个网页上把一个按钮控制n个灯的问题做成一个参数化的程序，用户输入灯的个数，
输入变量名字，第一个输出变量名字，一个对应的程序就自动生成出来。比如，
设灯的个数为8，输入变量为I0.2，输出变量为Q0.3，按下提交键，在文本框中就出现一个控制8个灯
的S7-200指令表程序。把这个程序复制并粘贴到编辑器中，然后保持到一个.awl文件。
在MicroWin软件中导入这个文件，就可以看到这个程序的梯形图。
如果在你的程序中需要这一功能，就设置一组合适的参数，然后把得到的程序插入到自己
的程序块中，实现程序重用。
如果有网友希望把自己的程序通过这种方式做成参数化的可重用程序，我们可以提供帮助。
在集成电路行业，现在的电路设计方法并不是从头开始设计，而是使用IP。一部分人
专门写IP，另一部分人把IP组装起来成为最终设计。
未来的PLC设计也可能采用类似IP组装的方式进行开发，一部分人开发可重用的PLC的IP，
另一部分人直接使用IP做系统开发。

写了那么长，辛苦了，不就是在描述FB，FC么。
Good Luck~

PLC中的功能块可以解决一些模块化问题。但是也有很多问题它们解决不了。前面讲的例子就是其中一个。您可以试一下写个功能块去解决”一个按钮控制n个灯“的程序，功能块中设置 一个输入n，输入3就成为控制3个灯的程序，输入10就成为空中10个灯的程序。很想拜读一下您的程序。
下面的网页上有这个问题的描述，以及许多网友的实现程序：
http://bbs.gongkong.com/Details/201212/2012121822254300001-1.shtml
这些程序写得很巧妙，但只能针对10个灯的情况。现在的问题是把这些程序改成含参数n的功能块，使它们能够处理任意n的情况。

引用 lingcore 在 2013/2/26 10:50:02 发言【内容省略】

嗯，提供一个不完善的程序例子：
不完善的地方在于，没有对于输入的灯的编号机型限定，这可能导致数组越界。
程序实现的功能是：控制指定编号的BOOL变量的ON，OFF，当该变量为OFF时，则转为ON，否则为OFF，程序中仅实现了50个BOOL变量的控制。
当然，如果要实现10000个BOOL变量的控制，无需更改程序，仅需要对数组的大小重定义即可。
Good Luck～

下面的程序是三菱的GX Works软件编写的，同样是没有对数组下标进行限定的不完善例子，松下的FPWIN PRO，菲尼克斯，腾控……等支持IEC61131-3标准的都可以这样做，至于你中国工控网中例子，均没有使用支持IEC61131-3标准的软件编写，其灵活性大大的受限，因为其对数组的灵活性较差，不过特例是AB，AB的软件的梯形图支持数组作为变量。
同样，要增加控制数仅需要修改变量的数组元素即可。
Good Luck～

引用 cvlsam 在 2013/2/26 14:14:38 发言【内容省略】

很感谢花费时间对数组功能做了详细介绍。这方面我过去关心的不够，有关资料也比较少，所以上面的一些表达需要做一些改进。
使用数组也存在一系列问题：
1. 一些低挡PLC尚未直接支持数组，而抵挡机的用户量很大；
2. 使用数组不如直接画梯形图直观；
3. 把程序限制在简单梯形图的范围内，将会使程序有比较好的可移植性；
4.最重要的一个问题可能是：基于数组的程序对调试的支持比较差。
在梯形图的调试过程中，我们可以看到那些输入条件ON 引起了输出ON。一条数组赋值语句相当于
多条梯形图。在梯形图程序的调试过程中，我们可以看到，多个输入为ON，引起了多个输出ON。
而目前的数组赋值语句似乎还没有这样的能力。
举个具体的例子，铁路信号灯控制程序。铁路划分成n个区间，每个区间都有检查列车占用情况的探测器，
也有信号灯。控制系统要根据列车在区间占用的情况去开亮信号灯。一旦某个区间被占用，不但
这个区间亮红灯，前面的区间要依次亮黄灯，黄绿灯等等。铁路上同时又多辆车在运行。因此在
程序调试过程中需要看到多个区间信号的相互作用情况，单看变量表示不够的。
更复杂的问题就是要自动分析轨道信号的错误，防止列车追尾。比如在723事故中，列车占用轨道
的情况没有传递出来，也就是说控制系统收到的信号有错误，因此就需要通过对多个区间信号变化
的情况来自动分析这种错误。在梯形图仿真过程中，可以清晰地看到各个变量变化的相互关系，对
程序调试提供很好的帮助。数组语句达不到这种效果。

引用 lingcore 在 2013/2/27 4:30:47 发言【内容省略】

1、既然讨论到PLC的发展趋势，那么就不应抱着低档机型来讨论，因为你也有说过，第6代编程平台，而目前IEC61131-3已经成为国家标准，那么自然厂商都有支持该平台的编程工具，所以低档机不支持数组也将会在下一代机型中被更替。
2、作为PLC的发展，势必向着Pc的平台进化，所以其编程格局已经向着高级语言发展，梯形图已经不会被作为编程的主要语言，这一点在大型系统上已经日益显现，PLc的编程者已经不再向以前那样的电气工程师，而是程序员了。
3、梯形图在不同的厂家是不能互相移植的，即使支持IEC厂家也如此，因此梯形图的移植性是非常差的，很多场合你不得不重新画梯形图，这对于程序员来说是很繁重的工作，而St语言你甚至可以使用轻量级的文本编辑器就可以实现移植。
4、所谓的调试比较差那是基于老一代的PLC程序员从电工出身，对于Pc的高级语言编程基础较为薄弱，而当今的调试技术中，已经不能常规的看梯形图监控来实现调试了，需要设置断点等一系列暂停程序的方法来进行调试，否则，调试的效率是极差的，在IEC平台上，无论是梯形图或者FBD，Il，St甚至于SFC都是通过变量监视窗口进行调试的，鉴于你使用的西门子S7-200系列PLC，你可以尝试使用一下西门子的Step7或者博途软件。
Good Luck~

引用 cvlsam 在 2013/2/27 5:55:05 发言【内容省略】

您的意见很值得继续探讨，不过现在手头有点事，过两天继续讨论。

这个主题的讨论比较好。

IEC标准已经出现十几年了。虽然在大中型机器上很普及，但是在小型机上极其罕见。按理说厂家早有能力在小型机上实现IEC，很可能他们并不愿意这样做，他们未必愿意让用户程序移植到其他厂商的机器上去。
对大中型项目而言，IEC标准可能过于简单，许多复杂指令依然依靠各厂商自己的功能指令。这样一来，程序依然难以移植。
IEC并没有达到统一语言的预期目标。未来也未必能够做到。正因为如此，才需要另辟蹊径。我们确实已经有了一些革命性的解决方案，但是离开成熟还有一定距离。不过我们可以用这些技术为别人提供一些帮助，比如PLC程序的测试，见plc.lingcore.com。另外一个方向，就是把现有的程序转换成可移植的程序，成为可供大家分享的库程序，比如http://www.lingcore.com/plc/lib/
虽然函数和功能块等概念过去就存在，但是，我们还从未看到一个公共领域的PLC程序库，至少在小型机范围内，还没有形成一个利用库程序进行PLC程序开发的风气。
理论上讲，可以用IEC函数和功能块构造某种程序库，但是，至少在小型机范围内不会很快看到这样程序库。
正如你所说，在IEC技术下，只能通过ST来实现程序重用。即使是IEC的梯形图也不能实现程序重用。这里，我们又要转入一个大家讨论了很长时间的问题，究竟梯形图还有没有前途。这个问题有争议，但有基本事实是，目前大部分用户还在使用梯形图，这种状况也不会很快改变；即使有一个基于ST的程序库，在最近的将来，小型机用户依然无法使用。另外，我认为梯形图是设计和理解PLC算法的很好的工具，正因为如此，大家都主要依靠梯形图来交流算法和编程心得，大部分教材也用梯形图来讲解。
我们的设想是，在程序库中放上可以转换成梯形图的指令表程序，这样的程序可以在现有编程软件中直接转换成梯形图。此外，这些指令表程序可以通过参数化方式改变。这样，一方面满足了大部分人的编程习惯，另一方面又实现了梯形图的重用。