电子说
S7-200的子程序SUB,一旦写好,用在程序中之后, 是不可以修改其输入输出管脚的。 因为你一旦动了管脚接口,调用这个子程序的地方,就会报错。
报错以后还没法和STEP7一样可以通过更新只更新改动部分。正常处理的只有把原本的调用删掉,从头重新调用,并为每个接口逐个分配变量。
这相当讨厌。
比方说我一个底层的设备,如果调试中发现需要增加些功能,实在不可避免决定要增加接口。而我主程序中已经对这个设备调用了几十次,那就必须几十个实例都重来一遍。
而这还不算完。
谁敢保证这一次接口的变更就是最后一次了呢?下一次如果还需要修改,就需要原样再来一次。
估计换谁,都受不了这种折腾。
而这也是标准化编程的大忌。
貌似许多人对标准二字有误解,看到我提出的标准化,就有些不服气。你万某有何德何能提出标准,俺们智力才艺都不比你差,凭什么要遵循你提出的标准,凭什么用你的标准而不是我自己的标准?我们国家历史上因为技术标准落后一步而受制于人,吃的亏大了去了。可不能重蹈这样的覆辙!
而另外有一些人,则强调没有办法做到整齐划一的标准。理由是设备配置千差万别,没有一模一样的设备,所以做不到标准化。
错啦!都是属于对标准化的误解。我们追求的标准化,是把系统做成搭积木一样的标准模块,每个模块自成体系,逻辑互不干扰。通过接口与其他系统模块对接,不同的系统设计,在接口不变的情况下,只需要更换相应的模块,即可以实现快速组装。
而接口,也不是一尘不变的,可以根据需要随时改进,而在接口改动的时候,也只是对接的模块之间局部变更,不要影响到整个系统。不会因为接口的改动,而需要系统重新调试。
甚至,我现在推广了二期标准化示例项目之后,下一步的计划就是对接口的优化升级。过去,我在开发阶段,采用的接口只是借用的别人以前做的,现在终于有精力,腾出手来,把接口改造为我满意的样子。
而我和我的团队成员,丝毫不需要担心接口的更改会导致影响到已有逻辑模块的运行,甚至带来bug。
这就是标准化设计的优势。心不累。不需要和以前一样,程序中改动一点点就紧张万分,就担心把整个系统原本正常运行的功能搞崩溃。
所以,我在开发SMART 200标准化架构的时候,首先就意识到子程序(库函数)接口不能更改的这个问题很严重。并认为有可能是众多人都不愿意投入精力在SMART 200系统做标准化的主要原因。
所以首当其冲必须解决这个问题。
而实现方法,其实很简单。
即利用程序块的导出功能,把调用被改动的子程序导出为AWL的文本文件:
然后在文本文件的调用中,修改到符合新版本的函数的语法,再重新导入即可。
这里存在的问题是,不管是导入还是导出,操作之前软件都会自动编译,编译通过后才可以进行。所以导出必须在修改接口之前,而在修改接口之后,导入之前,需要把相应的SUB内发红的段落先删除。
因而实时的存盘备份非常重要。千万不能上来就改接口改子程序的逻辑,改过之后发现既不能导出又不能导入,那就尴尬了。
由于AWL文件中是绝对值寻址的,所以界面非常不够友好。我通常是在文本修改阶段,只管语法正确,比如增加的数值变量,就先填上AC0,如果是离散变量,则暂时输入L0.0,等导入成功之后,在梯形图界面下,根据实际需求,更改为正确的变量。
当然啦,如果有可能,尽量直接用搜索替换比如把原有的”AC0”替换为“AC0,AC0”。速度会快很多。
所以,在使用标准规范中也包含了同一个类型的设备对象,尽量在同一个SUB中调用。这样导出修改接口的时候只搞这一个文件即可。而不必在整个程序范围去找,去把整个程序的SUB都导出来手工修改。
那样儿,仍然会很累。
全部0条评论
快来发表一下你的评论吧 !