注释
这一直是一个问题/错误,文件越大,某些文件导致 UGS 锁定的情况就越糟糕。我不认为进度指示器会有帮助,因为根本原因似乎在于文件处理本身。 系统速度似乎并不重要,因为具有 8 GB(很快将达到 16 GB)的四核 AMD 具有相当精简和干净的操作系统(win 7 pro 但经过调整)仍然会遇到这些问题。 此外,当您运行大文件时,UGS 上的控件通常不会在运行时响应,因此更好地中断按钮也需要成为同一问题的一部分。 |
这里有一些问题可能会影响您的体验@BallscrewBob你可能是对的,这只会显示问题的症状。例如,#1197表明我们将打开的流加载并保存到文件中多次。 我在加载文件时添加了额外的日志消息,这似乎是打开文件时的 4 次。
启动文件流时,状态面板似乎多次打开文件:
@winder我在想创建一个稍后可以流式传输的预处理文件的想法是个好主意。但是无论如何,我们将几乎所有数据加载到 Visualizer 的内存中。 我想知道我们是否应该尝试重写文件加载机制,一次将整个文件读入内存,然后创建从内存而不是文件流读取的 gcodestreamer? |
从我的角度来看,这是一个非常好的主意。 只是为了添加一些辅助信息,该文件经常被任何人检查,我的意思是任何防病毒软件。 二是改进加载系统的想法。 |
@breiler我认为清理文件加载是个好主意,但我不确定它会如何导致事件延迟。也许其中 |
我们在 2Gb ram 的 WIndows 10 mini PC 上加载超过 1,000,000 行长的文件。我们的技巧是打开“发送进度”窗口并等待“文件中的行”填充,然后单击播放。我们通常会关闭可视化工具窗口,但如果您不这样做,请注意刀具路径图形将在文件显示在“发送进度”窗口中很久之前加载。我们的计算机等待一百万行以上的文件可能需要几分钟,但它始终会加载。 另一方面,事实证明,更改某些窗口可以解决大文件的一些冻结问题。
不确定这是否有帮助,但它似乎对我们有用。在这些长时间运行期间,UGS 命令似乎不可用,但我们的硬连线“暂停”和“恢复”按钮有效。 只是为了补充信息。我们的文件以每分钟 200 到 300 英寸的速度切割,大多数时候 Z 会减慢速度。这些文件需要 5 到 9 个小时才能运行。 |
虽然这些步骤确实有助于解决问题,但 当使用覆盖将作业速度提高到 MAX 时,这里的速度和进给可能会导致一些轻微的滞后,而降低到较慢的进给似乎不会造成问题,而且似乎确实有帮助。 此外,在这些锁定或停顿期间,UNLOCK 和 SOFT RESET 可能变得不可用。 |
我从我们的测试中了解到,在以“快速”进给速率运行的大文件中,会导致 GUI 和串行通信之间出现滞后。因此 GUI 不是实时的。它落后了。当我们完成一个大文件(主轴返回原位,项目完成)时,UGS 屏幕仍有 30% 到 50% 的行需要处理。实际上,我让它继续运行了几次,它最终完成并返回了 GUI。这适用于 16Gb 双处理器或 2Gb 微型计算机。 使用我们的正常生产文件(小而多的直线),GUI 保持同步。 |
无论是光栅还是基于曲线的矢量,我都可以获得相同的锁定。 过去几天的测试似乎表明控制台可能是大部分问题的幕后黑手。 |
跟进… 接下来是在没有 DRO 显示器的情况下运行相同的作业,因为我可以清楚地看到那里也有一些问题,因为它断断续续。 令人高兴的是,STOP / PAUSE 命令现在似乎可以更快地工作,而无需在出现错误框之前进行长时间的停顿。 |
更新 |
问题描述
加载程序时,可能会快速单击发送并出现此错误。我通过在一台非常慢的计算机(2010 年的上网本,1.6 GHz Intel Atom N270 处理器,1 GB RAM)上运行一个相当大的程序(80k 行)注意到了这一点
发送按钮起作用之前可能需要 10 多秒。
据推测这是因为文件在加载时被处理并序列化为文件,直到该过程完成发送才有问题。
预期行为
更好的错误消息或进度指示器。