说实话， 我还从来没有见过另外一个行业的工程师，如本行业一样，动辄对同行的作品彻底否定。

见过了太多的PLC编程工程师，公开声明自己的原则：不愿意读别人的程序， 不爱修改别人的程序，情愿另起炉灶自己从头编写程序。

理由就是：别人的程序， 烂。

至于原因么， 很简单， 别人的编程水平不行，就我的最好。

包括我自己。

我自己记忆最清晰的是两次现场救援，系统原本的程序烂掉了， 跑不起来，原来的程序员干不下去了， 撂挑子不管了， 我来接了烂摊子。 因为摊子本来就烂， 所以不得已，毁掉了原来的所有程序， 只保留了符号表， 所有程序从头做的。

除此之外， 只要系统原本是能运行的，无非有缺陷， 总出事情， 那也尽量在其原本基础上读懂， 修改。找到问题， 解决问题。 别人的程序再烂， 我想也总有一些可以参考学习的闪光点。

不过也确实有些程序烂到实在不像话。 读那种程序， 实在是要忍着恶心的。有那么几年， 我一边读这种程序， 心里一边暗暗排名，哪个是我见过的第一烂的程序， 哪个是第二烂。 也曾经长时间的在硬盘上保留着，仅仅是为了作为比烂的样本。打算谁要发起比烂大赛， 拿出来参加的。

但我也实在明白得很，这种专业技术人员之间互相倾轧的心态是要不得的， 是自古以来的文人相轻的陋习的传承。 我还没有不要脸到只要别人的程序都烂， 只有我的程序最好， 最完美最合理最优雅最简洁。

所以， 这里面一定有一个客观衡量的标准。

这些年， 我一直在寻找， 在思考。

首先，要找到最合理， 最理想的程序范本。

最终我认为， 是PCS7 。 使用PCS7高级工具生成的程序， 最终落到S7-400的PLC中，其本质上还是PLC程序。  尽管其代码规模大，不够精简，运行效率低，但是从编程的规范来说， 它一定是最合理的。

其次， 是从中提炼出其可度量的好的标准。

好的程序， 一定是模块化的，面向对象的， 层次分明的。 PCS7显然是依循这一点做的。但还不足以作为考量程序好坏的标准。

我最终总结，认为，好的程序的标准是：不使用M中间量，不使用Timer。

我不希望有人给我耍滑头， 耍脑筋急转弯。说， 不让用M量，可以啊， 那我用全局数据块， 建立数据， 一样可以。 也用DB块自己脉冲计数， 也可以绕过不使用TIMER。

那性质是一样的， 特征都是：全局变量。

如果学过高级编程语言， 就会知道， 高级语言里面最基本的原则就是少用全局公用变量。 尤其禁止在函数块与函数块内部使用PUBLIC变量来交互数据。

放到PLC环境， 其实说的就是M和T。

我自己以前做程序， 程序块基本上靠M和T做出来的。为了清晰，便于传承， 给每个FC块严格分配了可以使用的M区和T区域。

现在看来， 都是属于落后的编程思想。也害了不少跟在我后面学习的徒弟。 惭愧。

那么如何避免使用M量和T呢？答案是大量使用FB， 每一个设备，单元类型，均提炼做成类库，需要的存储区使用FB块内部的静态变量，而定时器则使用SFB的定时器， 背景数据来自FB的多重静态数据。

那么是否可以完全做到呢？PCS7显然是可以做到。 而我自己做过的程序， 也有做到过没有使用1个M和1个T的。 CPU中指定的系统变量不算。

偶尔也有偷懒， 不够追求满分。 特别是调试到后期， 一些小的细节的功能， 顺便就用M量简单实现了。那怎么办呢？内心给自己的程序打个分扣上5分就可以了！

当你掌握了客观评价标准，都能给自己扣分了，那么就可以理直气壮地评价别人的程序了。 比如你如果见到我10年前的某个程序， 规定了多少M区不许使用，就可以尖锐地指出：烂！

我不想看别人的程序就一个字“烦”，自以为一个简单的控制给别人做起来，东扯一段程序，西扯一段程序，没有连贯性。但当自己编辑起来也一样了，在调试时出现的问题也不是先随便插入程序段或者删除的。

总之，一句话，对程序架构的熟悉程度。

记得刚刚开始看西门子数控程序时，也非常的“烦”，原因是不熟悉数控系统的关联，慢慢的边学边做，现在已经习惯了。

真如N多人说，某一个plc好用和不好用，实际上就是对软件的熟悉不熟悉而已。

看来我与好的程序差距甚远，M变量倒是用，但不是很多，基本中间过程用数据块DB，time用的比较少。

绝大多数项目都是按照编程工程师的个人习惯来组态的，没有统一的模板、规范。
这种情况下，去看别人的程序不是一般的难懂，并不是同行相轻，当然不排除一部分同行确实自我感觉良好的

在一些大型企业，程序都是有模板、块都是标准化的，程序结构都是固定的，现场工程师要做的只是调试参数……程序和现场工程师没啥关系～

而多数小型工控公司，走个自控工程师，剩下的人维护他做的项目都傻眼～

POP，OOP距离还远了

不太懂西门子，更不懂pcs7，但是对万版这个观点深以为然，因为咱有对比参照，哈哈哈。

窃以为，读程序读的是控制模型，控制方法，读出这些才能谈得上改善改进移植修改等等。最近几年接触软plc，习惯了用长长长长的名字做符号（老万另一篇帖子写定义符号的也很有意思），而且不关心地址，只需要有变量类型就行了。读程序思路非常连贯。

------写不出区别，但作为对比的是最近一次用1200plc，尽管是SCL符号编程，但还是感觉受限制地方太多太多。

-----还是举个栗子吧，没有DB 没有背景 有M区但很少有人用，你只管定义了一个叫start的变量，不必知道这个变量存在内存的哪个地址。甚至想知道这个地址或大型变量的地址和长度得用查询指令。是不是很美？

----至于楼上说的触摸屏问题。解决方案首选支持符号的触摸屏（西门子的不行），导入项目后会见到start这个变量。最不济的办法是指定个全局变量给start，如M1.0 ，当然这是下下策了，很烦。

还是不要这样说吧，个人认为，这种贴还是挺好的，至少让从事编程的人自省一下。

     做自控维护出身，就是看别人程序，看过太多人的程序，每次读别人程序，都是以拜读的心态读，等理解了再做一些修改。虽然编程人水平参差不齐，但是每次或多或少都有点收获，可能是我水平不高的原因吧！

      说实话“好的程序的标准是：不使用M中间量，不使用Timer。”让我感觉挺震撼的！希望读到高手的程序，多提高一下自己。不找借口，靠自已研究的提高感觉很有限。@万泉河 如果大师有例程分享就好了。

如果你的标准仅仅是注释的话, 那同样都有注释的程序如何比较呢?都好， 都一样的好？

或者, 没有源程序, 直接从PLC中上传来的程序，都没了注释， 在你眼里又成了都一样的烂啦？

你这标准简直太搞笑了好不好。 

我赞成楼主的观点。所有程序都一样的。读高级语言编程，不一定要精通，但是可以学习高级语言的编程思想，特别是互联网框架会有更多借鉴的地方，读完后会自然而然把高级语言的思想运用到PLC中虽然有部分功能在PLC中是实现不了的。读完高级语言编程后可以提升自己的编程水平，还有编程的时候多换位思考，有助于把程序变得通俗易懂。

嗯嗯。

我对M区还是有别的看法的。为什么S7 1200/1500仍然保留着M区？

这是与PLC的硬件结构有关系的。

自从学习使用单片机、PLC就记住了这一点。这个区，本质上应该叫做 布尔逻辑运算器存储区。它属于CU处理器周边的存储区，不需要CU去寻址操作（相当是通过地址总线的外存操作）。而且使用专门针对它们的逻辑处理器，尤其是位操作。其特点就是逻辑处理速度特别快。

我觉得：应该是正确地使用 M区，而不是不用。

我猜，像LOGO这类的微型逻辑处理器，就是系统的逻辑运算功能块，占用了所有M区，用户只能使用V区吧。

而我们的PC机的CPU就不是这种结构。CPU周边只有少量的寄存器和大量的缓存器。数据都是靠地址总线寻址，通过数据总线操作来对RAM读写。所以，普通的PC机，它不适合做软PLC.

是这样吧？

说点自己不务正业看闲书的收获，计算机科学界有条著名的“中间层定律”，具体内容在这里就不解释了，感兴趣的可以自行度娘一下。

使用中间层的原因，首先就是简化结构，使系统架构清晰，逻辑上保证强聚合，低耦合，使程序拥有足够的健壮性去对付随时出现的“变化”。

理性地看，M区DB块，都是这种中间层的某种外显形式，是一种桥梁性的东西，在使用上无非就是隔离实际输入与实际输出在控制逻辑上的直接性联系，保持一定的灵活性来应对未知的变化，简而言之就是，你写的程序要支持变化，这是其本质。

再说说有时看不习惯别人代码的问题，这是种很普遍的现象，不唯独写PLC程序的，IT界的“程序猿”们在这个问题上也是“天下苦秦久矣”，看别人代码维护别人的遗留代码时，闷骚的“猿猿们”是不是也会“WTF”（what the ****）不绝于口，翻译成国语就是“次奥，什么垃圾玩意儿啊！”，有时是别人的代码，有时还会是某年某月某日某时自己写的代码，这就看到了代码中必要注释的重要性。

随着计算机知识对工控渗透影响的日益增长，计算机科学和计算机语言的成型的指导方针和优秀的系统设计理念，外加一些浓缩的定律，完全可以借鉴到PLC编码上来。

一些优秀的出版物针对某一话题进行了深入广泛的论述，都是经过无数人验证过的精华，举几个例子，《编写易读代码的艺术》《代码整洁之道》《从小工到专家》《重构》，比较重磅的有《代码大全》《编程珠玑》等。

在阅读一些作者大牛的个人介绍时经常会发现他们的教育背景基本都是电气自动化+计算机专业的双料模式，起初十分不解，后来才慢慢明白，就应该是这样的教育经历，如果不是这样的话，反倒奇怪了，此时的的计算机专业恰似提炼特种钢材时加入的“催化剂”一样，让自动化有了神奇的变化。从根源上说，现在的自动化与计算机科学实在是一奶同胞，只不过侧重点不一样罢了。

孟子（补记：弄错了，是庄子先生说的）说“夏虫莫语冰”，有容纳的空间和接受的意愿，才能换汤又换药。坛里某知名大牛说，PLC编程就是固定套路，泡论坛也不是三天两日了，可时至今日，翻遍此大咖的帖子和回复，还真没见过多少系统的“套路”，也从未见过大牛所谓的套路在哪儿，也许这就是“大咖”的大咖之处，谢谢老万的分享。

最后，任何本质上大的进步和提升都是自主内发性的，靠别人也从来都是没有出路的。引用电影《鼠胆龙威》里的医生说的一句话作为结束语吧

------“做人，要靠自己。”

以前有个热帖谈起过，注重代码编写效率要优于代码执行效率。

从这个角度看，M区位操作速度快是个微弱微弱的优势。哈哈

先说个从前的事儿。

如果住过日本大学院宿舍，会发现一个事儿：宿舍的卫生间并不是瓷砖装修的，而是整体的。似乎是个预装整体的。好用不说，连维护空间都预先想好了。

不同的楼，有所不同（档次有差别），但同一楼则是一样的。

不同的楼，有不同的风格；但一栋楼内外，风格是一样的。

这就像楼主说的，写一个好的PLC程序，应该就像设计一个建筑。它内部需要有不同的功能。自然，模块化的预装件是最有效率的。这就是专用的功能块。如果这些预装件是经过多种考核、完善的，那当然好用了。

（达到好用的过程，肯定不是一次就行的。）

在这个整体预装件中，又有不同的功能（梳洗的、泡澡的等等）。但至少你要分类吧？总不能一个建筑内部各种功能都有，但把马桶放在餐桌旁边吧？所以该封装的，就应该封装，（内部是国产的、还是进口的；是这家产的，还是那家产的，不重要，）尽量做到外观一致。这就是能让人“入眼”！

当这类整体预装件，通过了实用考核。自然就会成为产品，列入设计库中了。

——写程序，也一样。

最后，就是整体建筑。建筑的整体框架设计，是为了实现整体的应用功能。整体框架设计之初有问题，即便内部都是预装件，也完蛋。这就是说，设计之初程序框架的重要性。

所以，当初学习三菱PLC时，告诉你的第一件事儿，就是关上电脑，拿出笔和纸。。。。

日常工作中我也不喜欢去读别人的程序，具体原因有二：一是不喜欢去揣摩别人的思维逻辑；二是感觉别人写程序时堆砌感特别严重。现在我在做程序时大部分采用scl来做，除关键变量外也基本不会使用全局变量，编程比较洒脱，移植性也相当好。

算。 

其中的INPUT和OUTPUT，是作为接口存在的，可以全局使用。

 而其中的静态变量，系统的开放性会支持外部访问， 但属于偷，不规范。用一次，扣10分。

个人认为什么M T DB都可以使用，关键还是变量区规划的问题，大家水平不一，能力也不一样，所以规划做的有好有坏，编程思想也不尽相同，造成彼此之间理解起来费时费力。

使用PLC的人员背景很多很杂，从高中学历到博士学历，机械专业、电气专业、计算机专业，等等，有的是专门付费学的，有的是自学成才，正规军、杂牌军、各种野路子的，百花齐放。这也是大多数别人的PLC程序读起来令人烦恼的原因。

不同人员编程思想不尽相同，毕竟大家不是从一个地方学的编程，各人知识水平也不同，难以做到统一，同时这个行当还没有一个普遍公认又被大家熟知的标准，这些都是造成读别人程序给自己带来困扰的原因。

抱怨改变不了现实，认清现实，调整好心态。别人的程序好的就借鉴，烂的就摒弃，不断提高自己。

至于接手别人烂摊子的事，完全是个人选择的问题，不想接就别接，找各种理由都可以推脱掉，实在推不掉，就硬着头皮做下去，尽力做到自己的水平，问心无愧就行了。

版主的“技术洁癖”是每个做工控程序的人该学习的，追求更好，追求上进，从小说对个人技术水平提高有意义，往大说对整个工控行业环境也有积极的作用。支持！

现在很多软PLC的性能比真PLC更强大，M应该只是为了照顾传统习惯而定义出来的一种存储（或者寻址）结构。我编程基本上不用M，但有时需要很快的解决问题（比如高炉上处理紧急事件），俺直接用M，这样不需要定义了。

关于全局变量，个人认为应该根据需要，如果是那种临时性的占用，最好就不要用全局变量了，浪费内存；但...，现在的PLC的内存已经远远超出原来PLC的内存的概念了，比如：1200/1500好像是可以连注释都保存到PLC里面的吧？

本胖眼里的好程序：

1、完全满足工艺算法的需要。

2、自己能很快的看懂，哪怕过上几年再看。

3、别人是否能看懂，根本不用去管。

4、注释，俺还是比较强调这个的。否则，过几年，可能自己连当时的工艺或者算法都不记得了。

5、那些程序的结构、全局/局部变量等等，都是细节问题，适当重视就行了。

6、FB比FC好，尽量把FB做成“零件”，可以重复使用。

OVER。原来还以为老万对PLC程序不咋精通呢，没想到原来是深藏不露。

编程也分境界的，应该也是没有最好只有更好才对。

任何技术也是不断完善提高的。

身处不同阶段，当然体悟不同，谁都年轻过，可以分享经验，这便是“先驱”的优势。可不要怕被后浪拍在沙滩上哦。

关于“注释”的问题。并不是楼主要表达的意思，那是是编好程序的两个方面。

还是用个场景说明：

外出入住House，管理员会带你到各房间，厨房、盥洗室、卫生间看一下。同样，恐怕大多家里的厨房、厕所门口也不会贴一个牌子（注释一下）。为什么？因为功能分类了。即便没“注释”，外人一看就大体了解了。

但这并不代表内部具体器件的功能，你就了解。（例如：一般水龙头你会用；初次接触恒温水龙头，你就不一定会用。）这就需要“注释”说明，至少有人要告诉你正确的使用方法。（高压锅没放气就开盖，也听说过不少。嘿嘿。）

但是，一个社区的公共设施或规模大的家庭，就需要“注释”；（我一个国外亲戚家，厕所就标上有 Gents、Ladies）甚至还要标好“指引注释”，才好。

所以，楼主的意思是：好程序要有框架，分层、分类、做好通用模块化；并不是功能块的堆砌。

这样做，即便 “注释”丢了。人家也能看明白个“大概其”。

是吧？

 如果公司或企业有了自己的标准就可以解决这个问题。程序的可读性、可复用性说小了是工程师的素养，说大了是企业管理跟不上。

程序是用于现场的，不是给人观赏的。

程序不但要满足现场基本要求，而且现场可能出现的各种情况都要考虑到。

一套程序可能需要在n套设备中运行n长时间，才能发现各种没考虑到的问题，再完善，最后就是完美的程序。

没有那个神仙能一次把一个系统一次做完美。

好，给个精华吧！版主不能老是给自己加精华吧！

M区在300内还是有一个特殊运用就是时钟脉冲，一般都是默认MB0的，在FB，FC内尽量不使用全局变量，这样做的FB,FC多次调用就不会出错，移植性比较好。T在赋实参时使用还是比较方便的。

M的好处就是不需要定义情况下可以直接方便使用，如MW0可以是一个字也可以是一个整数。

西门子还是要允许不求上进的家伙编烂程序的。 

在同样可读性强， 简洁， 无漏洞的情况下，不同的程序之间能否再分好坏高下呢？

PCS7在FB方面的主要是思想是以组件中的一部分而存在，不仅仅是底层PLC代码还有上位机的可视化对象包含图标和控制面板。

我是从入行起就直接使用PCS7，我到现在都不使用SIMATIC的计时器，而且是不知道怎么用，也没使用过M区来编程，最多就是用MB1什么的来做始终脉冲或者常0，1逻辑。

楼主有兴趣的话 我可以发点APL的SCL源代码给你

这么多年，符合这三条的程序不多。少数的几个都是珍品了。

如果非要在珍品中分出高下，那就像区分鱼跟熊掌一样了：看你好哪口。

比如有的人好FB，把所有相同逻辑功能封装在一个FB中，然后直接调用。这对编程是省事了，但是对维护者分析故障来说却是问题了。

我看过一个公司的程序，一个现场20台轧机，就一个FB调用20次。对设计者来讲省事极了，也显的高大上，但是维护者想监控个程序找出问题点来可就麻烦了。再加上这个FB本身就不完善，那就是恶梦。

所以，如果非要在珍品中分高低，那就得看裁判是谁。偏爱STL的与偏爱SCL的与偏爱LAD的给出的答案肯定不同。

还有，我极其反对有的人的所谓的'程序自己能看懂就行，不管别人”的观点。除非你的程序不需要别人维护，出了问题可以不看程序也知道问题在哪，同时别人想增加点新功能也不需要看你的程序就直接增加。否则，放下你的傲骄，老老实实的让别的能看懂你的程序才是根本。

工控程序，毕竟不是黑客工具，易用易看稳定才是王道。

否则，就24小时接电话吧。

你一个做工业行业的， 做的产品不追求工业化？

曾经跟做过奔驰项目的工程师聊过。奔驰的项目特别不好做，特别费时、费力，弄不好就要返工且没商量。难在哪？不是控制本身难，是理解和正确使用奔驰的企业标准难。奔驰的控制程序不是你想怎么编就怎么编的，你一个程序管脚的命名也要按照标准去做，否则无法继续下去；你的一个控制功能首先要去企业库中查找，已有的就必须要引用，它世界各地都要严格按标准，这样的结果就保证了它的各种信息的一致性，功能的准确性。而这些还仅仅是一个基本原则。

这种思路是我们可以借鉴的。

楼主既然要谈“好和坏”是否应先确定一个先决条件或划定一个范围，这样对大家或许更有参考意义。

我建议你啊， 先提高自己的维度， 能看懂别人在说什么。 

或者证明你自己的水平，整点有水平的内容出来， 让人信服。 

至少，能让西门子的工程师们信服你。 

我自己么， 到望京西门子大院， 认识我的工程师不在少数。 

我有这个自知之明。 

博途可以将梯形图封装成FB/FC后再结合库处理，这样用户就完全摆脱了“功能/功能块”内部复杂的实现，再给块的实例取个包含关键信息的好名字（如工步名称）。

其实学习plc其实就是从入门到熟练的过程，经验从无到有再到经验丰富，所以就会有编写的烂程序和好的程序，知识是一点一点积累出来的，关键是要不断的学习和改变自己。

明摆着1200/1500与原来的PLC完全不同！

从前的CU处理器是单核的。它都是扫描端口-IO映像区 - 处理循环 - 输出映像区 - 处理通讯及其他（任意位置插入中断）。从头再循环。速度的提高靠的是主频和硬件。

PC机586以后就多核了。就有多线程了。然后才有不用提高主频下，有更高的任务处理速度。PLC一直没啥发展。在外界PC人的眼里，PLC（硬件方面）特LOW。

1200/1500推出来时，就说过，它的通讯处理是与程序扫描处理是并行的，是时间片的！明摆着要向多核方向发展，来极大地提高速度。

你们那些用指针的，硬件上就要用CU的外存储器地址寄存器。对于多核的来说，都有任务队列缓存。遇到这种，还得当前压栈去处理。你说他能推荐原来的方法么？

你们编程的也得适应硬件的变化吧？

要不咱们干脆退到DOS去吧？单CPU、单进程，没线程。敲代码、写程序。

其实，楼主说当年的“烂”，其实，并不烂。适合当年的PLC！只不过现在是“与时俱进”了。

1200/1500保留 M区，一定是保留了专门的逻辑运算处理单元。

所以，该用到的，还是要用它。利用它的特点。

第一次遇到一个人用scl在fx3u上编写一个设备的程序。程序容量是13K（此时尚未结束工程，内容仍在增加），扫描周期14毫秒。这个设备我做过极其类似的程序，梯形图做的。程序容量是1K，扫描时间是2毫秒多，偶尔出现3字。从设备的动作反应看来，已经觉察到了这个14毫秒带来的动作区别。

他说这个程序很多地方使用了通用性很强的代码，一搬过来就可以了。

不知道这两个程序有没有可比性呢？

我觉得，不用看程序了，算了吧。 客户的电气主管三翻四次请求我换回我的程序……因为另外一台机是我的程序正常使用了三年。觉得比较靠谱。

这又映射了一个什么问题？软件的错？硬件的错？编程者的错？好坏的标准的错？

在一个有200个FB FC的程序，想必不会是你一个人做的吧？你在使用别人的程序的时候，有去看别人的程序吗？很容易理解，我用了S7 200plc的modbus库7年了，没发现他给我带来了什么麻烦，我也没看过他一眼。即使是大家都有办法打开他看看，我也没看过。各位也使用了command.com这个文件30年了吧。谁反译过它看过？

是不是很明显？

你叫我做一个功能块，我做到了，你就别管我怎么写。我老板也看不明我的图纸程序，不也一样承认我的工作？有什么必要要读？

最后我表明一个态度，好程序完全没必要有可读性。

敢于突出重围，发出这样的观点， 比我都勇敢！

必须赞。 

其实可读性根本没办法作为一个可以量化的客观标准。 你写出来的注释打算给谁看？给一年级的看还是给5年纪的看？给中专生看还是给大学毕业生看？

谁要是敢吹牛逼自己的程序最具可读性， 拿给我看看， 我来呲一呲。

PCS7不使用M和T的主要原因是APL库包含的电机阀门PID模拟量监视等这些FB都需要重复调用几百次，如果用Timer很快计时器资源就会枯竭，而且还要组态Timer的编号，效率太低了。你也可以用你的高级方法来使一个计时器完成所有的计时功能，但是绝对是得不偿失的，程序的风险难以把控。PCS7实现计时的方法实际依靠的是中断，程序几乎都运行在OB30~38之间，这些OB都是固定时长执行一次。

L Timing1

L 0.1

+R

T Timing1

简简单单的几行就开始计时了，每周期加0.1。

M区又叫位存储区，而实际上它提供的作用全局DB可以做到，背景DB也可以做到。渐渐它的地位就被削弱了。M编程实际上是绝对值编程。如果重复调用还需要手动去改地址的话就效率太低了。但是我不介意在程序中使用M做时钟脉冲和常1常0信号。

毕竟它们不需要再重复调用的时候去修改。

另外PCS7不使用M，而且坚决不会上传M到WinCC，wincc多数据区去寻址浪费资源，影响通讯速度。说句实话，我看到有人WinCC，只认定一个事实：菜鸟才上传I区，Q区，M区 。

用M，T区去编程，我不会说他是菜鸟，但我可能明确的说，他的程序用在重复度很高的过程控制里能够累死他！

上面有人回复我，PCS7是面向对象编程，我认为它比面向对象更高级一点，是小范围特定环境面向组件的。可以去西门子全球技术资源看看人家对APL的描述吧。它说的比我有文化点。

 

我借用了PCS7的一个电机控制，只是想给大家一个借鉴。谈好坏应该还是有个限定条件。如果愿意请移步“自动化的数字化伴随(一台电机的控制你会吗？）”http://www.ad.siemens.com.cn/club/bbs/post.aspx?a_id=1479053&b_id=80&b_sid=15&s_id=0&pno=1&af=1479241 谈谈一台电机如何控制。

我觉得这要看系统的规模。

小系统稳定可靠，程序易读性，可维护性首要考虑，这时程序的美观，移植性次要考虑。

如果一个很大的系统还不好好规划程序结构，哪些用FB,哪些用FC,还是M地址、全局DB，定时器T满天飞，那真是噩梦。再碰到变量名拼音、中文、夹杂着蹩脚英语乱标的，那就连看都不想看了。

   “好的程序， 一定是模块化的，面向对象的， 层次分明的。”，楼主这句话总结的挺好。以前也是没有体会到这一块。现在我们做程序工艺这块前，都是把电机、阀门、仪表做成个对象，属性、方法、对外输出的动作等管脚对外开放。每个对象建立完成后，程序员就可以把主要精力放在工艺程序这块。

    这种方法应该也可以叫做面向对象吧。这么做以后，变成效率确实大大提高。

    建立电机、阀门、仪表等原件类的标准FB块时，一定要考虑其功能的完善性和通用性。编写类的FB块，很考验工程师软件编程能力与经验的累积厚度。见过老外编写的几个类FB块，写的确实很实用。

易读不是第一位的，标准化是第一位的，尤其是底层程序，编好后，做一套说明文档，指出相关接口的含义。就像做变频器一样，这个端子接进去就是启动信号，至于为什么 接到这里就启动 ，使用者不需要了解，当然在标准程序也可能有BUG，使用者 在使用过程中可以反馈出来进行改进。

这样，公司走了谁都一样。

这个是深有感触的，，

我们现在的传动程序是PCS7做的，内部的逻辑看不到，而且几十台控制用的同一个块，很高大上，使用PCS7 也就是CFC做的初衷就是标准化，规范化，我们这是第一个，也是最后一个。不适合传动控制。

 

可是出现问题，比如内部有时某一个报警会一直置位，你即使复位了，，但就是消除不了，类似于单项启动，，按停止就是停不了，，怎么办？将整个程序块复位，他设置了一个复位按钮，这个需要在程序块里监控后复位，，或者两个方法，重启CPU。。

 

我认为逻辑性的控制，越简单越好，最好什么人都可以看懂，出现问题立马可以解决。不求什么高大上。

如果说“语不惊人死不休”才有效果的话，那我是不是可以说，好程序不需要维护，或者说“不需要维护的程序才是好程序”。

WINCC上直接 读I,Q,M 习惯而已，没有什么菜不菜鸟的问题，都是PLC内部的地址区。

但是，有一点，仅是个人建议，PLC程序里 不建议将I点直接加入到程序内部逻辑控制中，

这样 那天I点坏了 我还要找到 相应的控制代码块部分。把I区传递到 DB里，程序内部逻辑控制使用DB，那天I点坏了，我只要在改个

I 0.0

=DB1.DBX0.0

换成I 100.0

=DB1.DBX0.0

这样的维护，不易出错，而且这部分 可以单独封装在一个子程序里。

曾经有这样的一个想法，我司有几台大型压力机，液压站是采用多个泵头共同参与的，因为在实际应用中比较难判断因为某一个泵头由于自身系统单元的原因，而使整个系统压力下降。所以，引申出对泵头进行自诊断功能的想法。

想法是想法，只是到现在一直没有做这项工作，仅仅只是一个想法。

介于此，我想着手开始做一做，把想法变为现实。

嗯。是像他说的那样。十几年前，200做好、验证过的生产线程序；后来的生产线都是直接复制过去。这么多年也从来没有维护过，修改过。是不是那么完美呢？肯定不是。即便如此，用户也不愿意停机，让你优化一下。

其实，原因很简单。

因为我是针对这套轧制传动系统操作，程序设计的是一个框架，只是内部根据我们的经验数据，有一套默认参数集。此外，用配方方式，预留了12套空的参数集，用户需要更换产品，只需要复制、修改默认参数集，微调一下，达到新产品的要求，保存为新配方即可。

而操作工人的操作方法是不随产品变更而改变的。

这就像你选了一个操作系统Windows，（这里是 s7-200）；你写了个应用 Word (这里就是 200的程序)；这个应用提供了个模板（这里就是默认参数集）。别人用Word 方法熟悉了。虽然你有新想法要去改进（升级）。

用户真的听你升级了，结果是：原来的一些熟悉的操作“按钮”位置找不到了。你的新版就被大量地“吐槽”。不是么？

所以，我问这些大咖，他们PG/PC的操作系统从来不升级。

现在，PLC使用1200了，你也肯定不会去看原来 200的程序。连参考的意义都没有。对吧？

我个人认为，任何程序都不是完美的，只有通过不断改进优化会越来越好，所以程序应该需要开放，考虑周全，安全可靠，你的程序越简单越好，阅读性要好，如模块化编程，能够使用梯形图解决的，就不要使用语句表等高级语言。

简单说一下自己从业6年来的变化，

自己所负责的设备，第一版的程序大都是用的m，然后在整个程序段内跳转，程序块大多是fc；而且符号名都是中文的，定时器也都是用的s5定时器；

当时基于两点考虑：

1. m区，从读写速度来说，有一定优势，而且cpu定了，m区大小就在那摆着，不用也是存在的；

2. 自己所负责的设备是比较接近单机设备，程序的复制都系统性的，感觉不怎么需要考虑程序块的跨项目移植便利性。

后期，虽然还是那种设备，但是种类和功能有些变化，随着plc的升级换代，型号也变了，甚至编程软件都换了，有的客户还要求ab，三菱啥的，才发现这种思路还是有极大局限性的。

如今改了，写程序先考虑独立的程序块，设计阶段最基本的原则是程序块内尽量无全局变量，而且接口大都是udt，边沿触发使用内部静态变量，定时器使用iec，多重背景数据块，必要的话只把定时时间放到接口上，块与块之间的交互，建立db，中转，偶尔几个会用m的还是。

拿到一个新的设备，驱动器、编码器，首先是查资料找报文，写成独立的程序块，如此下来，程序的独立性和可移植性的确提高了。打开ob1，就是一堆的fb、fc调用。需要增加什么，首先考虑的是增加程序块的接口。无论之后的外设是啥，接口留好了，随便怎么外面是啥东西啥地址。

要说带来的变化，同一型号cpu，功能上增加不多的情况下，原来的扫描周期是5ms，现在大概加了1倍，原来128k的卡够用，现在得用512的，好像西门子也不卖256的，现在换1200/1500了，选型就另说了。

现在写程序像是搭积木，基本形状的积木（模块函数）生产商都有提供，不需要搭建者再像木工师傅那样手里拿着刨子锛子凿子锯子，耳朵上夹着红蓝铅笔，扯着墨斗拐尺自己再雕琢打磨。

不需要可读性？！我觉得纯粹就是扯淡！

像博图软件如果不提供帮助文件的话，相信会有很多人拍桌子骂娘了。

每条功能指令，库指令等都有语法介绍，还有示例，还发布demo项目例程，1200还有例程合集供下载，哪一种不是加强被描述内容的可读性。

程序是一个整体，工艺描述，参数说明，接口介绍，逻辑划分，哪一条不是为了帮助使用者更好的理解使用程序？！

汽车部件分解后，在部件层我们看到的是轮胎，车门，发动机，变速箱，中控系统；在原料层我们看到的是玻璃，橡胶，钢铁；每种部件每种材料你都认识，给你一辆车，你不学驾照，不看说明书，弄不懂车载HMI的符号代表什么，刹车油门分不清，你能保证你能把车开起来，并且不开到沟里去？！

没了可读性？一切都是耍流氓！还是街头小混混那种瘪三，而不是坐在桌子对面梳着大背头，叼着雪茄的那种大佬！

给你块仪表，没有产品型号，没有说明书，没有接线图，你能搞得定？

景区公厕没有可读性，你一条大汉进哪间？

手机软键盘没有字母只有光秃秃的26个空白按钮，谁能玩得转？

你连个名字都没有，没个证件，没个身份，谁能知道你是谁？

你丧失所有记忆后，别人不告诉你他是谁（姓名）？你又能知道他是谁？

可读性是什么？可读性是信息传递通畅，接收完整。

不需要可读性，当个冷笑话听听就行了。

如果用200或者200SMART编写一个库程序时，你就会发现，编写的库程序内，只用局部变量，不用全局变量的话，在所有项目中调用的时候，都不用分配库存储区！！！

非常支持 @万泉河 的说法，全局变量，能不用就不用。非要用的话，就用在接口处（IN/OUT)。

程序无需可读性，说明文件不属于程序部分，说明中需要说明清楚程序的使用。

要清楚：说明文件不属于程序。

DOS6.22提供有help.com文件是专门对DOS所有内部指令外部指令做描述的。help.com和command.com完全是可以分离的两个文件。两个文件的各自工作不依赖对方。说明是一回事，程序运行时另一回事。你看就看说明可以了。不必看程序。

对吗？唐大人。

当前的程序考虑是基于一种设备的动作流程，按功能和部套进行分块做的程序，上下相关功能之间需要动作的衔接，有些标志和数据，需要彼此判断；不同部套之间的动作也需要衔接或者互锁，也需要彼此信息的获取，放到一个udt为了减少接口数量，当然，如果全是bool的标志位，可以用word之类的代替，但是按位使用时，只能根据序号或者地址使用，不便程序解读；个人是如此考虑的，也是借鉴了别人的一些地方。

一点都不精华。 程序满足现场需求， 那是基本条件。 

没有达到需求的， 压根不通过验收， 完全的垃圾废物而已。 不在考虑之内。 

我们评价程序好坏，是指同样都达到了客户工艺要求， 正常运行的。 

支持万版的说法！

满足生产工艺的需求，满足生产质量的需求，满足产能的需求，满足可靠性的需求，满足人机交互的需求，满足设备维护的需求，以上这6点应该是所有能够使用的PLC程序的最最基本的要求了吧。还在讨论是否能做到这些的，说句实话小屁孩还抄着尿不湿呢，幼儿园的水平都不够！

哈哈，大师的作品，岂是一小白能一眼看懂的，不在一个水平线上，谈何易读性！？

低水平读高水平的程序，艰涩难懂，犹如咀蜡；

高水平读低水平的程序，满目荒唐，犹如吃屎；

当你能和某人深入交流某个程序时，说明你俩曾经都掉进过同一个坑，是坑友；

当你看别人的程序是那么的似曾相识，确定不是抄袭的，那么恭喜你找到了一个水平相当的知音了。

为啥不愿意看自己以前的程序了？那就是你的水平变化了，应该是吃屎的多，咀蜡的少，反正都不爽！

再问大家一句，什么是程序的易读性？

一个程序都做不好的人，能把程序的说明给写清楚了？

相反，做得好的程序，没有说明一样能看懂，只是初期少许困难些罢了。

FB块一定就是完美的吗？FC也一样能做到呀！

@工控一良  数字化浪潮从计算机发明的那一刻就开始了，PLC说白了也是计算机技术的产物，近些年又搀和了网络IT技术，现在的应对和转变不知从何说起，如果一定要说那就是一直以来的常态化的应对和转变，楼主的感觉就好像与这些年的技术发展完全隔离了似的，工控就是现成技术的应用与创新应用，没有基础性的发明。

满足生产工艺的需求，满足生产质量的需求，满足产能的需求，满足可靠性的需求，满足人机交互的需求，满足设备维护的需求，以上这6点应该是所有能够使用的PLC程序的最最基本的要求了吧

非常认可这6点，如果能够把这六点做好了，就是很不错的程序了。

那得看你愿意是，或者追求是，在或者事实上就是哪一部分的了。

你有过在现场一周的时间内现写一套三轴往复定位的控制程序，然后拍屁股走人，这套系统用户一直用到一年后元器件故障才来找你的经历吗。

说实话我追求这种感觉，Impossible is nothing！

做到这六点就是合格的程序，万版所指的程序的好坏实质上是水平高低的意思，就比如高中毕业会考都合格了，但高考你进了一所本地二本院校，你的同学进了清华北大，是一个道理。

用不用M和T个人可以根据水平在一定时期一定场合下自由决定，我告诉你，我的延时程序可以只用二进制逻辑指令实现，你信不信呀?

你是否同意我们的观点，你是否愿意实践我们的观点，等你这么做了，如果收不到业主的钱你再来找我呗！

大家是做相同或者类似的工作，才在此如此讨论程序的好与差，算是工匠之间在讨论手艺的优劣；

如此从设备使用者或者局外人的角度说，实现了功能就是好的，那自然是无需说的，如果功能都无法保证，那就不说讨论优劣的问题了。

恰恰相反，我们可以分析客户行业的操作规范，操作习性，直接就在PLC程序里考虑了人机交互的需求，所以对人机界面来说，PLC数据的变化导致了人机做出不同的响应，实际上PLC与人机之间的交互也仅仅就是数据，所以大部分情况下，我们的PLC程序定稿，也就是人机的功能也就确定了，其他都是些修饰性的了。

我的同事可以在背靠背完全不知情的情况下，拿了我的程序，把一个设备的人机的基本操作功能（如点击操作，状态显示，故障报警，手自动切换连锁等）就给实现了

自动化设计时都要考虑那些因素，可读、可复用是作用于谁，或者说谁可读，谁可复用。

Design for product, design for production，design for engineering，design for operation，design for mantain, design for optimization. 这些理念和需求我想应该不仅仅是对产品设计人员提出的要求，同样适用与自动化人。而为适应和满足这些要求牵扯着各种知识、工具，这也是我所提的“自动化的数字化伴随”中想引入的，有什么样的软件技术、工具，自动化人能够拿来加以利用的。西门子自动化部门搞的那几个数字化案例介绍，当时触动很大，自动化还可以怎么搞，用软件调试完了，自动化任务基本就干完了，甚至把什么VR，AR一并加上还要什么现场。

是吗？我们有工程师为了一个人机界面的变量在现场试了一个月，这算运气好的！一个MP坏了要换，没有源程序，PLC程序可以上载。虽然艰难，但把大部分变量对应上的时间花得不多，少数几个在屏里做功能的变量，就好比猜谜语了。事半功倍，还是事倍功半？
要我，搞清楚工艺，重做程序了，也不会这么费事儿！

博图中，使用M区变量，你不定义变量表，它也主动给你分配个什么Tag x 做了个变量表了。因为博图是（标签）变量名称编程。它不关心实际地址。

如果，你在变量表中。修改了变量名称，项目内的对应变量名称自动修改。

如果，你在变量表里，将M地址改到别的地方，项目内的所有这个变量名称的M地址自动修改。

关键的是要把相关的项目都得打开。才能完全编译，不出错！

难道不是这样么？

看了万版的观点，我理解是现在编程方式逐渐往高级语言看齐，特别是西门子越来越注重标签寻址。

不用M 及定时器，我觉得是为了程序的可移植性，标准化，模块化；在多人协作的项目中尤为重要，虽说划分区域也能避免，但是在变量定义这一项上就会浪费很多时间。

我现在控制对象都是用FB块，在inout区用结构体变量将控制及反馈信号接出来，这样程序块接口会很简洁。当然在step7监控的时候会麻烦点，但是博途已经修改了，必须赞个。

可读性，我觉得是相对的，新人跟做了几年的人看的角度是不一样的。我看到别人好的编程方式就马上学习加以利用。

由于英语学的很烂，变量名都是中文的。后来看到个兄弟写的英文变量，用下来编程速度明显提高，重拾丢了10几年的英语，真心是活到老学到老啊。

DB不都是全局的么(通讯可以完全访问DB，对于通讯来说他就是全局变量了)？M又怎么就赖定是全局的了(也是都可以访问)？不懂。
高级语言提倡不用全局变量是因为居于操作系统的面向对象编程时类如果使用全局变量会导致构造、析构、继承等等…各种麻烦，导致类对象需要另外增加各种处理，还有针对多线程线程间数据不一致引起程序崩溃…
如果写的程序是基于用不完的内存的处理器，不用全局变量问题不大，如果内存像单片机那样数着来用的就必须用全局变量减少动态内存开支了。
所以，你看看人家写驱动的都是全局变量怎么破？

有所为有所不为。 

人家提供给你资源你就要全用掉啊？

你自己可以有原则的呀！

我们在讨论的是原则的问题， 而不是资源的问题。 

总有人以西门子PLC中提供了全局变量资源，来认定用全局变量编程的方式是好的， 这里面的逻辑简直不可理喻。

PLC就相当于电脑。 想一想同样电脑的资源，为什么有的软件公司开发的软件是精品， 有的软件公司就要倒掉了呢？

PLC开始是从继电器控制发展起来的一种控制设备，（M、T）用来替代电路中的中间继电器、时间继电器的，大大降低现场线路的复杂性，当年PLC性能关系，执行效率也是要考虑的问题，并且使用梯形图比较直观，容易被一些由电工发展而来的维修人员掌握，在工业设备中得到大量应用，但随着时代进步，PLC硬件资源大幅提升，熟悉高级编程语言的人越来越多，现代工业设备的功能越来越复杂，对于一些大型项目，如果还用以前的方式进行编程，确实跟不上设备的进步了，故还是认可版主理念的，我们也应该与时俱进，但对于一些简单的电机启停控制之类的程序，就不要太纠结程序好坏，要不要用M、T了。

我比较认可万老师写的这句话：“好的程序的标准是：不使用M中间量，不使用Timer。”我再回上一点就是软件的执行效率，也就是PLC的扫描周期。你程序写的再美，达到同样的效果别人也用了6ms，你写的用了30ms，哪个好就显而易见了

你错了， 扫描周期是次而次之的指标。 

只要能同样完成工艺任务，达到了同样的效果的前提下， 完全可以不在乎扫描周期。 

从历史上看， 很多小而美的软件公司都死去了。 存活下来且发展的比较辉煌的软件公司， 微软， 腾讯， 所发表的软件产品，在性能上看，都是大垃圾。 但没办法， 用户友好性高啊！

你以为PCS7比S7-400好在哪里？

道理讲的很清楚，很受益，自己以前在做程序的时候也基本靠拢这个思路的。不过这样的软件设计更适合能做成成熟软件产品的应用场景，对于一些类似集成的、可变因素多的软件活，可能就不好这样要求了，不能为了标准化、模块化而标准化和模块化，那样可能会增加很多无谓的工作，软件效率也会相应降低。

不能为了标准化、模块化而标准化和模块化，那样可能会增加很多无谓的工作，软件效率也会相应降低。-----------最后的这段话典型的中国软件公司的思维。 

记得以前有人比较中国软件和印度软件的时候就提出过这样的区别。 

一个中国软件公司， 在前3-5年的时候， 人数小于50的时候，工作效率是高。 但等过了10来年， 程序员人数过百的时候， 效率就大大降低了。 甚至乱成了一锅粥！

而印度软件公司正好倒过来。 

认可。
德国工程师的原版程序。
不是PCS7，大量自定义数据类型，每个设备一个FB，对应一个局部数据块。
通用的FC块都是STL语句表编程的。
大量的间接寻址，指针变量，尤其数据块。基本没有T,M。
看起来很过瘾，很考验个人能力。对指令、寻址理解的不深的话，基本看不懂，还有就是栈入栈出有很多陷阱。
唯一缺点是： crossref基本用不上。为啥？因为都是间接寻址，crossref查不出来。如果要查一个特定的地址比较麻烦，要看变量声明，层级展开确认指针和偏移量。

读别人的程序，在于对控制设备的熟悉程度。不客气的说，如果不熟悉控制过程，单靠读程序，任何人都很难做到完全的理解。当然，一些简单的控制就不用说了。

我认为用了T和M也有可能是好程序,不用T和M也可能是不好的程序.

好程序的标准我自己想应该有以下几点:

1. 稳定,操作简便;

2. 要有注释和说明;

3. 报警详细;

4. 可读性好,自己要看懂,别人也要能看懂;

5. 结构清晰,方便查找问题和更改.

别的应该还有很多吧,但我想主要的是这些;

看了下大家的帖子,感觉万版主说有有些偏激.

    其实做PLC编程的大多数人都没有经过什么专业的培训,写的程序自然也不专业,至少在我们这个小城市我周围的人大多是这样的,所以并没有多少人会认为自己的水平有多高,人外有人,天外有天这名话大家都明白.但改造设备时确实大多数时是想删掉别人的程序,自己重新来写,但这并不是说别人的程序就没有自己写的好,而是自己用别人的程序,就要明白别人的程序和思想,要不然只是改的能按要求动作,但真有别的地方出了问题,你要是看不懂,或要很长时间才能找到问题,这就比较头痛了.别人程序好的地方可以拿来用,但一定要弄明白.重新自己写程序可能问题要比原来的程序多,但为是的排查故障比较快.

    还有些同学说程序自己能看明白,不用管别人能不能看明白,我认为这是十分十分错误的想法,现在的工厂都是24小时生产,你写的东西有问题,别人处理不了,你能7*24小时提供支持吗?如果单位有20个电气工程师做的东西相互之间都看不懂,大家不能相互支持,那怎么处理售后服务和以后的改造,如果你不干了,设备别人怎么管;如果别人不干了,设备你怎么管,想过吗?写的程序虽然不能让所有为看懂,但只能说尽量吧,就是小学老师讲课,也不可能把所为的学生教会,对吧?

    至于说用FB,很多国外的专用机械都用了很多FB,虽说他们的设备比较稳定,但以我这种不专业的水平想看懂是很难的,一旦出了问题想解决也很难.我认为在这个行业工作的很多人都和我一样,很怕看这种封装好的FB,但如果用M点编写的程序,一步一步走下来,要好解理一点.但可能这样还是算比较初级的程序吧.

    当然要实现一些特殊的功能时用FB,比如西门子的FB58等等,虽然我看不懂里面写的是什么,但也应该理解是好程序.不过有一天谁要是告诉我FB58里面的问题,把它找出来,或要让我把FB58做个改造,我想......

是的。我也是S7-300以上的程序几乎不用M和T,一个原因是资源有限，S5T格式难受。也不利于地址规划和后续地址冲突一类的问题。如果用M和T，很难做地址规划，程序可读性，模块化很差。读到这种人家做的程序就不想继续看下去了。

我喜欢用FB，带背景数据的。同一种设备类型建立一个FB。再通过多重背景数据放在同一个DB里面。这样设备地址就很有规律，在WINCC里建立变量地址通过自动填表功能（老版本需要安装一个EXCEL插件）一下子全完成了，不容易错。比如模拟量处理建立一个FB，这个FB背景数据占用100字节，如果我有100个AI,这样我建一个多重背景数据DB1,每100个字节存储一个模拟处理数据，数据地址很有规律，便于查找。

     里面有些需要顺控计时的可以自己建立变量定时累加和比较，精度基本满足了。

唯一可能用到的是一个时钟内存M字节。还有如果从控制器存取效率来说可能M会比DB快，但基本应用谁还会在乎这点差别呢。可靠性，可读性和可维护性才是关键。

    

我觉得你系统小，速度区别不大，用到FB就要占内存。。。。

你设计时还要加入架构，单台设备的话就算了，多台的话加多一个高级PLC来处理数据，现场控制还是用到M好了，不要用那么多FB，扫描周期会加大的，你觉得运行差不多，但是生产效率会有很大区别的，一天少产100个，一年就36500个了，一个赚1刀，都够你一年工资了。。。。

扫描周期和生产效率的关系是如何推算出来的？

请给个数学公式吧！

比方说一条汽车生产线， 你扫描周期20ms，提高到10ms，产线产能翻倍？而如果扫描周期到40ms， 产线产能减半？

当然有个重要问题就先放下不问了： 既然CPU速度这么重要， 为啥设计的时候不用最顶级的CPU呢？

 不知道有没有做汽车行业的朋友？像大众、通用、奔驰、宝马这种公司都是有自己的标准的，比如大众的VASS标准，通用的gloable标准，这些标准据说是数百位工程师一起开发的，并且不断的更新版本，在全球所有的工厂都用这套标准，后续使用维护起来非常方便。他们的标准非常成熟，基本都是标准块，HMI画面都是自动生成的。。。。相对比较一下我们国内的汽车厂基本都没有标准，我们的要求一般是“能用就行”“功能没问题就好”这类的，个人化太明显。。我估计其他行业应该也是这样。。这也算是一种文化差异，一种差距吧。。。