最近看了下论坛，发现大家对FB的态度是一路看好的，觉得可移植强，设计工作量减少了，但这都是设计人员角度去表达自己的观点的。

FB其实就是面向对象中的类，在实际程序中得生成一个对象来使用，这个对象拥有自己的属性也就是保持自己的数据不丢失。。。。如果你没有一种机制去管理这些对象，将会是灾难，如果这个对象不再使用了，它还保留着。。。。越来越多的对象产生，就好像安卓系统那样系统越来越慢最后PLC系统奔溃。。。。。

在我眼里，FB是好东西，但是不要上瘾，还是好好地写好LD程序，这是最接近硬件的语言。

或者以后架构将会是PC与PLC共存，PLC上传数据让PC去处理数据，PC再返回数据给PLC执行现场控制，如果让PLC来引入那么多对象，已经脱离了PLC初心！

这只是我个人想法，欢迎大家讨论下新的编程思想。

       安卓系统慢 跟你说的FB背景数据块越来越多有关系吗，安卓主要是后台不停的重生，APP无法真正关闭，而这些都是不正规APP开发导致的。pcs7几千个背景数据块运行周期也就10几ms，PLC会硬件老化，没听说过还能产生垃圾的。一套S5系统运行10几年到现在的很多，没见人家说PLC运行久了奔溃了。

你看了第四版本吗？加入静态和动态特性。。。。。

我意思是都中断处理程序，都处理完了，这里面生成的对象了还要一直保留着数据，系统大的话你就知道臃肿了。

越来越多的对象产生，就好像安卓系统那样系统越来越慢最后PLC系统奔溃。。。。。

PLC 你不下载程序，难道会自动生产FB,背景DB？还越来越慢？没有这说法。

还是好好地写好LD程序，这是最接近硬件的语言?
就拿西门子的S7-1500 来说，LAD/FBD,SCL 都是地位平等的语言，没有什么更接近硬件一说！STL由于 1500硬件限制，可以离硬件远了那么一点。

PC 技术在发展PLC 也是 ，以后PLC的在数据处理，通信等方面会更强大，

现在 流行的.NET平台下的编程，托管代码的一个重要功能是 垃圾回收，程序不再使用某些内存时，就会释放这些内存。

西门子编程也是遵循PLC Open IEC61131-3的

调用FB生成的对象 有哪些？无非是它的背景数据块内容需要保存在内存中，以及调用过程中所使用的局域堆栈，这些 内存什么时候释放和托管代码一样是由 CPU操作系统来完成的。至于 怎么释放，什么时候释放，无需我这个程序员操来关心了，那是研发人员的事情了。设计PLC系统时，只需要保证我的代码内存和数据内存满足我项目需求就行。

我还没见过，在任何一款西门子的的CPU中，由于 不断调用FB，造成工作内存不断地缩小，CPU扫描不断变慢的情况。

FC是一个函数没错。

也可以理解为一个对象，例如电机模块。可以重复调用赋值。

FB是一个带有背景数据块的函数，可以多个FB共同使用一个背景DB西门子叫多重背景。

我的理解是每次调用FB就要分配一个背景DB，你的意思是说调用的数量庞大以后会生产很多的背景DB？从而引起的内存占用？我觉得如果是这样，放在目前就已经不是问题了，1200/1500PLC的内存分分钟秒杀10年前的300/400PLC了，有足够的内存给你使用。如果你的FB能够把一个中大型的PLC填满了就厉害了，并且项目一旦调试完成投入运行以后基本上是多少内存就多少内存了，不会自己产生垃圾占用内存，不过倒是经常使用PC/PG进行程序下载修改下载等等会引起内存波动，需要适当的进行在线压缩一下。

plc的指令相对c、c++这种pc上的高级语言来说，就很简单了。

再加上plc特殊的运行机制，所以pc上常见的内存泄漏、回收这种问题对于plc是不存在的。

plc的离线程序编好，实际就能确定占用多大的内存空间了。

总之，楼主想多了

有得必有失，大家诟病PLC系统相对封闭（与PC_based的开放式相比）时，却忽略了这其实是PLC稳定性坚如磐石的原因之一。西门子为代表的传统PLC厂家和倍福为代表的PC_based厂家大家都在进步，底层的工作机制和原理就不是我们能够操心的了。

以前做过某汽车厂老PLC维护，系统经过N次改造，程序量越来越大，但是程序正常运行也没有问题，倒是调试次数多了，导致内存占用，需要压缩整理之后才能下载程序，所以正常运行不会导致内存越来越小，从这个角度来说PLC操作系统及内存调用机制是很强大的，正常运行20年依旧强悍。

威师爷说的还是很正确的。

至于PLC与PC的控制架构，那个老厂系统就是PC处理大量数据，PLC基本只是执行，一旦PC故障，整个生产都要停顿，后来新建系统架构都改成了生产线控制功能逻辑全部由PLC来执行，PC只负责生产数据采集和交互，运行相当稳定，以后更多的也会是这样，PC与PLC各司其职。