发表于：2022/4/10 19:03:33
#0楼
0410 【万泉河】标准化架构下的伺服控制功能块
大约一年前， 在论坛的某个帖子下面， 菲戈同学曾问我个问题，在标准化编程烟台方法的架构中，对伺服控制的功能块应该怎么做，做几个？
即， 同样一个伺服电机型号， 有可能运行在速度模式，位置模式以及转矩模式，那么开发者在开发这类库函数的时候怎么做比较好，是作成一个兼容所有功能的大块好， 还是每个功能都分别做库，分别调用比较好？
当时我的回答是两种方式都可以。
这个回答当然没有问题，然而不够精确。
我所分享的标准化示范项目中并没有用到伺服电机，所以直接从示范项目中并不能直接得到参考， 导致很多标准化学习营的学员对这个问题，以及类似的问题比较模糊，在针对自己的非标设备标准化开发的时候，就有很多困惑。
上个月，又有学员在群中问起， 我给做了比较精确的讲解。现在把这部分讲解的内容整理成文字。以后的学员有疑问时可以参考。 当然， 网友如果能看懂，也可以有一些收获。
伺服控制器+电机的设备，在我们的标准化架构里，属于电机的一个子类。在我所著的《PLC标准化编程原理与方法》的书中，总结归纳的电机子类的类型就有上百种， 那么伺服电机对我们来说， 只不过是其中的一个普遍的品种，所以并没有对其有特别的讲解。
而且， 由于市场上的伺服控制器品牌又特别多，有脉冲控制的， 也有通信总线控制的，通信总线协议又有许多种， PROFINET , ETHERCAT, CANOPEN等等。交叉下来，需要的库函数又是一个庞大的数量。所以也根本无暇全部顾及。
所以，本文的讲述， 也只是原理性的， 不针对具体的品牌和型号。 学员们在面对自己公司和行业所采用的伺服型号， 均需要单独开发其应用库函数。然后，将来如果更换了供应商，换成了其他的品牌， 也需要继续开发对应的另外一套库函数，以备随时使用。
在烟台方法所规划控制系统的设备架构中， 有划分了L1, L2, L3, L4不同的设备层级。 我在许多场合， 视频讲座，专栏文章，公众号文章以及书中均有详细描述， 尚不清楚者各自找到相应资料理解。
这里只针对伺服对象设备重点强调其区别：
L1 是基类的对象， 对应的是原始的MOTOR库函数，它实现了基本的控制逻辑安全保护以及与HMI/SCADA的基本通讯接口。 。
L2在积累对象基础上再次封装形成的库函数，包含了增加的伺服控制器通讯接口的功能包括总线通讯和IO通讯。
L3是在L2基础上又再次封装的库函数，可以实现需要的特殊功能，即伺服的速度，位置，转矩等不同工艺。
为什么要分到这么复杂？
L1和L2是带具体物理IO的， 项目设计时， 与电气系统对接的是L2。即控制柜中安装的每一个伺服控制器，均对应了程序中的一个L2实例。
即，在组盘柜的环节，电气图纸设计者以及盘柜工人并不需要提前知晓每一个伺服电机将来的运行模式。在他们眼里都只是并排安装的一个个动力单元而已。 甚至，将来在调试过程中， 如果工艺需要， 也可以随时通过软件修改以调整每一台设备的运行模式，而不必在电气环节做出任何修改更新。
因而，每一台具体运行在其需要的工艺模式的伺服， 其实都是一个个的L3实例。
即， 在开发工程师的电脑上， 针对每一台伺服型号， 应该开发具备的库函数有：
1个L1 + 1个L2 + 3个L3 + 1个L3
即至少6个库函数。
其中L3层的库函数为3+1=4个。 即需要为每一个工艺类型都做1个， 然后再做一个全功能的，可以用于一些在运行中需要切换工艺模式的应用。
同时， 具体的项目中，对于工艺模式不变的实例，则可以任意选择， 比如可以使用全功能的L3，也可以使用单一功能的L3。
各有优缺点。
前者，节省了FB数量，节省了内存空间，然而调用逻辑复杂了。
后者，浪费一点FB数量，然而相应设备的调用逻辑会简化许多。
这取决于开发者自由选择，烟台方法从来不限制具体的实现方式。
然后， 重点的重点是，强调这些库函数在开发工程师的电脑上。 而不是一股脑儿的都下装到一个PLC中。 具体每个PLC系统，需要用到那个库函数的时候才拿出来使用，不需要的时候不要白白浪费PLC CPU的空间和资源。
菲戈问我问题的时候我为啥不能简单给个明确的回复， 原因也是在这里。 即答案有可能是完全背离的两套。
在你的电脑上和在实际项目运行的PLC上， 是不一样的。
我们做自动化设计的工程师， 一定要分清楚这一点。
我知道咱们许多同行的思维习惯， 只要一谈到标准化架构， 就特别倾向于往大而全了去想， 恨不能一个功能块里把所有的功能都包含了，甚至连未来十年有可能用到的以及永远也用不到的功能都提前做全了，冗余在PLC的CPU里， 然后调用的时候通过设置参数的不同来切换。
甚至他们会想到把管脚参数送到触摸屏，以说明书的方式指导现场的施工人员在设备调试时调整参数以实现工艺功能切换， 以实现所谓的标准化。
在我看来未免太愚蠢了点。
（一不小心又骂人了， 又要得罪人了。如果有人不幸被我击中， 情商低的人会想到被我骂了而恨我， 而情商高的人会感激我点醒了他们）
所以， 总结一点， 在做标准化库的时候， 库的存储空间是你的电脑， 千万别把PLC的存储工作区当作库的存储区。
什么叫模块化， 不是仅仅把功能打包成块叫模块化， 真正的模块化是当下使用者（PLC系统）需要使用什么功能，则给它提供什么功能的模块，多余的功能一概不给。 即最理想的状态是， 一套运行的PLC系统中， 需要的功能全具备，所有具备的功能都有用，既不欠缺， 又不冗余。
符合传说中的奥卡姆剃刀原则：如非必要， 勿增实体。
原本，这篇文章的目标读者应该仅面对标准化学员内部交流的。现在给各位学员布置作业， 分别在自己学习的PLC平台系统内， 针对自己当下用到的伺服系统做一套完整的库函数出来。 如果暂时没有用到， 那么随便借一套，开发完成，作为储备，以待将来使用。 各位完成后交给我审查。 优秀作业将安排在群中直播讲解分享。
而非学习营学员，如果看懂了，可以自己尝试实现，不需要与人分享，也无人检查督促。
而如果看不懂的，别抱怨。 首先要想到的是，自己越级提前看到了不该看到的知识。
大约一年前， 在论坛的某个帖子下面， 菲戈同学曾问我个问题，在标准化编程烟台方法的架构中，对伺服控制的功能块应该怎么做，做几个？
即， 同样一个伺服电机型号， 有可能运行在速度模式，位置模式以及转矩模式，那么开发者在开发这类库函数的时候怎么做比较好，是作成一个兼容所有功能的大块好， 还是每个功能都分别做库，分别调用比较好？
当时我的回答是两种方式都可以。
这个回答当然没有问题，然而不够精确。
我所分享的标准化示范项目中并没有用到伺服电机，所以直接从示范项目中并不能直接得到参考， 导致很多标准化学习营的学员对这个问题，以及类似的问题比较模糊，在针对自己的非标设备标准化开发的时候，就有很多困惑。
上个月，又有学员在群中问起， 我给做了比较精确的讲解。现在把这部分讲解的内容整理成文字。以后的学员有疑问时可以参考。 当然， 网友如果能看懂，也可以有一些收获。
伺服控制器+电机的设备，在我们的标准化架构里，属于电机的一个子类。在我所著的《PLC标准化编程原理与方法》的书中，总结归纳的电机子类的类型就有上百种， 那么伺服电机对我们来说， 只不过是其中的一个普遍的品种，所以并没有对其有特别的讲解。
而且， 由于市场上的伺服控制器品牌又特别多，有脉冲控制的， 也有通信总线控制的，通信总线协议又有许多种， PROFINET , ETHERCAT, CANOPEN等等。交叉下来，需要的库函数又是一个庞大的数量。所以也根本无暇全部顾及。
所以，本文的讲述， 也只是原理性的， 不针对具体的品牌和型号。 学员们在面对自己公司和行业所采用的伺服型号， 均需要单独开发其应用库函数。然后，将来如果更换了供应商，换成了其他的品牌， 也需要继续开发对应的另外一套库函数，以备随时使用。
在烟台方法所规划控制系统的设备架构中， 有划分了L1, L2, L3, L4不同的设备层级。 我在许多场合， 视频讲座，专栏文章，公众号文章以及书中均有详细描述， 尚不清楚者各自找到相应资料理解。
这里只针对伺服对象设备重点强调其区别：
L1 是基类的对象， 对应的是原始的MOTOR库函数，它实现了基本的控制逻辑安全保护以及与HMI/SCADA的基本通讯接口。 。
L2在积累对象基础上再次封装形成的库函数，包含了增加的伺服控制器通讯接口的功能包括总线通讯和IO通讯。
L3是在L2基础上又再次封装的库函数，可以实现需要的特殊功能，即伺服的速度，位置，转矩等不同工艺。
为什么要分到这么复杂？
L1和L2是带具体物理IO的， 项目设计时， 与电气系统对接的是L2。即控制柜中安装的每一个伺服控制器，均对应了程序中的一个L2实例。
即，在组盘柜的环节，电气图纸设计者以及盘柜工人并不需要提前知晓每一个伺服电机将来的运行模式。在他们眼里都只是并排安装的一个个动力单元而已。 甚至，将来在调试过程中， 如果工艺需要， 也可以随时通过软件修改以调整每一台设备的运行模式，而不必在电气环节做出任何修改更新。
因而，每一台具体运行在其需要的工艺模式的伺服， 其实都是一个个的L3实例。
即， 在开发工程师的电脑上， 针对每一台伺服型号， 应该开发具备的库函数有：
1个L1 + 1个L2 + 3个L3 + 1个L3
即至少6个库函数。
其中L3层的库函数为3+1=4个。 即需要为每一个工艺类型都做1个， 然后再做一个全功能的，可以用于一些在运行中需要切换工艺模式的应用。
同时， 具体的项目中，对于工艺模式不变的实例，则可以任意选择， 比如可以使用全功能的L3，也可以使用单一功能的L3。
各有优缺点。
前者，节省了FB数量，节省了内存空间，然而调用逻辑复杂了。
后者，浪费一点FB数量，然而相应设备的调用逻辑会简化许多。
这取决于开发者自由选择，烟台方法从来不限制具体的实现方式。
然后， 重点的重点是，强调这些库函数在开发工程师的电脑上。 而不是一股脑儿的都下装到一个PLC中。 具体每个PLC系统，需要用到那个库函数的时候才拿出来使用，不需要的时候不要白白浪费PLC CPU的空间和资源。
菲戈问我问题的时候我为啥不能简单给个明确的回复， 原因也是在这里。 即答案有可能是完全背离的两套。
在你的电脑上和在实际项目运行的PLC上， 是不一样的。
我们做自动化设计的工程师， 一定要分清楚这一点。
我知道咱们许多同行的思维习惯， 只要一谈到标准化架构， 就特别倾向于往大而全了去想， 恨不能一个功能块里把所有的功能都包含了，甚至连未来十年有可能用到的以及永远也用不到的功能都提前做全了，冗余在PLC的CPU里， 然后调用的时候通过设置参数的不同来切换。
甚至他们会想到把管脚参数送到触摸屏，以说明书的方式指导现场的施工人员在设备调试时调整参数以实现工艺功能切换， 以实现所谓的标准化。
在我看来未免太愚蠢了点。
（一不小心又骂人了， 又要得罪人了。如果有人不幸被我击中， 情商低的人会想到被我骂了而恨我， 而情商高的人会感激我点醒了他们）
所以， 总结一点， 在做标准化库的时候， 库的存储空间是你的电脑， 千万别把PLC的存储工作区当作库的存储区。
什么叫模块化， 不是仅仅把功能打包成块叫模块化， 真正的模块化是当下使用者（PLC系统）需要使用什么功能，则给它提供什么功能的模块，多余的功能一概不给。 即最理想的状态是， 一套运行的PLC系统中， 需要的功能全具备，所有具备的功能都有用，既不欠缺， 又不冗余。
符合传说中的奥卡姆剃刀原则：如非必要， 勿增实体。
原本，这篇文章的目标读者应该仅面对标准化学员内部交流的。现在给各位学员布置作业， 分别在自己学习的PLC平台系统内， 针对自己当下用到的伺服系统做一套完整的库函数出来。 如果暂时没有用到， 那么随便借一套，开发完成，作为储备，以待将来使用。 各位完成后交给我审查。 优秀作业将安排在群中直播讲解分享。
而非学习营学员，如果看懂了，可以自己尝试实现，不需要与人分享，也无人检查督促。
而如果看不懂的，别抱怨。 首先要想到的是，自己越级提前看到了不该看到的知识。
PLC标准化编程