唉，E10的加工报表错误不断！(确认为BUG，等修复！)

只看该作者 · 发表于 2011-9-10 15:36:42

本帖最后由 taidaing 于 2011-9-13 18:10 编辑

年初用pre-beta版时，看到E10在加工报表上做了相当大的更新，很兴奋。立刻做好了相应的E10加工单，确实简化了定制加工报表上的70%以上的工作量，XLS可以做得相当简洁。可惜遗憾的是，当时测试版E10在抓图上只能抓到MODLE方向的图，自定义激活中的UCS方向会抓错。就放一边去了。

今天突然想到再试一下正式版的情况，抓图正常了，可是一个自定义变量老是出错，通过单步跟踪才发现，报表处理时直接从快速直线运动走完后，居然跳过了直线运动（我的自定义变量就在那里）到最后结束的段落去了，郁闷。又只有等BUG修复了。

E10P2下，32位和64位E10均测试出同样问题。

当然成绩还是要肯定的，在E10模式下，相同刀具合并、排序等在E9工作量大的东西，简化了太多。称赞一下。

只看该作者 · 发表于 2011-9-15 09:34:31

看看，学习学习

只看该作者 · 发表于 2011-9-13 18:09:12

经过仔细研究，发现E10报表也跟我方法一样（哈哈，抄袭我的？），在直线运动处定义了一个自定义变量，用以判断吃刀的最高点。
------------------------------------------------------------

现在此功能不可用，E10自带的这个变量也相当于作废！可见是个BUG，他们并不想跳过的。

呵呵，这下放心了，等修复BUG

只看该作者 · 发表于 2011-9-13 18:05:51

本帖最后由 totob 于 2011-9-13 18:06 编辑

不清楚呢。

只看该作者 · 发表于 2011-9-13 13:57:57

Okway 发表于 2011-9-13 11:08
用start point这个变量可以不。

GPP2哪来的start point变量？

不过查了下，有个程序开始点，但那是安全高度。算了，不想了。

只看该作者 · 发表于 2011-9-13 11:08:23

taidaing 发表于 2011-9-11 16:28
为何你说只支持32位E10？我看都正常吧？莫非你用了cimatonE的API编写了EXECL的VB代码？

E版缺一个相 ...

用start point这个变量可以不。

只看该作者 · 发表于 2011-9-12 13:35:14

准确的刀长不等于Z_UP－Z_MIN，这样的识别对工件的形状，加工的方式有要求，显然没有多大的参考意义，关于刀长、刃长、和夹头的同时输出，我建议用备注的形式，因为有时候，我们可能通过测量或预览长刀长得知需要的长度，这在CIM中是非常容易的，而且现在有后台计算，我们完全有时间去分析刀长、备注TP，我的程式单是在TP备注中输入 -15.29-5RC 这时程式单的刃长会显示为5，刀长为15(不再参考Z_MIN)，备注为29小夹头，我强烈推荐用类似的这种方法操作，效率高而且不会出错。靠全自动备注夹头、刃长等反而有些不方便。而且要求也较多。

只看该作者 · 发表于 2011-9-12 12:34:53

问题是beta版时都行啊！

看来只有靠Z_max的安全高度来算刀长了，可惜不准啊

只看该作者 · 发表于 2011-9-12 12:13:41

本帖最后由 enliang 于 2011-9-12 12:16 编辑

看了下报表。应该是故意限制了不处理刀位数据。以后的版本也应该也不会有。基本上还是能作出符合规范的报表

只看该作者 · 发表于 2011-9-11 22:49:59

一头污水现在在老家
回去弄看看我一直GPP2出来的程序和程序单
很少去搞个程序单

只看该作者 · 发表于 2011-9-11 21:57:08

本帖最后由 taidaing 于 2011-9-11 22:13 编辑

是啊，我当初自定义变量就是想避免这个情况。
我举的例子只有5mm，深度只有Z-20,极端的情况下：
安全高度Z20，工件最高点Z0，如果在工件某处有个凹下去的大平面，刀柄可以伸下去，如果这个凹下去平面是Z-50，需要在这个平面上用4mm的小刀加工一个10mm深的凹槽。

按我的算法也只有10mm的刀长（可以在报表上自动实现刀柄的直径及型号，正好配上刀具的夹持长度>10，很准确）
按安全高度来减的话，刀长就要60mm了

误差太大了

[原创] 唉，E10的加工报表错误不断！(确认为BUG，等修复！)

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源