我一般在做一个项目的程序时会对需要的功能做抽象和封装，封装完成之后需要其功能只要调用其接口即可，这样做的好处是显而易见的，程序结构更加清晰，底层驱动或上层逻辑被隔离，底层驱动发生改动时只需更改底层驱动即可，以下是我经常用到的一个伺服封装的例子。

控制接口：

反馈接口：

功能代码：

很好的例子，层次结构清晰，封装后易于维护

愿意分享经验的就是最棒的。

这样你下次用是否能通用？

可以，直接复制过去就好，再改几个与IO相关的信号即可。

程序中使用了全局V啊。你是整个封装成库吗？用库内存吗？

200封装成库很麻烦，因为200不支持背景Db，那就意味复杂的功能着需要弄一堆引脚，不用的功能引脚还不能空，所以针对200我的封装标准就是接口明了，上下层分开即可，整个公司200的标准程序结构包括V区使用都已分配好，这个V区就是轴1用的不会用做别的，就算万一有冲突，在变量表里改几个地址还是不复杂的。

但是我的程序我的滤波库也用到了这个段的V，那么，就是说你的不能移植到我这边来。或者我要让出这片空间给你。将来你也可能某两种这个打包程序也会产生V的干涉。

假如说，谁做了一个程序包，用到了1000开始的1000个字节。然后某天他又做了另外一个功能程序包，用到了2000开始的1000个字节……某天第n个功能程序包用上了15000开始的1000个字节。之后再做一个的话V区已经没有了，必须与以前做的V区重复了。

此后，某程序需求正好遇上了要使用互相冲突的两个程序包，那么……就产生了我现在问你的这个事情了。

200封装成库很麻烦，因为200不支持背景Db，那就意味复杂的功能着需要弄一堆引脚，不用的功能引脚还不能空，所以针对200我的封装标准就是接口明了，上下层分开即可，整个公司200的标准程序结构包括V区使用都已分配好，这个V区就是轴1用的不会用做别的，就算万一有冲突，在变量表里改几个地址还是不复杂的

modbus库和运动库，算是两个比较大的库了。需要斟酌一下它的调用方法，特别是它们各自的ctrl指令。这是大型库程序需要做的。

可知道它们的数据块有很多隐性参数，用户敢改，是可以使使用发生变化的。引脚是显性调用，数据块值是隐性调用。库内存，更加是隐蔽得没有人知道，但是确实可以修改。

应该是有办法的，但是，是有点复杂。

自己公司用的标准程序也不想搞得太复杂，简单明了，结构接口清楚就行，这样下面的人也好了解好接手。

版主的想法非常好。只是如果可以的话，我想西门子公司早做了。因为在伺服指令方便性这块，西门子的与其他日系的指令上比是不如日系的方便快捷的。西门子的指令很专业，但太过死板。你这个只能说是一种较好的程序结构，和只占用局部变量的封装不是一个概念。200smart做不到真的封装。但是1200到可以试试。因为它提供了更广泛的块接口参数和底层数据交换方法。

200毕竟只是低端PLC不可能做的太强大，300 400 1200 1500支持背景DB做功能封装方便很多，所有数据都可以在背景DB中实现。

用间接寻址，对本子程序参数的隐性访问，可以代替背景DB的部分功能。每调用增加一次，隐性访问的空间自然增加一片。说不可能，是假的。说复杂，是真的。高端plc，有很多事情都由plc系统或者编程软件代劳了。代劳的工作，在某些什么系plc里面是很清晰的。能够看出，系统帮做了，需要做的事情，如果用编程的方式做，还是要大概的做回这些工作。比如，第一个子程序用到了最后是什么地址，下一个子程序接着这个地址后面用。

做了这么多年程序我自己对编程一般要求有三点要求；

第一：结构明了，逻辑清晰，注释详细；

第二：能用简单方法就用简单的方法，哪怕是简单的方法笨一点；

第三：不得万不得已不要去使用指针；

基本上满足以上三点，接手的人维护起来会很方便。

谢谢楼主的分享，值得学习。

值得学习的经验，谢谢楼主分享。

楼主的想法我很赞同，大道至简，用最简单的方法实现功能其实是最有效的。

我一直有一个向往，command.com文件我们都很清楚是什么东西的了。从来没有多少身边的人管过他是怎样工作的，有没有漏洞，有没有空间优化。接手的人根本不用管它里面的事情，用端口就是了。放哪台电脑用都可以。子程序放哪里调用都可以。我就是想把很多程序都做成这样的结构，拿来就用，什么都不用管。

就像液压设备的阀，同一个型号的装哪里都行，功能不对的换型号，接口还是那些。毫不担心有油管放不下扳手拧。

就像电脑上的一些绿色小软件，一个EXE文件，不需要安装，放哪里路径都可以，双击就用。不用担心系统兼不兼容。

在plc上，一个子程序……象万老说的，不使用T才是好程序。言下有意就是不使用公共资源，我怎么用都不用担心内存冲突。

这才是我向往的封装。

不知道大家对“封装”是一种什么样的理解？