sim_time 问题 #306

鲁斯沃纳

我在边缘分支上玩 grblsim，我无法弄清楚“sim_time”的值代表什么。我用 1x step_time 通过 sim 运行了一个非常简单的 gcode 文件，捕获了 stderr 并解析了它。

这是 gcode 文件：

G90 G21
G0 X1.000     
M30

这是解析后的输出：

{x:0.004,y:0,z:0,t:0.000033},
{x:0.304,y:0,z:0,t:1.000031999999306},
{x:0.608,y:0,z:0,t:2.000030999997783},
{x:0.912,y:0,z:0,t:3.000030000002988},
{x:1,y:0,z:0,t:3.286833000004481},

如您所见，它会将 X 轴精确移动 1 毫米，并使用 $0=250 步/毫米的 sim 默认值和 250 毫米/分钟的默认进给速率，移动 1 毫米只需 0.24 秒。然而，最终的 sim_time 是 3.286。这个值是多少？

我已经通过 sim 代码进行了跟踪，但我对 C 或 AVR 编程不太熟悉，所以我在通过 ISR/CPU/OCR2A 进行跟踪时有点迷路了……

任何帮助将非常感激！谢谢！

鲁斯沃纳

这是未解析的输出，采用 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 }

shapeoko

我不熟悉 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
。

jgeisler0303

我不知道自从我上次使用 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 文件；它在几次通过后从 4mm 的库存中切割出 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 秒。

jgeisler0303

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

鲁斯沃纳

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

密歇根

您至少在某种程度上错误地读取了输出。我认为 10863.959961 数字是 block junction (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）

jgeisler0303

我仍然没有查看代码，但我感觉您找到了问题的确切原因。旧的步进器中断以 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 秒。（对于我的测试，我还添加了对空块的中断处理程序调用，这可能会影响数字几毫秒……）