您使用的是哪个版本的 UGS 平台？
您介意分享您正在运行的 GCode 文件吗？

水仙花粗加工 25 flat.nc.zip

这是每晚 3 月 15 日的版本（我知道一个有效，我有一个重要的剪辑要制作）

哇，这是一个相当大的工作！

UGS 在尝试加载时在我的笔记本电脑上崩溃了。关闭 Visualizer 会有所帮助，如果我要运行整个文件，我可能还需要关闭控制台。所以我猜这只是大文件的性能问题。

关于 GUI 锁定问题，如果允许我猜测的话，有几个问题可能已在 3 月 25 日的每晚构建前后得到解决。类似的问题#718和修复了几个问题的问题#759。

我没有时间尝试在旧版本中运行整个文件来重现问题。

认为这可能与大文件的问题相同……

美人鱼灰度 75×57 fine inverse.zip

没有崩溃的设定点。
它可以发生在 G-CODE 的任何地方。
可惜我不得不再次猜测起点，因为它无法记住它在哪里。如果我只进行粗剪，这不是什么大问题，但如果我进行精剪，那将是一个真正的痛苦。

“大文件”问题似乎确实是一个常见问题。
该程序只能从任务管理器关闭，即使某些按钮对鼠标保持响应，它们也不会响应应该发生的命令。

TM 没有报告任何问题，因为屏幕截图显示其运行正常，但同一会话的上方屏幕截图显示发生了灾难性故障。

@BallscrewBob感谢您的报告和文件。除了崩溃/挂起之外，UGS 似乎在可视化文件时也存在问题。虽然 81,000 行比我看到的大多数作业大得多，但我的理解是激光作业可以更大。我想知道除了可视化工具/控制台的已知“大文件”问题之外是否存在某种内存泄漏。

你能告诉我这些工作的预期运行时间吗？
你不止一次见过这种情况吗？
您大约在多少分钟/小时内看到这种情况？

如果你有时间，请为我运行几个测试。理想情况下，一次运行一个测试以查看哪些更改（如果有的话）有助于解决问题——当然我知道商店时间很宝贵（无论是业余爱好还是生产），所以如果您需要在一次让我知道。

1. 运行这样的大型程序时关闭可视化工具/控制台。

2. 更新到最新的每晚构建，@breiler今年做了一些稳定性改进，可以防止 UGS 进入不良的 UI 状态。

如果您没有时间运行这些测试中的任何一个，请继续并ugsplatform/etc/ugsplatform.conf通过更改-J-Xms64m为更大的东西来更新——比如您系统 RAM 的 50%（即，如果您有 4 GB 的 ram 使用-J-Xms2G。这是一种蛮力解决方案这应该可以在不修复错误的情况下缓解问题。

谢谢！

我有很多时间 威尔…
运行时间各不相同，但总是超过 2 小时。那一个大约是4.5小时。
我可以向您保证，顺便说一句，这与节电无关。

是的，在两个不同的工作中多次看到它。

所提到的挂起可能是几分钟 (>15) 到几个小时。
其中两次关闭了 Visualiser，但它确实有助于关闭它。

如果我执行“检查更新”，它会被报告为最新的。

将在下一个作业完成一个通道时一次一个地更改测试，然后在下一个通道再次进行。

旁注：- 我还为 Arduino CREATE 团队开发测试，所以我通常不会报告错误，直到我知道它是可重复的或有进一步调查的基础。
比其他许多人更喜欢您的计划，所以我宁愿帮助您，以便其他人也能受益。

当前系统在一个体面的规格 win7 pro 盒子上，但确实有一个 win10 盒子和一个服务器可用于其他测试（如果需要）。

使用“LaserGRBL”进行激光工作，因为它很容易完成我在这方面需要的工作类型。
两个 CNC 都是自制的，但非常可靠（开发中的第 3 个）

对 CONF 文件进行任何更改都会导致 UGS 无法正常启动……
要么它看起来可以正常工作然后退出，要么只是非常快速地闪烁并退出。
直接来自您的帖子的 CP，只要我放回“-J-Xms64m”，它就会正常启动。

刚刚完全通过了我附加的程序，没有错误。
这是我第一次不必使用其他程序来完成剪辑。Visualiser 已关闭，那时我也关闭了控制台。
您对可视化器和/或控制台的断言是正确的！看起来对于大文件，它们都有你所说的泄漏或其他问题。

尝试了几种不同的方式来实现该 mod BTW。它确实在 meg 范围内工作。设法让 128m 坚持下去。

刚刚有另一个失败更新此链接现在是崩溃的 DUMP 文件
https://1drv.ms/u/s!AqSzk5so2vXinQP7KUssAs0T5d1Z

正如您将看到的那样，当时没有打开控制台或可视化工具，并且程序在大约 7 分钟内失败（迄今为止最短的失败）

更新 –
自从更改为 128m 以来，程序变得更加稳定……
其他几个小问题显示有时整个程序对命令的响应变得非常缓慢，但至少它确实响应。
Visualiser 和控制台仍然关闭（保持其 100% 工作的唯一方法）
加载大小超过 4 Mb 的 CNC 文件似乎很慢，在文件完全加载之前会弹出 NULL 错误。
除非您已经知道这些消息，否则下次会尝试拍摄照片吗？

将在完成下一个作业时尝试更新内存编号。

管理到一个转储文件，但它对于 GIT 来说太大了，所以这里是一个外部源的链接

https://1drv.ms/u/s!AqSzk5so2vXinQIgnfoGa6q0fQ1Z

它相当大，但希望包含一些关于问题所在的线索。
即使没有打开可视化工具和控制台，程序也变得越来越慢。
在我截取屏幕截图之前，JAVA 警告不断出现和消失，如果我确实设法点击了一个，它只会让 UGS 缓慢恢复。这是根据您之前的建议设置的 512m。

可以肯定地说，它与控制台可视化器没有直接关系，但它们确实加快了问题的速度。

你好@BallscrewBob
我也在尝试处理大文件。
我构建了自己的 DIY 木路由器并将其与 Arduino GRBL v1.1f 一起使用。

起初，我遇到了更多问题。最终，我设法完成了包含 355080 行的粗糙表面的附加 gcode。大约用了3个半小时。
我遇到的第一个错误与 G2/G3 arc 命令有关。我设法通过从设置中启用 arc expander 来解决它。工具>选项>UGS>控制器选项>Arc Expander。它将 G2/G3 命令转换为直线运动 (G1)。

我的第二个问题是，在雕刻过程中，电脑突然死机，机器停止，没有给出任何错误。阅读您上面的评论后，我关闭了可视化工具和控制台。它奏效了。但这次我遇到了另一个问题。等木雕结束，主轴回到起始位置。我检查的时候，距离原来的起点有3-4毫米。当我意识到这一点时，我将机器放回原处并上传第二个 gcode 文件以进行整理。这是一个小文件，大约需要 20 分钟。然而，它开始在距离它应该开始的地方 5-6 毫米处完成表面，所以我停止了 UGS。

我不确定问题的根本原因是UGS还是我DIY的机器。
我认为大文件问题也与计算机处理器速度和 arduino 性能有关。

为了能够找到确切的问题，我将在周末用另一个软件尝试相同的 gcode。如果有效，则意味着问题出在 UGS 上。如果我遇到同样的问题，我可能会
考虑使用更快的计算机和原始的 arduino。我会和你分享我的经验。

gcode文件.zip

@BallscrewBob感谢所有这些线索，它们将在我下次调试这些性能/内存问题时提供很大帮助

不客气，威尔…如果我发现任何明确的内容，我会将其放在本节中。
希望上面附带的故障转储足以用大文件填补这个漏洞。

看起来它可能从头开始读取文件，而它已经进入了很长的路要走，导致速度减慢，可能是缓冲区问题？

该问题的副作用是屏幕按钮可以工作，但程序不反映更改。例如，如果您通过超驰更改进给率，那么机器会响应但屏幕不会更新，因此您无法判断（除非您计算鼠标点击次数）新的进给率百分比是多少。

PS 像这样的时刻，LINE 计数器和“从 xxx 行重新启动”一起有用，我可以从设定点重新启动程序，看看问题是否仍然存在。

好像就在提示中……这是一段 UGS 准备失败的视频，显示半按钮和 DRO 更新速度减慢到断断续续

ugs 准备失败 2018-07-03 at 07-58-21.zip

忘记我上面的评论。我遇到的最后一个问题是因为 x 轴联轴器上的螺栓松动。我刚刚注意到了。

你对这个大的工作问题有进一步的了解吗？
新路由器刚到，我期待着完成一些实际工作，但如果我从程序中停止工作，慢跑选项就会变灰。

这应该在最新的每晚构建中得到解决。