为什么在plc 里头要用fb块,感觉系统学习这事儿就像跑马拉松

为啥在PLC里头要用FB块,感觉系统学习这事儿就像跑马拉松,偶尔歇会儿才更有劲。上回我们说了,现在工业4.0推得这么快,控制系统复杂得不行,老一套的面向过程编程根本扛不住现在的那种高要求。现在工业控制软件正处在一个大变化里。这一期咱就把FB的好,从内存管理到状态机再到大项目架构,好好掰扯掰扯,看它怎么把代码安全、维护方便还有执行快这三个方面给我们的系统加分。 按照IEC 61131-3标准来琢磨,功能块FB和功能FC可是完全不一样的两个东西,差别就在内存管理这块儿。咱们要是弄了个FB调用,CPU就会专门给它分个数据块用。每个变量在那个实例DB里头都有个固定的位置:那种布尔值就占个位子,整型数就占个字。这种定死了的分配方式,保证了咱们读取数据的时候准成,这对实时控制太重要了。 整个扫描周期下来,FB干活儿的路子很死:一开始它会从DB里把所有叫STAT的变量值读进工作寄存器;然后拿着这些值去算、去判断状态;算完之后又把更新后的数值写回原来的DB地址。这就保证了状态能跨个周期接着用,也免得变量被人不小心改坏了。 那种叫PrevSignal的变量就像是FB的独门秘籍。以前要想检测个边沿信号得靠全局变量记上一周期的状态,现在FB直接在自己肚子里弄个静态变量PrevSignal就行了。至于FC嘛,这就不怎么占用资源了。 用封装的办法搭了一道墙,基本上把以前用全局变量会带来的坏毛病给治好了。咱们输入个开关量去启动个FB块就行,里头的所有变量都不需要占用你PLC的真实地址,这就能省下不少M点和D点的资源。数据隔离不光是平时好使,遇到故障的时候更能看出好处。如果有个FB实例出问题乱套了,那混乱的数据也只能闷在自己这一个例子里头,不会殃及其他同类的例子。 这种不怕出事的机制保证了一点小毛病不会让整个系统垮掉。就像我之前给大家讲的那个电机控制FB小例子那样,写好一次逻辑就能去管100或者上千台电机。 不过写FB也有得注意的地方。遇到特别大的项目的时候,FB的优势就得往架构层面去想了。分层分布的架构加上多层背景数据块是现在的普遍做法。一般都有四层:最底层L1负责定义电机、阀门、传感器这些物理设备的FB;中间层L2把几个设备拼起来做成工位的控制;L3负责协调好几个工位一起干活;最顶层L4管的是生产计划和跟MES系统打交道。 这一套架构里头呢,上层的FB是通过套着下层的FB来完成复杂功能的。每个FB都有清晰的接口和职责划分,大家可以并行开发也能独立测试。像下面这个例子就是这么个嵌套法: FB_Application(应用层) ├── FB_ProductionControl(生产控制) │ ├── FB_Line1(生产线1) │ │ ├── FB_Station1(工位1) │ │ │ ├── FB_Motor(电机) │ │ │ └── FB_Sensor(传感器) │ └── FB_SafetySystem(安全系统) 咱们要是把FB给用好就能解决不少问题。没事的时候把代码写好放在库里要用的时候调一下不用的时候就放着就行。其实功能块技术不仅仅是个写代码的工具了它标志着工业控制软件正在从单纯写代码变成做系统设计的大转变关键的地方就在于搞懂封装和组合这两点。有了封装咱们能管住复杂程度靠组合咱们又能让规模变大抓住了这两点工程师就能弄出一套真正符合工厂设计的控制架构这东西不光能满足现在的需要还能对付未来十年的技术变化呢。