S7-200的子程序SUB，一旦写好，用在程序中之后， 是不可以修改其输入输出管脚的。 因为你一旦动了管脚接口，调用这个子程序的地方，就会报错。

报错以后还没法和STEP7一样可以通过更新只更新改动部分。正常处理的只有把原本的调用删掉，从头重新调用，并为每个接口逐个分配变量。

这相当讨厌。

比方说我一个底层的设备，如果调试中发现需要增加些功能，实在不可避免决定要增加接口。而我主程序中已经对这个设备调用了几十次，那就必须几十个实例都重来一遍。

而这还不算完。

谁敢保证这一次接口的变更就是*后一次了呢？下一次如果还需要修改，就需要原样再来一次。

估计换谁，都受不了这种折腾。

而这也是标准化编程的大忌。

貌似许多人对标准二字有误解，看到我提出的标准化，就有些不服气。你万某有何德何能提出标准，俺们智力才艺都不比你差，凭什么要遵循你提出的标准，凭什么用你的标准而不是我自己的标准？我们国家历史上因为技术标准落后一步而受制于人，吃的亏大了去了。可不能重蹈这样的覆辙！

而另外有一些人，则强调没有办法做到整齐划一的标准。理由是设备配置千差万别，没有一模一样的设备，所以做不到标准化。

错啦！都是属于对标准化的误解。我们追求的标准化，是把系统做成搭积木一样的标准模块，每个模块自成体系，逻辑互不干扰。通过接口与其他系统模块对接，不同的系统设计，在接口不变的情况下，只需要更换相应的模块，即可以实现快速组装。

而接口，也不是一尘不变的，可以根据需要随时改进，而在接口改动的时候，也只是对接的模块之间局部变更，不要影响到整个系统。不会因为接口的改动，而需要系统重新调试。

甚至，我现在推广了二期标准化示例项目之后，下一步的计划就是对接口的优化升级。过去，我在开发阶段，采用的接口只是借用的别人以前做的，现在终于有精力，腾出手来，把接口改造为我满意的样子。

而我和我的团队成员，丝毫不需要担心接口的更改会导致影响到已有逻辑模块的运行，甚至带来bug。

这就是标准化设计的优势。心不累。不需要和以前一样，程序中改动一点点就紧张万分，就担心把整个系统原本正常运行的功能搞崩溃。 

所以，我在开发SMART 200标准化架构的时候，首先就意识到子程序（库函数）接口不能更改的这个问题很严重。并认为有可能是众多人都不愿意投入精力在SMART 200系统做标准化的主要原因。

所以首当其冲必须解决这个问题。

我在写文章《【万泉河】SMART200也能做标准化》时，提到了我解决了其中一些关键细节，其实其中*个便是搞定了子程序可修改的问题。原本是我打算在培训课上首先传授给学员的*课的内容。趁这次征文机会，写出来，与大家分享。

而实现方法，其实很简单。

即利用程序块的导出功能，把调用被改动的子程序导出为AWL的文本文件：

然后在文本文件的调用中，修改到符合新版本的函数的语法，再重新导入即可。

这里存在的问题是，不管是导入还是导出，操作之前软件都会自动编译，编译通过后才可以进行。所以导出必须在修改接口之前，而在修改接口之后，导入之前，需要把相应的SUB内发红的段落先删除。

因而实时的存盘备份非常重要。千万不能上来就改接口改子程序的逻辑，改过之后发现既不能导出又不能导入，那就尴尬了。

由于AWL文件中是绝对值寻址的，所以界面非常不够友好。我通常是在文本修改阶段，只管语法正确，比如增加的数值变量，就先填上AC0，如果是离散变量，则暂时输入L0.0，等导入成功之后，在梯形图界面下，根据实际需求，更改为正确的变量。

当然啦，如果有可能，尽量直接用搜索替换比如把原有的”AC0”替换为“AC0,AC0”。速度会快很多。

所以，在使用标准规范中也包含了同一个类型的设备对象，尽量在同一个SUB中调用。这样导出修改接口的时候只搞这一个文件即可。而不必在整个程序范围去找，去把整个程序的SUB都导出来手工修改。