大家有没有遇到过这样的客户，初期方案讨论时侃侃而谈，把设备的动作讲得一清二楚，但是当你按他讲的东西披星戴月的做出来后，他觉得这个要改、那个要调整，今天要增加一个步骤，明天要增加一个产品，三天两头改工艺。甚至有些人自己对具体的操作的步骤都时云里雾里的。

遇到这样的客户怎么办？如果做到只要做到客户自己能够随意改工艺路线，想让设备怎么动作就只要在触摸屏上点点就好了，岂不两全其美？所以最终方案就是做一个工艺路线的组态程序，正如下文所述。而且用这个编程方法，还有另外两个优点。其一、可以作为过程控制程序的标准模板，不再需要从头设计程序的框架结构，所有过程控制类的程序都可以直接套用这个程序结构。其二、对单个控制对象（例如一个双动作阀门、一个模拟量的液位计）所编写的程序，可以不加修改地直接用于所有其他项目中，复用率极高。当此类程序累积到一定数量后，编程时间将大为缩短，且错误极少，编程效率会达到一个令人惊叹的程度。

做这样的程序当然要用面向对象编程，分析好系统中的类和对象，最好用数组的形式建立对象，便于程序上的处理，而且可以适当的增加数组长度，以防客户将来增加硬件，到时候软件就不需要再改了。如果使用S7-1500的PLC，则可以用数组数据块，数组长度就是可变的了。除了完成每个对象固有的编程之外，还需要完成一个“工艺对象”的编程。

首先，对于每一个控制对象，列出所有的动作，通过对一个“指令”变量赋值，就能让它执行相应的动作，例如一个阀对象的指令有开阀和关阀两个，可以分别定义为“1”和“2”，再加上保持原来状态的指令，定义为“0”。对于每一个检测对象，则列出所有的状态，还是以阀为例，其状态有“全开”、“全关”、“正在开”、“正在关”、“故障”，5个状态，分别用1~5来定义。对于模拟量则需要离散化，比如要设定几个区间，或者定义一个运算过程，按运算结果来定义状态。此外，考虑到某一个检测对象的状态与某一步工艺无关，所以所有检测对象都还有一个“不相关”状态，也用”0”表示。

然后，把每个对象的状态和指令汇集成整个系统的状态集和指令集，即为所有对象的状态和指令的组合。把状态集和指令集分别定义在两张表中，并给每个状态和指令指定一个不可重复的序号。这两张表可以自动生成，优点是编程简单，缺点是可能浪费存贮空间、程序执行效率低。也可以人为逐条添加，优缺点则和自动生成正好相反。

接着还需要一个工序表，定义每一道工作步骤要进行什么样的操作，既执行哪一条指令。

最后再建立一个工艺表，定义每一道步骤执行后各种可能的状态下所对应的后序步骤，如果后序步骤为空值（实际用零表示）则表示该步骤为最后一步，所有工序执行结束。

至此，完成了一个小小数据库的设计，如图1所示。

这些表在博途中全部以UDT的数组（或数组数据块）形式建立。由于这些表都需要添加、修改和删除一条记录的操作，所以可以定义一个表的通用函数用于这些操作,用Variant数据类型作函数的输入输出接口。需要注意的是，对指令表的删除操作需要先确认工序表中是否有使用该指令的工序，如果有就不能删除该指令。否则将来执行相应工序时，就不知道要做什么了。同理，对状态表的删除操作也需要在工艺表中确认。

程序执行时，先从工序表中调入第一条工序作为当前工序，并按当前工序对应的指令序号在指令表中找出相应的指令进行操作，操作完成后，将设备的当前状态与状态表中的记录比较，找到对应的状态序号，然后用工序序号和状态序号在工艺表中找出后续工序序号，将后续工序序号赋值到当前工序，如此循环直到后续工序为空值。下图展示了程序的伪代码。

按此思路完成PLC程序和HMI的设计就万事大吉了，剩下的事就可以交给客户自己去折腾了。且慢！还漏了重要的一件事：教会客户怎么在HMI上操作??（后期就电话远程指导吧）。

有的时候一套设备可能会用于不同的产品，那么只要多建立一张产品表，把产品和该产品的首道工序联系起来就可以了，如图2所示。但是需要注意的是，即使工序的指令是一样的，但是只要是不同的产品，就应该定义不同的工序序号，除非所有后续工序和工序切换条件都是一样的。

用户改工艺的情况非常多，之前有一个滤池控制项目，由于处理效果不好，用户频繁更改工艺，陪了半年都抽不出人，最后没办法就做了跟这个类似的功能，设计了30个步骤，每个步骤干什么用户自己定义，让他们自己玩去吧。

最好让使用方把工艺流程白纸黑字写好，签好字在整！改一次让他们写一次，这样你也好跟公司领导交差！

不签字就干活呗。之前来我们公司调试的工程师，就很谨慎，任何我们的建议，都要落实到纸面上，并且要求要我们领导的签字。后来下边人觉得太麻烦领导，也不给他提意见了。

之前做一个项目罗克韦尔的项目，前面都是把工艺黑纸白纸写上的，按照原来技术协议上的工艺给你做程序，最多给你改3次。且每次你要怎么改，都得字画押，这样就不用频繁的更改了

这个事，咱客观评价一下， 应该还真赖不得客户。 

只能说，双方之前对工艺要求都不够理解， 在执行过程中才逐渐发现了问题。

这个工艺本身就不是确定的，本身就是一种柔性制造的要求。 

不同的产品，需要不同的工艺步骤。 

你设计了第一套，他要求改成第二套。然后原来的第一套错了用不着了吗？不，等他要生产第一种的产品的时候还需要改回来。

所以这种程序原本就不能做成固化的一套程序。 

是这样的吧？

 改方案，改工艺给钱啊，什么客户都是一样，呵呵

向楼主请教一下，假如工艺可以自定义

第一次为A--->B--->C--->D---E--->F

第二次为A--->----C--->---E---C---F

第三次......

应该不好实现吧

如果对工艺了解到一定程度，并设计了方案写了程序，那么对于用户提的问题，你可以像老师一样说明为什么这样，为什么不这样。除非你没到那个程度，如果用户提修改方案，那么你就，不但认真听，还要反思自己做的不够好。

1、一个是配方的主自动（配置的）程序在运行，

2、根据监控临时调整的运行程序，和主自动程序并行执行

如果出现在 监控程序里给某信号值，但和主程序里自动运行时的值（配方的值）不一样，监控是根据信号调整的值，主自动程序是配方的值，监控刚给了新值，主自动程序里这时给值（配方的值）这样就比较麻烦了。1、同步配方的值，2、不同步配方值，3、时效，

不好意思，不知道我理解的对不对

您说的=我说的   根据监控（信号）调整的运行程序（满足一个或者多个条件，才自动运作的程序）

只靠监控来处理，这样的系统是固定了对象的运行条件，按配方来调度相对简单，如果是固定的运行条件，此法思路清晰。

这个设计的意思=给一个启动信号，其他设备做相应的运行，自己的条件写在自己的FB里，

比如启动时上升沿信号，没有顶层调用，如果这中间，有延时，延时的长短需要调整的，

这样对象的运行条件会非常复杂，配方的意思=临时可以改动的流程，对象状态全部写在自己的FB里，感觉没有顶层调度来的方便

完整的程序流程

1、一个是配方的流程

2、一个是监控下的调整流程

配方的流程，按部就班的运行（工艺的要求）。

监控的流程，根据信号随时调整，作为配方流程的补充，可以在线修改（调整输入变量，修改计算公式）。

回复30楼：请参考https://www.china-journal.net/home/qikan/papershow.html?id=30549786

程序编制本应该如此，对于一些流程或者参数错误或者空参数选择性的跳过或者确认，程序的容错性和灵活性更好一些。

我自己写的程序任务结束一般会有一个函数U16 FindNextProg(U16 currentProg)，来判断下一步需要执行的操作，而不是无脑的顺序执行。

那么好了，我们把自己定义成开发编译器的人员吧。

 一定要做好完备的数据备份功能。我们的工程用这种方法后面临一个大问题是万一数据丢失几乎是灾难。因为最终的程序是好几个人共同合力的成果。如果是复杂系统的话时间一长可能大家都有点迷糊了。

那些还在说配方的人，请再仔细考虑一下吧，真的可以用配方实现这些功能吗？做个程序来看看呢，不要纸上谈兵，空口说大话呀。

抛开PLC，在其他语言中，有一种状态机，很多解决方案，和这个很相似。

确实，控制器程序其实就应该往这个方向发展

把不同的工艺写到不同的CPU，换工艺就换CPU，现在的模块式PLC，也就一插一拔，插根网线的事，就像看电影要换光盘一样，岂不美哉，客户不麻烦，你也能多赚钱 ，哈哈

只能把需要调整的参数做成可调的

别的动作只能调整程序了