以前在做一个项目时用了许多FB功能块，而且把相匹配的上位机软件监管数据信息放到了IN-OUT插口，結果运作时发觉CPU扫描仪周期时间非常大，贴近100ms，操纵十分费劲。之后发觉是由于在FB的IN-OUT插口应用了UDT种类数据信息的原因，由于在IN-OUT插口应用UDT后FB的环境数据信息块就只储存浏览表针，运作时选用表针的方法立即浏览插口实参，在FB中每引入一次IN-OUT插口的UDT种类自变量原素，程序流程的工作中储存器占有就会有40多字节数，而一般自变量只占有不上10字节数。最终没法把全部IN-OUT插口的UDT分拆到IN和OUT插口，工作中储存器立刻就降下去了，扫描仪周期时间减少了许多，见下面的图较为。这个问题以前也发贴探讨过。

自打发觉所述问题后，我一直害怕再把UDT种类的上台插口放进IN-OUT区了，可是也提供了一些不便，例如有的过程中必须程序流程分辨上台键入是不是有效，假如不科学就根据程序流程改正，假如上台插口在IN区就没法在FB内取值改正。为了更好地完全弄清楚这个问题，我之前干了一个检测较为，方式便是建立一个UDT基本数据类型，包含8个BOOL，2个INT和2个REAL，随后在FB中写三行程序流程，各自读取三种自变量。根据把UDT放进IN插口和IN-OUT接口较为FB占有的运载储存区和工作中储存区的尺寸差别，还根据提升BOOL和INT自变量读取较为每提升一次读取占有的运载储存区和工作中储存区的尺寸差别。程序流程如下所示

STEP7APP选用5.5SP4，组态软件CPU为315-2PN/DP V3.2，较为結果如下所示：

从以上较为可以发觉，在IN插口应用UDT时，每提升一次插口原素读取工作中储存器只提升8或10字节数（因指令和数据种类不一样而不同）；而在IN-OUT插口UDT时，每提升一次插口原素读取工作中储存器提升了46或48字节数（因指令和数据种类不一样而不同），每一次读取比IN插口时多了38字节数，与此同时运载储存器提升的大量。因此得到的结果是在STEP7服务平台下最好不要在IN-OUT插口应用UDT算法设计，假如要应用我近期改善的作法是先把插口数据库同步到FB內部自变量，在程序流程读取时应用內部自变量取代，只在程序流程反写插口自变量时才应用插口自变量，最大限度降低在FB程序流程内读取插口自变量。

现阶段STEP7服务平台应用越来越低了，绝大多数程序流程都能够用博图来写，那麼在博图自然环境下是不是有一样的问题呢？我将以上测试标准在博图V15自然环境下拷贝了一遍，一样组态软件315-2PN/DP 的CPU，結果如下所示；

根据与STEP7服务平台较为发觉結果类似，每提升一次读取提升的工作中储存器尺寸是一样的，换句话说针对300系列产品CPU而言，应用STEP7和博图程序编写都是有这个问题，那麼情绪调节也是一样的，尽量避免读取次数，由于工作中储存器是不能寻址的，读取多了还危害扫描仪周期时间。

最终我又在博图V15上组态软件1500系列产品CPU干了一次较为，結果如下所示：

根据较为結果可以发觉二者早已没什么差别了，乃至在IN-OUT区应用时储存器占有还少了一点，表明在1500plc上早已沒有这个问题，可以安心大但的去运用了。原先由于300的前车之鉴我还在1500下也害怕在IN-OUT区应用UDT数据信息，下一步就打算把现阶段的程序流程块移殖到1500上提升一下检测具体結果。

上一篇：博途V15安装注意事项

下一篇：西门子1200PLC的基础通信知识锦囊