这是 JSON 格式的未解析输出，但值直接来自 stderr 输出：

{ block: 0, time: 0.000033, x: 1, y: 0, z: 0 }
{ block: 0, time: 1.000031999999306, x: 76, y: 0, z: 0 }
{ block: 0, time: 2.000030999997783, x: 152, y: 0, z: 0 }
{ block: 0, time: 3.000030000002988, x: 228, y: 0, z: 0 }
{ block: 0, time: 3.286833000004481, x: 250, y: 0, z: 0 }

我不熟悉 grbl sim 的设置方式，但如果它是
grbl 到模拟器的直接端口，那么可能会加速/减速（加速）可能会导致
执行该移动所需的额外时间。如果您将
加速设置调得更高，这些时间会减少吗？

-爱德华

2013 年 12 月 20 日星期五晚上 9:37，ruswerner notifications@github.com写道：

这是 JSON 格式的未解析输出，但值直接
来自 stderr 输出：

{块：0，时间：0.000033，x：1，y：0，z：0}
{块：0，时间：1.000031999999306，x：76，y：0，z：0}
{块：0，时间：2.000030999997783 ，x：152，y：0，z：0}
{块：0，时间：3.000030000002988，x：228，y：0，z：0}
{块：0，时间：3.286833000004481，x：250，y：0 , z: 0 }

—
直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/306 #issuecomment-31055899
。

我不知道自上次使用以来 grblsim 是如何演变的，但 sim_time 应该是自模拟开始以来的模拟时间。两个步骤之间的时间差是从一个调用到步进中断到下一个的时间。
所以@shapeoko是对的：您看到的时间差是加速和减速移动所需的额外时间。除非您将最大允许加速度设置为无穷大，否则您永远不会得到 sim_time（和现实世界的程序运行时间）的移动长度除以进给率。

多谢你们。我将用我的 shapeoko 和 sim 进行更多测试以比较输出。我正在使用 sim 来渲染预览，如果还知道在机器上运行该作业需要多长时间，那就太好了。我会尽快报告更多信息。
干杯!

@jgeisler0303

好的。我刚刚使用 Grbl 0.8c 在我的股票 Shapeoko v1 上运行了一个简单的工作。以下是我的 Arduino 上的相关设置：

$0=87.480
$1=87.480
$2=640.000
$3=30 (step pulse, usec)
$4=250.000 (default feed, mm/min)
$5=1000.000 (default seek, mm/min)
$6=160 (step port invert mask, int:10100000)
$7=25 (step idle delay, msec)
$8=25.000 (acceleration, mm/sec^2)
$9=0.050 (junction deviation, mm)
$10=0.100 (arc, mm/segment)
$11=25 (n-arc correction, int)
$12=3 (n-decimals, int)

以下是 grblsim（运行 0.9a）上的相关设置，我从 grbl 0.8c 映射了相同的值：

# $0=87.480 (x, step/mm)
# $1=87.480 (y, step/mm)
# $2=640.000 (z, step/mm)
# $3=1000.000 (x v_max, mm/min)
# $4=1000.000 (y v_max, mm/min)
# $5=1000.000 (z v_max, mm/min)
# $6=25.000 (x accel, mm/sec^2)
# $7=25.000 (y accel, mm/sec^2)
# $8=25.000 (z accel, mm/sec^2)
# $9=200.000 (x max travel, mm)
# $10=200.000 (y max travel, mm)
# $11=200.000 (z max travel, mm)
# $12=30 (step pulse, usec)
# $13=250.000 (default feed, mm/min)
# $14=160 (step port invert mask, int:10100000)
# $15=25 (step idle delay, msec)
# $16=0.050 (junction deviation, mm)
# $17=0.100 (arc tolerance, mm)

这是我使用的 gcode 文件；它在几遍中从 4 毫米的库存中切出 2 个正方形：

G90 G21
M3 S15000
G0   Z3.000     
(Pass: 1)
   X76.777       Y30.259    
G1   Z-2.000     F250 
   X115.877    F1000
   Y69.359    
   X76.777    
   Y30.259    
(Pass: 2)
   Z-4.000     F250 
   X115.877    F1000
   Y69.359    
   X76.777    
   Y30.259    
(Pass: 3)
   Z-4.400     F250 
   X115.877    F1000
   Y69.359    
   X76.777    
   Y30.259    
G0   Z3.000     
(Pass: 1)
   X73.594       Y78.357    
G1   Z-2.000     F250 
   Y114.557    F1000
   X33.194    
   Y78.357    
   X73.594    
(Pass: 2)
   Z-4.000     F250 
   Y114.557    F1000
   X33.194    
   Y78.357    
   X73.594    
(Pass: 3)
   Z-4.400     F250 
   Y114.557    F1000
   X33.194    
   Y78.357    
   X73.594    
G0   Z3.000     
G0 X0 Y0 (home)
M05

结果：

物理机运行该作业只用了 90.899 秒（1.5149833333333333 分钟）。
…以及同一文件的 grblsim 步进时间输出：10863.959961

所以我想知道两者之间的差异在哪里……似乎它们应该相对接近，除非步进时间单位不是以秒为单位。我想这可能是以毫秒为单位，所以实际上是 10.8 秒，但这比现实世界的时间少 9 倍；所以然后我认为在步进算法之外花费了某种“等待”时间，这弥补了额外的 80 秒。

你知道有什么方法可以让步进时间更有用吗？我觉得这是一个非常直截了当的问题；arduino 时钟以 16Mhz 运行，grbl 在已知时间和持续时间发送阶跃脉冲（假设缓冲区保持满）。

干杯。

只是快速跟进。我确实设法编译了 0.9a（与 grblsim 相同的版本）并将其放在 Uno 上。gcode 仍然在 90.858 秒内运行。

好的。我开始怀疑错误的计时与 grbl 0.9 步进中断计时的新方式有关。很久以前就没有看代码了。
但我会让 grbl_sim 适应 grbl 核心即将发生的变化。目前我没有足够的时间，但如果你能等一个月左右，我会尽力解决所有问题。

别担心朋友。我当然可以等待，因为我还有很多其他项目要处理。谢谢您的帮助！

至少在某种程度上，您正在错误地读取输出。我认为 10863.959961 数字是块连接 (block_t->entry_speed_sqr) 的入口速度，而不是时间值。它是标准输出数据行中的第四个值。

但是，有些事情仍然很奇怪。我将你的 GCode 输入到我刚刚使用上面列出的设置配置的模拟器中，它告诉我这需要 3958.71(…) 秒。两次运行给了我相同的结果。

我认为它在步骤时间计算中有所体现。

((oacr2a + 1) * 8) / F_CPU
OACR2 = (F_CPU/ISR_TICKS_PER_SECOND) / 8 – 1
简化为
(F_CPU/ISR_TICKS_PER_SECOND)/F_CPU
或
1 / ISR_TICKS_PER_SECOND
或
1 / 30000

我是代码库的新手，所以我可能会朝着错误的方向前进，但我敢打赌，步长计算需要考虑其他一些因素，比如加速期间每秒使用的不同滴答声，步脉冲率之类的。（据我所知，TIMER2_COMPA_vect）

我还没有查看代码，但我感觉您找到了问题的确切原因。旧的步进中断以 TIMER1 设置的可变速率运行（据我记忆）。新算法以固定的 30kHz 运行。但是模拟器仍然试图从 TIMER1 寄存器中读取中断调用率，从而得到一个完全错误的时序。
我会尽快解决的。

（删除了我将一些 TIMER0 和 TIMER2 功能混为一谈的评论）

问题是 sys.state 永远不会设置为 STATE_CYCLE，这最终会影响每个块的步骤事件计数、斜坡类型等。您的步长公式（ ((oacr2a + 1) * 8) / F_CPU ）已失效。它准确地描述了调用中断处理程序的频率，但由于 sys.state 的副作用导致移动速率降低，因此较少的中断处理程序调用会导致执行步骤。完成每个事件需要更多的中断调用，因此作业运行时间更长。

由于 sim_stepper() 在缓冲区已满时调用，因此在 handle_buffer() 顶部添加一个块将通过正常代码路径触发状态更改为 STATE_CYCLE，并且仅在缓冲区已满时触发：

void handle_buffer() {

  if (plan_check_full_buffer()) {
    if (sys.state != STATE_CYCLE) {
      sys.state = STATE_QUEUED;
      st_cycle_start();
    }
  }

  // ... the rest of the current procedure code.
}

这导致作业完成时间为 90.19989 秒。（对于我的测试，我还添加了对空块的中断处理程序调用的调用，这可能会影响数字几毫秒……）

@michmerr你能附加一个补丁文件或创建一个PR吗？我将该块添加到 handle_buffer() 中，现在我得到了 164 秒，这比以前好得多，但不完全是你得到的，也不是我所期望的。

感谢你目前的帮助。

@michmerr没关系。当我重建 sim 可执行文件时，我有错误的默认值。我能够在测试 gcode 上获得 90.19989000272848 秒。惊人的！

稍作改动并提交了一个拉取请求。

拉取请求在更改59e906f时被合并，所以这可能会被关闭。