PLC编程再思考之一:MapReduce

大家知道MapReduce是奠定GOOGLE成功基础的三大技术法宝之一(另外两个是PageRank和BigTable),现在MapReduce方法论已经在网络开发甚至在企业开发中得到广泛的应用,而本文则探讨MapReduce在MES PLC编程中的应用。

目前PLC和自动化技术在MES的应用中非常关键,通过对PLC的集成,MES得以打通执行层、控制层、设备层,在一些汽车制造公司,甚至专门搭建IT PLC或MASTER PLC,以实现PMC、ANDON、AVI、EPS等高度复杂的业务模块,以及数以千计的外部设备(拉绳/按钮/灯)的集成。

因此,对于MES业务而言,IT PLC的重点不是过程控制,而是复杂业务逻辑的处理,以及大量I/O设备的读写。

由于上述原因,IT PLC内部运行的FB/FC就会非常多,如果不认真规划的话,OB1里调用关系就会非常混乱,因而需要对程序的结构进行严谨的设计。

本文试以ANDON为例,说明MapReduce在PLC编程上的借鉴。

首先是Map。

Map应体现在两个方面,一是程序结构。

如下图体现了非常清晰的调用关系,在OB1中只需要做一些业务模块的声明:

第二个方面是配置关系的定义,如线和工位的对应关系,工位和拉绳/灯的对应关系。

如下图所示,可以用数组建立线和工位的对应关系,然后把拉绳和灯的编号作为工位属性配置:

因而我们可以用遍历数组的方式得到线对应的所有工位,然后根据工位属性得到对应的拉绳编号和灯编号。

再来看Reduce。

从FC40000 ANDON主FC以下,我们又看到了以下几类业务处理过程:

- 对于线的处理

- 对于工位的处理

- 对于拉绳的处理

- 对于灯的处理

我们可以分别编写4个FC来进行相应的处理。

- FC40100处理线的逻辑,包含两个变量:线编号和工位数量。

- FC40101处理工位的逻辑,包含变量:工位编号。

- FC40111处理拉绳的逻辑,包含变量:拉绳编号和拉绳状态。

- FC40121处理灯的逻辑,包含变量:灯编号。

经由以上处理,我们就得到了一个非常简洁的调用结构:

具体过程为:

- FC40000依次调用各条线FC40100。

- FC40100调用本线对应所有工位的FC40101。

- FC40101调用工位对应拉绳的FC40111。

- FC40101根据拉强绳返回的状态值FLAG,决定是否调用灯的FC40121。

总结一下,本文中用MapReduce处理PLC程序结构的要点:

- OB1/FC的结构要清晰、有层次。

- 业务模型通过DB中的数组等结构体现关系。

- 业务过程FC要参数化、可重用。

时间: 2024-08-15 09:10:59

PLC编程再思考之一:MapReduce的相关文章

PLC编程再思考之二:SOA

随着AMAZON云服务的成功,许多人知道了BEZOS在AMAZON内部推广WEB SERVICE的故事,从而佩服他的技术眼光和执行力. 如果说AMAZON.COM的成功是因为长尾理论,是对万货商店的技术实现,那么从某个层面来说,AWS(AMAZON WEB SERVICE)是另一种形式的长尾,只不过它销售的是IT服务而不是物理产品. BEZOS基于SOA的思想,通过网络接口和服务打通了AMAZON内部的各种子系统,他把基础设施的接口进一步对外开放,从而形成了AWS的基础功能. 那么,SOA的思想

PLC编程再思考之三:面向过程

现在的高级语言基本上都是面向对象的,但是PLC编程象较早的BASIC/FORTRAN语言一样,是面向过程的. PLC逻辑处理的基本过程为: 1) 将外部设备输入的数据写入输入映像区(I). 2) 逻辑处理,包括读I区.写Q区. 3) 将输出映像区(Q)的数据输出到外部设备. 其中,1)和3)是PLC内部处理的,所有的PLC用户程序只处理第2)部分. PLC的这种处理方式带来了下面2个特点. 特点1:OB1调用的程序不存在并发 我们知道,PLC用户程序主要运行在2个地方:中断和OB1. 一般而言,

PLC编程再思考之4 - 面向对象

PLC编程有诸多限制,如: 传统的西门子PLC单个DB的存储容量为64KB. 每次DB结构变更时,都需要编译并重新下载覆盖原DB. 每次DB结构变更时,OPC变量需要重新映射地址. 但有时候我们希望把DB设计得灵活一些,当给PLC增加一些小的元素时,我们不希望覆盖大量的DB. 有时我们希望PLC程序设计得模块化.产品化.基于配置. 在这些应用场景中,我们可以参考面向对象的方法进行PLC编程. 本文以质量安灯实例说明了面向对象的PLC编程方法. 业务需求为: 每个工位配置1条拉绳. 当拉绳拉下时,

C++ Primer 学习笔记_73_面向对象编程 --再谈文本查询示例

面向对象编程 --再谈文本查询示例 引言: 扩展第10.6节的文本查询应用程序,使我们的系统可以支持更复杂的查询. 为了说明问题,将用下面的简单小说来运行查询: Alice Emma has long flowing red hair. Her Daddy says when the wind blows through her hair, it looks almost alive, like a fiery bird in flight. A beautiful fiery bird, he

C++ Primer 学习笔记_74_面向对象编程 --再谈文本查询示例[续/习题]

面向对象编程 --再谈文本查询示例[续/习题] //P522 习题15.41 //1 in TextQuery.h #ifndef TEXTQUERY_H_INCLUDED #define TEXTQUERY_H_INCLUDED #include <iostream> #include <fstream> #include <sstream> #include <vector> #include <set> #include <map&g

关于网页脚本代码结构的再思考

在很多说法中,总是建议将我们的javascript脚本加载在网页的最后,并用外部文件的形式,然而事实并不是这样,外挂的文件最好不要太多,脚本结构代码本身才是值得我们思考的问题.我们需要重新思考我们撰写的脚本的执行力,并把更优秀的javascript开发思路融入到我们的开发中. 我在读完了几篇关于javascript和jQuery的性能优化的文章之后,才恍然大悟,我以前所做的很多代码结构优化,最终只是让乌徒帮显得臃肿,于是重新设计脚本代码的结构,无论怎么样,乌徒帮现在的网页打开显得更加流畅了. 1

机房收费重构——关于上下机的再思考

有句话叫做no zuo no die,我大概就是这种人吧.why?做机房收费系统的时候,按照一般方法也能实现,但这次做上下机的时候,总感觉这么做对自己来说,没什么提高,然后就停下来,重新想想上下机还能怎么做? 后来,大致采用的思路是这样的:将上下机的读写数据的过程写成两个存储过程,负责读取和更改数据.中间的计算过程写在代码里面:中间判断时间的过程用职责链模式来实现,判断一般用户还是临时用户用策略模式实现.这样,整个上下机的过程就是这样的: 1,用上机的存储过程使学生上机,然后将学生上机信息写入表

C++ Primer 学习笔记_73_面向对象编程 -再谈文本查询示范

面向对象编程 --再谈文本查询示例 引言: 扩展第10.6节的文本查询应用程序,使我们的系统可以支持更复杂的查询. 为了说明问题,将用下面的简单小说来运行查询: Alice Emma has long flowing red hair. Her Daddy says when the wind blows through her hair, it looks almost alive, like a fiery bird in flight. A beautiful fiery bird, he

C++ Primer 学习笔记_74_面向对象编程 -再谈文本查询示范[续/习题]

面向对象编程 --再谈文本查询示例[续/习题] //P522 习题15.41 //1 in TextQuery.h #ifndef TEXTQUERY_H_INCLUDED #define TEXTQUERY_H_INCLUDED #include <iostream> #include <fstream> #include <sstream> #include <vector> #include <set> #include <map&g