引用37楼详细内容：

6，问你个问题，假如程序有100个报警，用M区存储可以采用名字为A001--A100，采用DB的话最简洁的就是"F".A001--"F".A100。当这些报警显示在HMI上的时候，现在的维护人员如果最快速在程序上找到这个报警的位置？假如用户使用的不是wincc，并不能直接从HMI跳转！

拿你上面的电机来说，不管什么项目，最基本的电机就是电机，没有不一样；

我会先做个UDT ，UdtMotor ，里面包含控制信息，状态信息，故障信息，电机IO所在的PN或者DP的诊断信息，相关控制参数；

使用UDT+DB的方式，我在程序里引用电机的某个状态，比如正向运行信号StStartedfwd。对我来说就是 ProcessLine1Motors.Motor1.StStartedfwd。这就是我对生产线1的1号电机的运行状态的引用，

我的结构化数据块很清晰，ProcessLine1Motors是个DB，Motor1是个UDT，我有100个电机，我就是Motor2，Motor3，它们的数据类型都是UdtMotor，而且TIA Portal Step7DB编辑器里面 都可以像EXCEL一样拉动操作了。

还可能 相同的第二条生产线在一个PLC控制，很简单复制下DB名称改成ProcessLine2，生产线2的100台电机控制所需的变量建好了。

用M 可以，如果标准化程序做的好，每个电机占用100个位，占用40 字节。全用M区，整个工厂200台电机，你看你用M区够不够，而且 这个工厂不大，用M区来定义这些位，你的符号表要建多少变量，因为M区不能建立复杂数据类型。

说了 这么多 我只是阐述 DB +UDT 以及Struct等组合的优势。

4，FC的out参数，如果程序内部不方便初始化，或者使用s/r，或者程序有跳转，用DB作为实参是会出问题的，而用m区不存在这个这个问题。

这问题始终无解？在CPU运行过程中M区和DB有何区别？不知坛里 其他同行有什么看法？FC的OUT参数在运行过程，要一直赋值，这是必要的。不能有跳转等不赋值的情况。

引用36楼详细内容：

这应该是西门子PLC的优点之一吧，用起来很舒服。举个最简单的例子变频器的控制字

1，通信的时候作为整个字进行传输

2，逻辑控制的时候，可以一个个bit单独控制，而不需要进行任何的拆箱装箱工作。

引用35楼详细内容：

最近在论坛看到类似的贴子多了不少。

我实际上发此贴真正的意思并非是出于哪个不好，或者哪个不对。而是在调用前先调用再使用，是我发帖的真正含义，这样可以确保地址重复使用的可能性。编程稳定、安全、可靠是关键。

引用详细内容：

1，M区对于绝大多数人来说足够大，使用M区恰恰为了是结构更简单而不是很乱，M区定义好符号表后，直接使用符号很方便，用DB是极度不方便的。比如有100个Motor，对应一百个fault，每个项目类似单不完全一样，所以有些注释需要跟着改变。那么实际应用的时候，需要找到motorXX，我就在goto location那里输入motorXX，就能直接找到了，你用DB试试怎么输入，无论如何要逼用M区复杂得多。当需要修改注释，我在原地就可以修改，不需要离开编程的位置，DB可以吗？不可以！而且使用DB会导致符号很长，因为DB的名字是必须的，加上每一级struck都要增加个“.”，结果就是注释太长，程序很难看。

2，DB+UDT绝对没有想象的那么好用。修改完udt回到DB的时候需要重新update，工作量不见得小，有的FB引用了UDT经常会出错，工作量更大

3，DB可以实现的复杂数据类型，基本上用M区都可以替代，只是少了个名字而已，但是用起来更方便，因为他是绝对地址寻址，比如Any数据类型，M区可以很方便地定义每一个位置，不知道那里比DB不方便？

4，FC的out参数，如果程序内部不方便初始化，或者使用s/r，或者程序有跳转，用DB作为实参是会出问题的，而用m区不存在这个这个问题。

5，编程习惯就对了，你有你的习惯，别人有别人的习惯，每个人都有自己的规划方式，并不代表哪个更好。为何用M区就叫狗皮膏药？如果M区这么不好，西门子干嘛不取消掉？

6，问你个问题，假如程序有100个报警，用M区存储可以采用名字为A001--A100，采用DB的话最简洁的就是"F".A001--"F".A100。当这些报警显示在HMI上的时候，现在的维护人员如果最快速在程序上找到这个报警的位置？假如用户使用的不是wincc，并不能直接从HMI跳转！