首先因为工作关系好久没有发帖了，希望大家没有忘记我  觉得有用记得回帖点赞 

***********************************废话分隔符************************************

       OOP（Object Oriented Programme）编程，即大家一直说的面向对象编程。其实大家一直都在用面向对象编程，FB就是最基本的面向对象编程。当然哪些连FB都不支持的PLC就不讨论了。今天我们讨论的“继承”是OOP 编程的“进阶”功能，也是 IEC61131-3 第３版的新增内容。其实高级语言中类、继承这些概念是最基本的。但是PLC编程谈继承我也是这两年才学习到（没见过大世面，高手勿喷）。我还特意查了这个IEC61131-3 第３版 正式发布时间为2013年，现在都2021年了到底是我孤陋寡闻还是因为鸡肋功能大家都没用起来呢。  我又在论坛搜索了一下，只找到三篇相关帖子。

第一贴发布2009年绝对是前瞻性的大佬们。第二帖，水货搬运的C++的内容。 第三贴 老万的，发布于2020.7月。其中也只有老万的帖子有点干货，不亏是做标准化的嘿嘿。概括老万的帖子的意思就是鸡肋没啥用，然后回帖都是撕逼也没啥正经讨论。

       先说说概念：FB的继承，有继承关系的两个FB之间，父对象的更新会令子对象也自动更新。同时子对象可以重新编写某个方法的代码，即重构。从而使用继承，可以由一个简单的对象，派生出若干复杂的对象。老万的帖子中有这样一个观点因为PLC里面根本没有一个对象是复杂的。如果从这个观点来讲的化，PLC中的编程那都是间的对象及都是父类。没有子类当然也没有继承关系啦。

      回到我为啥会继承这个想法的，因为我碰到了一个相对复杂的对象：轴。事情的经过是这样的去年的时候我封装了一个其品牌的轴FB，方便团队内的工程师一起使用。我本着一个FB搞定所有事的原则在维护，同事提出新需求我就添加新的功能。版本一直在更新，直到今年又开了一个新项目来了新同事，他对我开玩笑的说咱这个FB块也太强大了，引脚功能都能写一本说明书了。这我才意识到我似乎跑偏了，原本封装FB就是为了使用简单，引脚多了功能多使用者看说明的时间就多了。另外为了其中一个简单的功能就是实例化这个全功能的FB确实很臃肿。其实我想解决这个问题第一反应就根据功能需求多建几个轴FB，把他们分类比如定位轴，速度轴等等。这就和老万帖子里面的尼泊尔工程师一样。刚好因为之前看过FB继承的相关介绍，我就有个想法是否使用使用FB的继承。

     我的思路是这样的把一些轴的基本功能封装成一个父类，比如里面包含 MC_Power,MC_Reset等。然后根据功能做个子类比如 PTP轴，旋转轴,步进轴等。然后再根据不同驱动添加个孙类。如：松下PTP轴。

还没开始做，先拿出来讨论一下各位谈谈是否值得用上继承，另外有用过的来谈谈里面有多少坑

      最后说一下我的观点不管什么封装方式，我的目的是使用者方便,PLC执行效率高。不是为了继承而去继承。