用结构化编程在功能块或功能内为了项目移植方便及通用性内部肯定不要去用M。如果是特殊的恒通或恒断，必要的时基，异常复位啊看情形来。那没结构外之外的零散逻辑放着方便的M不用去用DBX.DBX.X不是差不多么？甚至还不如用M直截了当。或是不是有更高级的形式替代M或DBX.DBX.X的好东西。要能被第三方软件能读写。

M区有数量大小限制（根据CPU不同M区大小不同），DB块可以很大（受限于存储大小）。

DB块可自定义，分类，数据集中存放，比M区好用得多。

第三方软件能读写的有I,Q,M,DB。

 嗯，以前STEP7的DB里的变量符号名不支持中文，现在博图V16里试了一下支持全中文，M虽然土吧但支持中文符号名，交叉引用里面使用情况还是看的清清楚楚。虽然不那么高大上，个人感觉也没有有些高手把M说的那么不堪吧。1200/1500/300/400的M区至少有2K字节的，零散逻辑用用感觉也挺实用的，GOTO一点使用情况也很清楚啊。是不是我的行业应用（一个项目下来也上万个点的）限制了我的格局和眼界？

最近几年都没写程序了。 这几天刚好我也在看这方面的内容。

我的理解：项目移植、项目移交。M和T在这个过程中会给项目移植和移交带来不可避免的麻烦。用FB，中间变量都在FB内部，在移植、再利用等过程中不必考虑这些因素。知道这个块实现的是什么功能，输入、输出有哪些就行了。如同使用step7自带的那些功能（块）。

ONLY DB

 如果是这样那就对了。万物存在总有它的存在的理由，那整个M区不就是西门子相当于已经帮你生成好了的一个以bool量为基础的特殊“DB”块。零零散散边边角角的用它也不差。突然灵光一现，难怪有些设备或软件和200或smart200通讯读V区对方就当是虚拟的DB1。

现在我写的程序中，就是系统时钟用M，其它基本都是DB块了，DB也可以单独掉电保持，感觉还可以。

回头想想也有道理。博图支持全中文了。不向STEP7的DB块里定义变量只能是罗马字符，凭仅有的词汇量表达不出所有意思，用拼音缩写时间长了自己也糊涂，写的注释吧有些地方还只能鼠标靠近才出来。我们做的行业太杂，没有一个同样的，更注重功能块的优化。

除了系统时钟用M，其他变量全部用DB，可以分几个db块，比如所有的运行一个db，故障一个db，数据读一个db，数据写一个db，也可以一个电机的所有变量做成结构体，这样建变量就非常方便了，项目移植也方便很多。用好了结构体，你根本回不到M上面去。

万物存在总有它的存在的理由-------因为旧的PLC有就用了------然后在研发新PLC的时候因为有用户旧程序要用，所以要继续保留不能扔-----然后新用户新程序又用------然后再新系统扔不掉

然后系统就永远只能将错就错维持最早的样子，永远都不能发展进步了。

因为厂家研发产品也还要满足用户需求，所以同样被用户牢牢困死了。 

我们老家小县城，30年前盖的楼房里， 都还是有农村那种土炕的。

就是这么个逻辑。

因为老百姓家里有老人习惯了睡土炕，所以盖楼需要有土炕。而因为有土炕， 你即便上楼了， 也仍然睡土炕。 

这个死循环一直到现在没有完全解除， 去很多亲戚家里， 仍然有土炕。 

万物存在总有他存在的理由么！

 万先生首先我不是杠精，那边是我看气氛有点不大对想缓和一下气氛的，没想把你给惹不愉快了。我就是好奇零碎不成体系的逻辑用M也不可取？你的文章我大概都看看了就从你打出fredoooooom我就猜你肯定没少搬LADDEER靠着WAAIII.。如果是的话其实我们还是有相同的关念的。关于知识付费我也很认同，搞笑网红能凭才艺在网上获利过上优哉游哉的日子，工程师借靠网络获利也未尝不可，阔**开第三产业不纯为利就图个乐。我如果高攀一句不打不相识不知你可否认同

我感觉就是习惯，我也不用M，因为我在做程序的时候就没有用M的习惯。

对M区的访问与对DB的访问，还是有区别的，寻址有简单复杂的区分，那么访问的速度也是有快慢的，可能一般情况下觉察不到，可以重复做个几千次测一下耗时。

在300年代就没有用过M了。程序都是由各个基本FB搭建的。没有用分散的元件写程序。哪怕再小的部件，都写个FB来实现。就不存在M FP之类的烦恼了。

1，用不用M区，并不能作为判断程序好坏的依据。例如：smart200的M区和V区。

 2，一个好的程序，首先要结构清晰，注释清楚，适当的用M区也无可厚非。

3，

-------------------------------------------------------------------------------------------------------------

人身攻击不要哦！

by Zane

这个话题讨论了几年了都没意思了吧

M   可以用而且对我必不可少，但是只用在全局的标志如，全部仿真/全部自动/脉冲/公共标志位，用的不是很多但是非常方便也无可替代，M受限很大，像复杂的数据类型他就不行，你也不用反驳这是事实，真实情况是你要在除公共区域测试外的具体对象上面避免用到它，之前我改过一个人的程序他的什么乱七八糟的都是SCL写的包括一些IO信号，因为在FB中在这种情况下你用什么来改他的程序？肯定是M,因为M不会涉及OPN DB的问题，所以说M我感觉有着无可替代的作用以后一直还会存在。

T  说起T很多人觉得IEC TIMER好用，确实好用但是这也有坑，我个人觉得是西门子的BUG，首先是输出管脚必须连接变量或者使用管脚的静态变量ET Q才会更新，这个是说的过去的，还有一个问题很多人没注意到，IEC TIMER背景DB必须设为不保持,这是我之前发现的问题，有一次用的1515的CPU SMC卡12M改动大的话下载不进去（这也比较头疼，你必须买你程序装载内存的2倍以上不然大量下载更新就会导致卡不够用）因为前一个项目配的是24M的卡，我就去设备上等停下来后我怕参数有问题我将程序所有DB读了快照然后写到初始值，结果呢卡换了以后发现有些输入状态不对，IO值与控制值不一样（控制值做了相应处理的值加延时逻辑配置），发现只有常闭点有问题，只有把开关重新触发才能解决，后面我发现是定时器的问题，如果定时器的初始值为True并且背景数据默认保持的话就会出现这个定时器不动作的情况，而且这种问题很容易犯。我觉得西门子应该就这个问题发一个说明。

关于程序很多人觉得背景DB很好用什么都去访问背景DB其实这是错误的，不能说错误这是非常不好的习惯，用IO接口才是最好的，用udt定义一个数据存放区

另外博途有个很不好的地方 就是FB DB HMI窗口不是以编号排序，你起码让我能选择排序方式吧，程序的结构就是有顺序的每次必须搞得我在前面加一个编号，不知道西门子什么时候能让我们看到以编号排序，符号化也不是这么搞的。

PC与PLC同属一系，既有相同之处，又有不同之处，程序执行的工作机理有较大的区别，因此编程时还是要考虑其差别的。

至于处理速度，对于控制系统来说太快了不见得是件好事，尤其是针对基于事件的编程。

PLC之所以还存在的理由，就是因为他的可靠，用户程序的全扫描是其可靠的重要因素之一，每一个扫描周期都把所有控制程序处理一遍，每个扫描周期都是尽在掌握之中。而基于事件的编程在可靠性上是存在明显的缺陷的。

另外再说一句，这与硬件的中断响应是有区别的，也与用什么语言编程无关。

M一边去儿....连时钟也不用！！！！！！！！！！！！！！！！！！！！

从来都是自己写一个时钟的FB，多重背景生成想要的时钟频率，10Hz,2Hz,1Hz, 0.5Hz, 还有0.1Min, 1Min的... ... 自己写的才是想要啥就有啥，自带的永远只能是将就用。再一个M区破坏程序的整体结构，移植存在冲突的可能性。 楼上一位朋友讲得如果一个很小的零散的项目，也不能用M区？  非不能也，实不为也！！！当你养成一种习惯后，你就不会去那么做！

闻道有先后，一个大侠认知和能力是经年历练的结果。

那些小白、菜鸟们可没有这样的历练，所以他们对你的观点肯定是不能理解和赞同的，也许他们同样需要一个漫长的历练过程。

我本人可以编写出完全不用M/T/I/Q的程序来，但我从来不会要求我的客户，也不会强制他们去这么做，充其量只是当作“课外知识兴趣点”介绍一下而已，甚至我自己的同事做项目也没有很严厉的去规定他们这么做。

介绍以一种完全不用M/T的编程方法，这件事情本身完全没有问题，但作为一个事情优劣的判断标准我认为还是值得商榷的，还有这其中的表达方式我也并不赞同，这无形中划分了界限划分了优劣等级，造成小白们的自卑和焦虑心理。任何一个群体都是一个循序渐进的，小白-熟练-资深-专家，每个个体也必然经过这样的过程，只是时间的长短而已。以专家的水平去要求一个小白，这未免有些强人所难，或者说拔苗助长了。

所以我认为作为论坛的资深网友，技术上有一定成就的专家们，还是要有耐心，要有一颗包容的心去看待小白们的成长，多多加以指导。而小白们也要有谦虚，尊敬前辈的态度，不耻下问，不畏艰难的精神，努力地去提高自身的技术水平。

要真正自由，标准化，尽量用符号编程，具体应用时赋值一下IO点即可。如做不到，尽量用DB块，因为这个与存储相关，与CPU干系相对远一些，用M点，受制于CPU，何谈标准化？

我虽然也不用M，但是我感觉只要逻辑清晰、有条理、可读性强就行。每个人做事有自己习惯，合适不合适本人自己会清楚，非要把自己的观点强加于人是不是太强势了？认为有人与自己的习惯不一样就火急火燎、苦口婆心的去纠正别人，是不是有点像YSL教一样，不是自己的习惯就是YJT？要清理YJT?

技术之外的话：

1. 好程序，坏程序，有明确的标准么？争论这么久的话题，目的是要制定标准么？

2. 事物都是存在多面性的，从不同的角度会有不同的观点。简单的说，我关注移植性、关注标准化，那就不用M/T的好；我不在意这个，我只在意功能性、在意程序的大小，那就想用什么用什么。

3. 搞技术，就要交流、沟通，不怕争吵，但应把范围限定在技术范围内。——羡慕你们有这么多时间在技术范围之外进行无意义的吵架。

4. 人的本性？ 被否定或者不被认同就不舒服，就要去吵？ 我相信每个人都有“惯性思维”，都有局限性，别人提出了一个自己不熟悉甚至不了解的东西，我认为第一反应不应该是先去反对，而是去了解，取长补短，完善自己。
   

技术之内的话：

PLC是可编程逻辑控制器。它使用专用的处理CU芯片，有别于PC机的通用CPU芯片。

M区和IO映像区都是芯片自带的存储区，同时这类CU还有专门的布尔逻辑运算器。

如：1200不管型号（内存、扩展不同）同一芯片，它M区大小是一样的。M区和IO映像区均可直接使用布尔逻辑运算器。所以速度很快。

这也是有些运算、有些数据类型M它不支持的原因。

这也是它和软PLC之间的差别。

好久没分享了，我来分享一个。 这个是我改之前同事程序的时候发生的现象。

1、“单循环”这个全局变量，变量表里对应的地址是M74.3  ， 将鼠标选中“单循环”，在下面的常属性里可以看到它对应的地址是M74.3 ， 如图1

2、然而.... 当你把鼠标悬浮在“单循环”这个变量上时， 它显示的对应地址却是 M0.2 !!! 如图2。所以当时出现了一个奇怪的现象就是： 程序在别的功能块里写入了“单循环”（M74.3)为TRUE， 但是在这个功能块里监控“单循环”(M0.2) 却为FALSE！！！  交叉引用查找 “单循环”定义的确只有M74.3 ，  一个变量，却有两个对应的地址，神不神奇？意不意外？

3、选中项目的程序，右键点“软件全部重新编译”， 这个操作过后， 再将鼠标悬浮于“单循环”变量上，它显示的地址变更为M74.3 了！！！

说明了什么？
1、尽量不要用全局变量，更不要使用M区！ 偏激点讲，M，T等等这些地址都是属于上世纪的产物，那只是为了兼容以前的PLC来使用。  我的程序里，从来不用系统自带的定时器T，也从来不用M变量作为中转，从不！Never ! 养成这个习惯。  需要全局变量怎么办？ 自己建立全局的DB块！  使用M区，当几个人编辑同一个项目时，往往造成不可预知的地址冲突，象这个一样。另外项目移植时也容易造成地址冲突。
2、当程序改动较大时，特别是增减了变量，一定要选中程序，软件全部重新编译！特别是HMI项目有时不这么操作，结果显示的画面不全，甚至变量对应不上！

以上纯属个人观点，不必强加于人，只是个人分享

这说明了拷贝过来修改过的程序，重新编译的重要性，与M无关呀，如果是C或T也有可能是这样一个结果，当然你说是博途的小BUG也无可厚非，但把责任都归咎于对M的使用，着实有点不公平。

      嗯，在哪个开发平台就用这个平台给你提供的合适的开发手段包括环境，语言，符号，书写规定，规章条例可能还是明智的......。

      在纯软件领域你不熟悉C++,C#，Jave应该不妥因为大概率没T形图给你用;在嵌入式平台你不能熟练用C可能不合适;在PLC平台你不用开发好的T形图也不一定就真的高明.（例：几何时T形图被有些培训机构，著书立说者说成是机电自动化工艺编程的优势，现在摇身一变站在利益层面说T形图低级过时了，必须要高级化培训）-是故非语言之高低贵贱三六九等也,实为熙熙攘攘利来利往也.（语言:含编程语言以及以上文字语言）

      说到主题是否要用MT来做PLC程序：例：顶级大牛Linus骂用C++开发Linux是很可怕的，不能用C++，要把用C++的踢出去。虽然很多人觉得他讲的很有道理，但丝毫不影响很多人用C++，丝毫不影响C++不停更新"创新"，开发占领一个又一个“大项目”.

用M区，应该是从接受培训的开始，就把思维给固化了，要打破。不用，就是不用。一边玩去。

以下是我第一次用1200的问题。

1. 上升沿。这上升沿怎么这么奇怪，要两个bool变量。真烦，没有200smart简单。

2. 定时器。这定时器怎么还要实例DB，拖一个来一个，拖得满屏幕的IEC_TIMER，看的心烦（当初还不知道能创建文件夹，更不知道FB的妙用）

3. 计数器。理由和定时器差不多吧。

4. 除法指令。200samrt有一个DIV。输出商和余数，1200只有单独的，要么商，要么余数，就感觉很烦，一个指令多简单呢，1200不行。（当初更不会玩SCL）

现在回想起来，当初是真的傻。特别是自己学习了SCL之后，博途是真香。LAD+SCL混合着来。

存在即合理，这是不对的，存在就合理了？有的东西存在就是不合理的。

学会打破现状，会发现更多的编程乐趣。

看到大家的发言，我也想说说M的弊端，我在早早看到万版的摒弃用M的说法是，感觉也是有点扯，但随着时间的推移，自己的项目用M的弊端慢慢的旧体现出来，最深的体会是，本来我M点1byte刚好可以控制2个风机的启动、停止、正转、复位，80组风机，占用20个字，设想很美好，控制效果也采用for-next 循环，控制简单，刚开始没有任何问题，但去年，一个项目，现场要加一个高低速的位，我当场就崩溃了，我都是用字节控制的，怎么加，无奈加了个通宵，自己建了个自定义数据类型，建DB,重写程序，才能用，通过这件事后，印象深刻，以后能用DB,绝不用M了！。

m我是绝对不会再用的，很多新手用m后也不写注释，然后用多了自己也不知道哪块区域没用，一旦地址重合，尤其是做通讯的时候，传过来的数据就在那里跳来跳去。

你的示例不能说明什么问题

字节改字一样的方便，在博途全集成环境下，你可以自己去试试！

再说了，为啥不给自己留点余地呢？记得世上还有个墨菲定律！

也就是M区变量（和IO变量一样）是可以重复定义的。要好好利用它。

DB中的不可以，也无法重复定义（即便你取消优化）。

说了那么多不用M，我倒是觉得，应该想一下 M区可以用来做什么？

想一下：

为啥 I Q M是统一的？

为啥只有M和 I Q 一样是直接寻址的？

为啥系统功能变量 只能定义在M？一些PLC干脆把系统状态标志固定在M变量中。

了解了这些，就知道M该用在哪些方面了。

个人习惯，我采用的是Excel表格，来做设置

主要是PC和PLC通讯

交换是数组，基本不用M

设置参数和反馈数据都是数组（DB）

数据都在数组里了，没有必要在搞M了

感谢版主的回复，我程序设计之初刚好一个Byte占满了，没余的，每个字节又是连的，只能最后面增加，，所以后来才改用UDT,这样我后面再加其它功能，仅修改UDT就放便了。其实看了大家的评论，我认为要是能把M使用的弊端在什么情况下出现分享出来，会更让大家接受，毕竟每个人的高度不一样！

UDT也会同样没有余地的，即使留有余地，也不是无限制的，所以这一点上M和UDT的使用上区别不大。

有区别的是，绝对地址的寻址，与结构体符号名化的寻址，参数传递的便利性后者是不言而喻的。

当然，从资源多少的角度来看，M和UDT还是有差距的。