总时间指标绝对是最有用的，因为我目前记录了 40W 的电子管使用时间，因此我知道何时需要开始节省以备更换。

我想象 GCODE 可以被解析为线段，并且每个F变化都会总结以前的路径并除以该毫米/分钟。

不利的一面是，这将是一大堆Math.sqrt电话，我怀疑像 Raspberry Pi 这样的东西可能会崩溃。

只是有一个虽然。选择Shoe Laser是画布上下文。您可以计算所有绿色像素，然后应用 dpi 的平均进给率。会更快，并且可能足够准确以用于估计时间。

我在服务器端已经有了“一些”工作指标：

Job started at Fri Feb 24 2017 18:24:26 GMT+0100 (Mitteleuropäische Zeit)
Job finished at Fri Feb 24 2017 18:30:27 GMT+0100 (Mitteleuropäische Zeit)
Elapsed time: 361 seconds.
Ave. Speed: 333 lines/s

应该可以在服务器端保存一个使用摘要，让客户端查询。

@cojarbi在 LW3 中，我们在哪里可以得到工作持续时间的估计时间（预览）？我只看到距离估计。

• 估计作业将用完 gcode 的时间并不容易（尤其是在使用提要覆盖时）。
• 经过的时间/总时间不是问题，我可以补充一下。
• 对于当前通过/总通过，我只能猜测 z 轴的变化是新的通过，但这不是一个明确的迹象。看到z位置还不够吗？

我们在 LW2 中有它——但是通过对解析器进行大量重构以提高其性能，它停止了工作。一些代码仍然存在。

https://github.com/LaserWeb/LaserWeb3/blob/master/public/lib/gcode-viewer/gcode-parser.js#L756-L774

https://github.com/LaserWeb/LaserWeb3/blob/master/public/lib/gcode-viewer/gcode-parser.js#L788-L790

https://github.com/LaserWeb/LaserWeb3/blob/master/public/lib/gcode-viewer/gcode-parser.js#L773实际上非常准确（；

LW4 的 gcode 预览使用滑块的无加速近似。

LW3 的工作统计数据回来了：

我对持续时间估计有一个想法，至少在作业运行时是这样。
我可以计算一段时间内（如 5 秒）处理了多少队列行并计算剩余持续时间（预计到达时间：类似于 Windows 的文件传输对话框）。

是的，可以跳来跳去，但人们已经习惯了 Windows

多谢你们。如果我没记错的话，通过计数将与激光二极管更相关，目前，如果我没有弄错，启用 Z 阶段将在所有矢量上摩擦一次通过，然后更改 Z，那么这可能是一个触发器吗？

@cojarbi是的，这可能是一个触发器，但如果没有 Z 变化怎么办？大多数激光切割机没有 Z 级。
gcode 生成器可以在代码中放置一个命令来告诉我新的 pass 何时开始？并且可能在开始时，期望有多少传球？

我们现在有一个 Z 阶段启用按钮，我们需要选择通过次数，所以如果通过次数 > 1 则开始计数？？

我不会为此使用 Z 移动，因为这不适用于铣削。当新的 pass 开始时，向 gcode 添加注释行应该很容易。
@tbfleming@lautr3k 你怎么看？

https://github.com/hudbrog/gCodeViewer 有一个我们可以使用的 worker (CC-A-4.0)

我们可以在 gcode 生成中添加特殊注释来标记每个操作并标记每个 pass。发件人可以在击中每一个时进行报告。

@tbfleming我喜欢这个主意
“#: Pass 1”？

评论是; blah或(blah)：http ://linuxcnc.org/docs/html/gcode/overview.html#gcode:comments

或许; Operation: 3/4 Pass: 7/9

我更喜欢从 0 开始计数；单操作单遍文件将只有一个标记：; Operation: 0/1 Pass: 0/1

哎呀，我的错（乱七八糟的评论标记。）

好吧。将检查 gcode 时间估计:)

@cprezzi昨天注意到，如果最后一个操作很长（在我的例子中是一个矩形，需要大约 2 分钟来切割），完成时间是在操作发送到机器时输出的，而不是在它完成时输出的。你能做些什么吗？

@openhardwarecozaLW3 解析器所做的不仅仅是估计时间，也许更精简的单一用途代码，如https://github.com/cncjs/gcode-parser可能会有所帮助

同意，只是给历史上 gcode.ws 已经适合的地方的教训（：

临时解析器做的不多；希望替代的永久解析器也不会做很多事情。

@jonbev目前，当控制器接受最后一行时，作业“完成”。此时，控制器规划器队列仍有一些命令要执行（Grbl 最多 16 个，Smoothie 最多 32 个）。不幸的是，在执行命令后，控制器没有任何事件。

可能会等到一段时间内没有检测到任何移动，但这只是猜测。

我看到两件有趣的事情。首先是 CAM 选项卡中的估计持续时间，其次是 JOG 中的作业进度。
我可以显示 % queue position 的进度条，而不是在 DRO 上方显示队列长度。

顺便说一句：MACHINE 或 OPERATE 不是比 JOG 更好的名字吗？

@tbfleming请查看https://github.com/cncjs/gcode-toolpath似乎是关于解析的质量代码。
顺便说一句，tmpParser 缺少什么？我在https://github.com/cncjs/cncjs/blob/master/src/web/widgets/Visualizer/GCodeVisualizer.js上看到了 G2/G3 的一个很好的实现

看起来他们犯了一个根本错误：他们将 G 数字视为字符串。例如，它将错误处理与“G0”相同的“G0.0”。我怀疑任何凸轮都会生成“G0.0”，但那种错误让我感到不安。

临时解析器仅支持光栅化器和路径凸轮生成的微小 gcode 子集。它缺少 G2/G3、英寸模式、固定循环、工作坐标系（将是图形显示的主要 PITA），可能还有更多。

这是它接受 G0 但不接受 G0.0 的地方：https ://github.com/cncjs/gcode-toolpath/blob/master/src/index.js#L41

什么是好的计时算法？
我不是要复制 18 steps planner@chamnit，只能得到一个不错的球场（改进@openhardwarecoza的因素1.32 ?), 而不会混淆。

对于每一行：

• 计算每个轴运动的时间

  1. 计算进入加速时间（使用进入速度），然后计算它的距离（使用平均速度）
  2. 计算F处剩余距离的时间
  3. 计算退出加速时间（选择实际速度）。应用一个大概的交汇点时间因素。

• 累加所有移动轴的最长时间

• 最新命令应计算最新行。

..任何人…？

您已经进入了对特定固件进行疯狂猜测的领域。了解哪些技术产生合理近似值的唯一方法是运行大量实验，涵盖广泛的 gcode 文件以及广泛的固件设置。

?我确实计划将函数命名为guesstimate。
包括一个巨大的球场，准确度应该足以判断工作是大约 1 小时还是 2 小时等。即使使用 3d 打印机，85% 的准确度也足够了。
你看到算法中有什么可怕的错误了吗？不说联合因素…

我没有看到任何明显的东西，但我不确定你的步骤是什么意思。

LaserWeb2 代码的有趣使用：http://dangerousprototypes.com/store/lasercut我
从某人那里得到了这个链接，他问我是否可以为他的网站做类似的事情。