Plant使用体会，若有Expert请指摘

xyzwj

用的是Plant 7.5版本的，支持3D模块，刚刚完成一个较大的模型，现谈几点体会：
    优点：
      1.用Frame进行功能模块划分，建模结构清晰；
      2.SimTalk简单易用，功能强大，几乎可以用其完成所有的创建、设置、试验任务，但个别参数的修改存在问题，个人目前未找到代码实现方法，仍是手动去设，如：启用importer后的broker设置，如何用SimTalk去实现。需要说明一点，较大的模型只有用代码去做，手动很难完成。
      3.基本类库简易、基础，功能扩展性强；本人以前用过Flexsim，感觉定制对象的话，plant更为方便
      当然，还有其他很多的优点，不再一一赘述，下面将一下个人感觉不太理想的几个地方：
! L6 q, u0 b7 ?; M% ^. \      1.仿真钟运行太慢，当然这种说法或许不正确，但反复调整后却还是这样的结果：如果事件极为密集，而且Mode设为Animate All，那么，模型运行的甚至比真实时间还要慢，很苦恼的地方！或许会说，改一下Mode，设为Fast Forward或者Step Forward怎么样？如果是Fast Forward那么3D环境里不会有Animation;Step Forward则与Animate All没有太大区别。当然了，电脑硬件限制也是一定的，毕竟不是专业的Simulation Workstation，这是下一个要谈的问题。
; ]& a0 [( b) j9 ]      2.Plant对线程的划分好像不够理想，不能充分利用双核的硬件，在Task Manager里可以很清楚的看到Tune.exe的利用率最多不过51%，好像只用了一个核，不能将大量的计算充分分摊到两个核上，当然,时钟已经丝毫no faster了。
      3.类修改与类对象修改，有时类的属性改变之后，相应对象的参数并未随之改变，这有3d控制参数，也有Dialog中需设置的参数，解决办法要么是“激活”一下，即换个值存一下再换回原值，或者只有Deleteobject后再重建。不知这是不是软件自身的bug
" C- W5 I( T0 g+ ~      4.3D视图控制，经常会在旋转视图时跳转到上一级，很无奈，好不容易调出的角度一下又成Z视图了。
1 w+ b# ]1 D) Q$ y2 A: q      5.2d与3D是两个独立的模块，它们是连接关系，3D的地位好像略低一点，2d控制3D很方便，反过来就不行了。
      6.3D视图有时还会意外丢失，更遭的是，如果你修改了Mus在模型里的对象硬要存回去，那会把文件毁掉，再也打不开了，当然这是操作不当，不能算是软件的问题。
2 N9 m* x' x  Z3 s: U& b8 g      还有一些问题，先讲这么多，若有expert偶然经过可指摘不当之处，这是本人目前的一点点小的实践。

苘苘

楼主的经验总结的非常好，对新人很有帮助，再次感谢您的无私分享

SimChen

9 B3 k9 ?$ r( H" h; `
9 Z4 Y7 b" x) \8 NPlant的计算速度相当快，只有专业的模型才会觉得速度不够，还有三维模型不在讨论范围，因为Plant的3D还不成熟。Plant是以事件触发的，没有事件或事件很少就走得快。这里可以给几个提示

在编程中如果有循环，当达成条件后用exitLoop就可以跳出循环，加快运送速度。
尽量避免写wait until语句，因为只要这个条件没有达成，以后所有进行的事件都要重新检验这个条件。用专业术语讲，这条语句是performance killer。
有些模块会严重影响运算速度，如Sankey，建议不用时不要激活它。

xyzwj

3# SimChen
, ~4 t6 U0 g6 S  N. L$ ]非常感谢，exitloop就不用说了，只是waituntil 是必不可少的，而且用waituntil时限制较多，所监视的变量基本只能是最简单的变量，而SimTalk中所支持数据类型虽然有诸如table,queue,stack等高级形式却不支持基础的数组类型，如此以来如果所要watch的变量较多那么只有一个个写出来了，也没有找到可以用SimTalk创建变量的方法，请expert给点对策才好

SimChen

理论上所有的Wait until都是可以避免的。程序的技巧是每当条件可能成立时，都要重新call这个程序进行检验。举个简单的例子，如果要buffer的贮量大于五才进行buffer中物件的筛选，那么可以在每个物件进入buffer时触发一个程序，仅在if条件成立时才做筛选。

另外在精密度要求不高的情况下，再介绍一个小技巧，用一个程序，每隔几秒执行if一次，要比wait until划算很多。
" A" {0 a5 Z; A+ u% C
还有忘了说了，Display也会严重影响运行速度。很多时候可以用全局变量代替，这个全局变量就可以用Wait until来检测。另外关于simtalk创建变量的问题，其实所有的局部变量都可以，甚至是table的形式。

jgc

个人观点：
, S4 c9 t2 _1 r8 `$ E2 ^6 v1，其一：simtalk的计算速度是非常快的，前提是不用的对象千万不能激活，否则机器卡死都有可能，其二：代码的编写基本不会影响到机器的运行，即使不停的使用waituntil影响也不大，即使是十W条代码，以现在电脑的运行速度可以忽略不计，在我所做的大模型中，不开3D，不会影响速度的。其三，切记，分层不能太多、同种对象最好能通用。比如说你mu有50种之多，然后在目录树中将这些对象分到第三层或更多层下面。而你的frame的根地址默认在最外层。这个时候你调用资源的时候寻地址那就相当的慢了，这是新人最容易犯的毛病，即使你的模型非常小，也会很慢，本人认为这是主因。其四：在调试的时候，把MU的显示关掉会快一些，当然这些只能起微调的作用，最重要的是第三点。
2.waituntil有些时候确实非常有效，实现起来非常容易，但在复杂模型中多处使用的时候容易出错，在大模型中本人也不常用。至于说理论上所有的waituntil都可以被替换，理论上确实如此，但实际应用过程中要想取代你需要付出昂贵的代价（大量的代码和变量以及复杂的逻辑纠葛）才能够实现，所以，我使用waituntil是看情况的
3.用simtalk好像不能创建全局变量，否则不会有variable这个对象了。局部变量的创建那就无所不能了。

xyzwj

7# jgc

& N! r2 b7 p3 }% g! x8 U9 z1.正如所说，waituntil确实可以完全避免的，其引入也正是为了避免拐弯抹角的逻辑但其对运行速度的影响有多大值得怀疑，最坏的情况下只要每个事件后加一个对它的检测即可，影响应该不大，因此，个人觉得没必要回避。
2.但要说嵌套层次不可过多就觉得比较可惜，因为一直认为这是Plant进行模块化的优势，可以构建极大极复杂的模型（个人也不喜欢一层层的嵌套）。而对于MU,可以是只用三种的，即系统有的三种。
3.对不用的对象不激活，否则甚至会卡死，这一点也同意，所谓激活即其制造了事件，密集的事件会严重降低速度，最简单的验证，放一个source,一个Drain,然后连接运行，看一下CPU是不是满的，或是50%以上（双核哈）。
( {$ G! z9 R9 ^' W- r$ ]     个人也用曾认为性能极优的Flexsim试验过，事件密集之后同样吃不消，所以，如果造了太多的事件先应考虑优化模型，减少事件。软件本身的因素较小，因为软件的设计理念是大同小异的，实在没有办法就只好搞一个超高配置的station任他跑了，当然，如果高版本软件对双核利用的充分同样会有好的效果。

gzjingong

这些应该是高水平应用才会遇到的问题了。楼主经验的总结和后续的讨论，对新人很有帮助，再次感谢无私分享