老师好，
遇到一个问题，在搭建的多层级gh算法里，后面层级的算法模块用到了最初始层级交互点参与计算，在测试参数过程中，发现会出错。
比如换个参数，计算结果不正常。用recompute重算也是如此。
我试过出错后，断开，再重新连接上面会报错的参数，这时不会出错，计算结果正常。
或者，要单独enable一下出错模块，才会计算正常结果。
根据上述症状，我判断是多层模块同时计算导致的，
后面的模块结果还没出来，初始数据已经介入提前计算，导致数据不正常。
想请教老师，有没有能让某个电池不要那么快计算？比如延迟10秒再触发生效的方法？
谢谢了！
请至少提供一张截图，这样绕来绕去的文字实在是太难理解 
可以画一个简单的示意图
老师，补充了一张草图，看看行吗？
如果你的结构是这样的
那么1计算完毕，234和6收到新的数据输入，会触发2346的计算
此时6因为还没拿到5的数据，所以6不会输出正确的结果
234拿到需要的所有数据，计算完毕，输出给5
5也拿到了需要的所有数据，输出给6和7
此时6第二次拿到了更新数据，来自于5的正确数据，因此6输出了正确的结果
所以GH的逻辑是每次电池的任何一个输入端数据更新了，整个电池重新计算
按照这个逻辑，6除了一开始会有那么一瞬间计算错误，之后会返回正确的数据。
所以没有必要设计延时系统
老师，确实如您所说的过程。
上述只是简化图，一个框不是单一电池，可能是打包了好多层级的cluster。
但6号经常产生不完整的结果，
主要是里面这个brep / plane，我要获得多条圆管截线，并标注尺寸，
1号是4个点，
正常结果是产生4条线，4个周长。
但一换参数，就会出现5个数据，或6个数据，我查看了下，本应一条线的有些分成了两截；
本来比如是：
98
65
42
37cm
结果会显示（随机的，不知道哪条线会计算不充分）
76
17
42
37
断线重连，或enable一下又正常了。
因此，我推测是同步计算导致的。
您看这个动图，
白色顺序第三个数据，改变参数之后所有数据应该变大，它则变小了，enable之后再disable则又正常了。（还特意等了一下，前面几个打包的里面可能有几百个电池在运算 ）
问题可能出在你的程序和GH里面各种第三方插件上。
尽量删除第三方插件。
简化程序，不要做太多没有必要的打包。
里面有shapemap，其他都是gh自带电池了。
如果没有延迟方案，估计是cluster导致的内存占用问题。。。
之前也出现过打包的shapemap不自动更新，要手动进去cluster再出来就好了。问过dixson老师，好像和内存占用有关。
能不用cluster就不用。cluster我个人从来不用。
好的，谢谢耐心解答 
延迟计算有个 data dam 右键可以设置延时时间、。
