Solid Edge ST3, 我的第一印象 (part 1)

liujunyun

来源：它山的石头

原文 by Paul hamilton
翻译 by 咋不乐

下一篇：Solid Edge ST3, 我的第一印象 (part 2)

看起来SolidEdge ST3拥有了很多新的建模新功能。我并不是一个SolidEdge的用户，或许我的“第一印象“并不一定都是有关新功能的解读。各位看官和专家有最终发言权。实际上我最感兴趣的是他们如何处理同步建模和SolidEdge模型树的。

我是尝试着利用工作流来评估这门技术的。或许大家都知道我本人对于直接建模技术有所偏好。当然我非常明白模型树和父子关系在参数建模里的价值，还有参数关联性带来的价值。但是我看到了很多时候设计者被这种建模方式绑定了。参数建模不好的地方往往被他带来的好处遮掩了。而参数建模不好的地方往往是驱动了直接建模的发展。这些“不好的地方“具体包括：

1、工具复杂和培训需求
2、在建模前需要规划
3、数据交互性
4、重用数据树（基于历史的模型）
5、重生模型的冲突
6、建模的标准及最佳方案

再重申一次，我明白参数建模带来的好处，但是以上列出的几点使得有时候工作不能及时完成。因此这些缺点驱动了直接建模的发展，但是直接建模技术依然还有未解决的问题。但上述问题并不存在于成熟强劲的直接建模工具。

所以我要问的问题是：Solid Edge ST3对上述问题又是如何回应呢？让我们来逐一看看吧。

工具复杂和培训需求：我认为SE变得越来越难学习。即使你从未用过同步建模，或者是从未用传统的结构化ordered（官方翻译为顺序）建模（此处的Ordered在SE里面特指参数化的结构树），仅仅把这些按钮(同步建模指令)摆在菜单上就已经把它弄得够复杂了。可以预见到培训教材会变得越来越厚。虽然看起来操作变得很直观，但往深处想，对于一个用户来说何时，如何，为啥要将一个特征从Ordered列移到Synchronous列中。

在建模前需要规划：假如系统在记录建模过程信息的话（模型特征），无论你是使用基于非历史模式的建模还是基于历史模式的建模，你就需要提前规划并注意每个步骤。因为每一个规划的细节都会影响到后面的建模及重用。在同步建模的模式下，所看到的模型树可能和后面的重用并没有多大关系，但是在特征下收集到的面集合还是有用的。SE ST3是不是个好的概念设计的工具呢？很多时候，同步建模模式下的概念设计总是留下一堆杂乱无章和无用的历史模型树。这也会往往会造成进入详细设计的时候，很多模型要重建。SE ST3解决了这个问题？

数据交互性：我们都认为模型树是很有必要的，不同参数建模系统之间交互模型树信息是不太可能的，但几何模型本身倒是可以相互传递。这时候假如拥有强健的直接建模功能的话，我们就可以随性地修改任何几何模型。这里我唯一想弄明白的问题是：看上去SE ST3在这方面并没有改善其“鲁棒性”来处理复杂模型的修改。虽然我并没有多次尝试NX和SE中的同步建模，但同步建模并没有让我觉得其拥有强健的修改复杂模型的功能。不管咋说，系统应该不断加强直接建模的功能。我没有看到“显著的证据”来证明SE在这块的改进。当然我有可能是错的，但眼见为实吧。

重用数据树（基于历史的模型）：谈到重用自己或别人留下的若干月/年前的历史数据，总会有些问题。在用好这些数据之前，你必须花时间去分析模型树的结构。但看起来ST3的模型树结构变得越来越复杂了。当然我知道，你没有必要在一个模型中使用两种模式，但问题是你能够控制其他人吗？

重生模型的冲突：我猜想，在ST3里，假如你的模型树发生冲突或崩溃了的话，你很可能会将这些特征拖到同步建模的模型树下。这样的话，问题就会被解决了，对不对？问题是其他的参照关系及父子关系该咋办呢？这些在ST3中该怎样解决呢？

建模的标准及最佳方案：我曾经看到过一大叠厚厚的关于最佳建模实践的文档。这些文档往往都是些大企业用来培训员工并且保证这些员工能够创建的参数式模型有一致性，这样的话今后被其他人重用的话就变得简单些。但是引入ST3的话，恐怕这一大叠的文件会越来越厚。我仿佛看到了越来越多的最佳实践滚滚而来。

Solid Edge的演化也是经历了漫长的年月。SE ST3的在线视频演示看上去棒极了（这是必须的）。我非常赞赏ST3的产品经理和开发人员做出的创新。他们的确引入了非常有趣的概念和方法。同时也迫不及待希望看到其发展。但到现在为止我并不认为他们拥有了所谓的“两个世界的解决方案（指的是参数建模和直接建模）”，就像很多blogger撰文认为的那样。不好意思，我还是有点怀疑。所以这篇博文并不是其中之一。
—————————————————————————–

liujunyun

liujunyun

大有茗堂