1） 西门子的背景数据块不能动态，就算强行动态也需要建立一个模板db，于是产生了一个限制：只能在组态时修改一个功能块所能储存的对象数量。

你有动态生成对象的需求吗？比如工艺轴，你能通过用户程序层面动态生成吗？你有的不都是你事先定义或组态的吗？

2）在一个工程内自然是去确定的，换一个工程硬件数量有可能成倍增加，甚至有可能超过你上一个工程预设的最大数量，于是你这个块需要重新增加背景数据块的寄存器数量。

难道你不需要增加吗？不管你通过什么形式。你的描述好像是几个人同时穿一条裤子，合适吗？

3）如果逻辑简单的还好，如果逻辑复杂的则会很难。

都模块化了，块内的逻辑复杂与块的调用有啥关系呢？那你指的到底是块内逻辑复杂呢还是块间相互关系的逻辑复杂呢？块间逻辑关系，块本身能管到吗？是不是应该有更高层面的逻辑程序来处理呀？

3）针对这些，我就建议将每一个对象拆分出来做成一个单独的块，再根据每个工程的不同来调用适合的数量的势力，然后通过一个统一的inout接口来协调他们之间的逻辑关系。

对象是否单独拆分成一个单独的块，这应该根据编控制功能的需求以及架构的需求吧？一般来说，每一个不同的控制对象应该都是有一个独立的功能块与之对应的吧？我没想出来，一个阀的控制块与一个变频电机的控制块可以使用一个通用的功能块，无非就是最笨的办法，二合一，要做多合一吗？

既然能通过一个INOUT接口来协调他们之间的逻辑关系，那么这些逻辑关系是不是已经事先定义好了，INOUT接口传递的数据，充其量是让功能块可以选择执行不同的逻辑罢了，能通过用户程序层面定义新的逻辑关系吗

4）inout接口不是说要链接一个统一的fb来处理他们之间的关系，而是链接一个相同的数组array 0..1 int，而不需要其他fb来协调这些调用实例的逻辑关系。

不清楚你说的逻辑关系究竟是一些什么样的逻辑关系？逻辑关系这四个字太复杂了，简单点说排队还能理解。排队嘛，可以有管理员，也可以没有管理员，你这是让每个排队的人都带一个管理员吗？愿闻其详