有关FC/FB接口的描述及相关建议,西门子官方已经给出了一些具体且实用的“建议”和“规则”,详细描述参见以下官方文档:
1、ID81318674_Programming_guideline
2、ID109478084_Programming_styleguide
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
关于块接口一些常用知识点有:
1、接口参数的分类,包括Input/Output/InOut/Temp/Static(仅支持FB)/Constant;
2、接口参数的传递,包括“传值”/“传址”,与之息息相关的还有块之间“块访问模式"的匹配与兼容问题,涉及到空间和时间两个维度的开销问题,有时还需要使用"Temp"和“InOut"来助其一臂之力;
3、接口参数的性能优化措施,包括2提到的空间和时间上的开销,以及提高可读性方面的数据组织形式,而数据的重新组织又涉及到结合“PLC数据类型”的应用;
4、关于性能方面的建议,在上文中的官方文档2-ID1094788084章节10有详细阐述,在此不赘述;
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
上面所提及的内容,已经全部包含在官方手册和相关文档中,下面说一点儿日常工程实践中必须(或者偶尔)考虑的东西:
5、接口参数体量大小;
6、接口参数组织形式;
接口参数体量大小,笼统地说是由抽象结果决定的,说到抽象划分,功能在逻辑上是否相关联依赖,关联依赖度有多大?谍战片里的特工总是保持单线联系,上线只有一个,下线也只有一个。是否一些有关联的功能拼接成一个稍大的功能?抽象,是否真的抽出了必需的重点细节?是否又抽出了不必需的细节?抽象搞不好,它会抽风!接口要简洁,什么叫做“简洁”呢?个人理解就是能满足功能所必需的最小合集,加一分则太过,减一分则不足。
参数是采用“一揽子”的形式,还是采用把鸡蛋分放在几个篮子里的形式?数据的组织形式才是编程的根本,这句话真的需要好好品味。如果可以,尽量采用“PLC数据类型”的InOut参数。 ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
上面就是对理解和应用块接口的一点小理解,水平有限,有不足或者错误之处,还请方家指正指教。