limit3 无视最小值、最大值和有时开始缓慢失控 #240

编码器

out超出 [min, max] 范围
，
有时会缓慢失控。

两年前我注意到了缓慢而持续的失控，只是无法捕捉到它。现在我抓住了它并且可以复制。

以下是我重现该问题所遵循的步骤：

— 在第一个终端：

halrun
loadrt limit3 names=l
setp l.min -50
setp l.max 50
setp l.maxv 4000
setp l.maxa 10000
loadrt siggen names=sg
setp sg.amplitude 100
net s sg.sine => l.in
loadrt threads name1=t period1=1000000
addf sg.update t
addf l t
start

— 在第二个终端：

watch -n 0.2 halcmd show pin l

注意输出值超出 [min, max] 限制。

— 然后在第一个终端上：
在随机时间手动切换以下行并等待开始失控而不是停止。耐心点，多试几次。第二次我需要大约 20 次尝试：

unlinkp l.in
net s l.in

这是我期望发生的事情：

out保持在 [-50, 50] 的范围内
hold steady 当所有输入都稳定且停止后

这是发生了什么：

out out out out the range
有时out在所有输入都稳定且在预期停止后缓慢运行

有关我的硬件和软件的信息：

我正在使用这个 Linux 发行版和版本：Debian Jessie 8.7，amd64
我正在使用这个内核版本：4.5.0-0.bpo.2-amd64
我正在运行 LinuxCNC 2.8.0-pre1-2881-ge624275，在 2015 实时 x86 版本上也注意到了
- [+] 来自 linuxcnc.org 的二进制版本（包括 buildbot.linuxcnc.org）

塞布·库兹明斯基

这是一个 halscope 屏幕截图，显示了 2.7 上的 limit3 约束违规。

塞布·库兹明斯基

这是一个失控的人。请注意，当它的输出处于过冲状态时，我碰巧断开了它的输入。

塞布·库兹明斯基

我开始在名为 2.7-limit3-issue-240 的分支中添加针对此问题的测试

塞布·库兹明斯基

这些测试位于名为“2.7-limit3-issue-240”的分支中。

jm卡苏尼奇

不确切知道您正在运行什么测试（目前不能深入到那个分支。）您能用通俗易懂的语言描述一下测试吗？输入信号是什么？脚步？三角形？正弦波？我记得在 limit3 的开发阶段，某些奇怪的输入可能会搞砸。我认为它可能是一个三角波，其速度大于 limit3 的速度限制，因此限制块永远无法跟踪输入速度。我不记得我是否能够修复它。

……

塞布·库兹明斯基

“失控”测试：

limit3.min = -50
limit3.max = 50
limit3.maxv = 4000
limit3.maxa = 10000
limit3.in是从siggen正弦采样的信号，幅度为100，信号包括第一个半波和第二个半波的一部分；它以 -42 结尾，就停在那里。limit3 输出不断下降超过输入并超过其最小值。这看起来像上面的“失控”屏幕截图，但没有连接和断开引脚中的 limit3。

“超调”测试又名约束违规：

与上面相同的 limit3 min/max/maxv/maxa 约束
输入是振幅为 100 的正弦信号
limit3 输出略高于最大值并低于最小值，每个周期，然后更正并返回到极限，直到下一个周期（如上面的约束违规屏幕截图所示）

三星币

这就是我为测试所做的。
http://electronicsam.com/images/KandT/testing/limit3/

我添加了一堆 hal 引脚以公开内部变量 (limit3.comp)，然后我运行了 limit.hal 文件。我也跑了上面

watch -n 0.2 halcmd 显示 pin l

在单独的命令窗口中。

在观察 l.out 时，我会从信号 s 断开并重新连接 sg.sine。在 5 到 10 次断开连接并重新连接后 – l.out 将继续向负方向移动并且在断开连接时不会停止。似乎总是朝着负面的方向逃跑。

目录中的电子表格有 2 个采样器日志。第一组数据显示失控。第二组显示正常（我认为）断开连接。

我以为我可以弄清楚发生了什么 – 但我有点不知所措。

山姆

jm卡苏尼奇

呸。这将是一个难以解决的问题。Limit3 有一堆不平凡的数学（我记得用代数填满了几页），然后进行一些经验调整以处理代码的离散时间性质与普通物理的连续时间，其中 V = 积分 (A) 和P = 积分 (V)。它可能和我写过的任何东西一样接近“这里有龙”代码。一个建议：查看 git 历史，看看是否/何时最后一次触及核心数学。对以前的版本应用相同的测试。我以为我很努力地测试了原始代码，但也许有些东西漏掉了。或者也许后来的一些更改以当时没有出现在测试中的方式破坏了它。测试旧版本将告诉您适用于哪种情况。约翰·K

……

塞布·库兹明斯基

自从将 limit3 从块移动到 LinuxCNC 以来，limit3 的核心数学并没有真正发生任何变化。我们将约束从参数转换为引脚，添加了一个“加载”引脚，仅此而已。

我确实测试了 2.7 开始和当前提示之间的每个版本，并且所有版本都未能通过此错误报告中描述的两个测试。

jm卡苏尼奇

该死的……这意味着是我的错。不幸的是，在可预见的未来将无法看到它。

……

jm卡苏尼奇

我一直在通过电子邮件查看此线程，并且不知道 github 上有 halscope 屏幕截图。现在才看一眼。（也没有看到原始帖子，不确定我何时/为什么开始在电子邮件中被复制，但很高兴它发生了。）我确实记得在我的早期测试中看到过类似的行为。我只能触及问题的表面，它太深了，我现在无法全神贯注。但它与正弦波输入有关。振幅和频率的组合意味着加速度（可能是速度）和绝对位置都超出了限制。limit3 块正在尝试跟踪输入。当输入变化太快以至于输出跟不上时（速度或加速度限制），它努力预测输入将做什么，并在它最终赶上时平滑地融入其中（即，当位置误差变为零时，它试图使速度误差也为零）。它适用于步骤，因为输入是固定的——很容易与之混合。它适用于三角形，只要速度在限制范围内。如果速度超出限制，它永远无法跟踪输入，因为三角形输入总是以过高的正速度或负速度移动。对于正弦波，它无法真正预测到位置误差得到纠正时输入将做什么。在第一个测试（超调）的情况下，看起来输出只是设法赶上输入（匹配位置和速度，同时服从加速限制）就在输入（和输出）达到位置限制的那一刻。它无法知道输入即将触及位置限制并立即停止。输出必须服从加速限制，所以它必须超调。我很好奇如果正弦波较慢会发生什么，这样输出就可以在输入达到位置限制之前很好地跟踪输入……我有兴趣参与调试这个，但我不能’这几天没花太多时间，手头也没有LinuxCNC开发系统。请保持线程活跃，我会尽我所能。约翰·K 我很好奇如果正弦波较慢会发生什么，以至于输出在输入达到位置限制之前设法很好地跟踪输入….我有兴趣参与调试这个，但我不能投入好几天了，并没有真正手头上的 LinuxCNC 开发系统。请保持线程活跃，我会尽我所能。约翰·K 我很好奇如果正弦波较慢会发生什么，以至于输出在输入达到位置限制之前设法很好地跟踪输入….我有兴趣参与调试这个，但我不能投入好几天了，并没有真正手头上的 LinuxCNC 开发系统。请保持线程活跃，我会尽我所能。约翰·K

……

塞布·库兹明斯基

我想知道我们是否应该以某种方式在 limit3 组件和自由模式联合轨迹规划器之间共享代码。他们都解决了完全相同的问题，对吧？

三星币

大多数时候它工作得很好。在上面的测试中——我唯一能让它失败的时间是当输入在限制 (+/-50) 之间变为负数时，似乎逻辑选择了错误的方向。在这种情况下，它没有选择 max-out（减速并改变方向停止），而是选择 min-out 并继续朝负方向前进。我试图让它在那个范围内不失败，我想如果我能得到好的数据，我就能看到发生了什么。它虽然似乎一直失败。

        if ( fabs(err+dp*2.0) < fabs(err) ) {
	    ramp_a = -ramp_a;
	}
	if ( ramp_a < 0.0 ) {
	    lout = min_out;
	    data.old_v = min_v;
	} else {
	    lout = max_out;
	    data.old_v = max_v;
	}

三星币

不 – 我的上述评估是不正确的。我应该闭嘴。（除了它似乎只会失败）

三星币

抱歉 seb – 不会那么懒惰。行。它实际上会减速到停止（斜坡下降），但不会发生方向的改变。（当变为负数时。）当输入在 -43.1456 断开时，记录了以下数据集。你看到它减速到 0 速度。现在它应该选择 -56.08 (int-max-out) 但它选择了 -56.1。看起来它可能与这段代码有关。

 	if ( in_v > data.old_v ) {
	    ramp_a = maxa;
	} else {
	    ramp_a = -maxa;
	}

在这个数据集中——in_v 和 data.old_v 都是 0。所以 ramp_a=-maxa。在这种情况下，这是错误的选择。（当速度为负时。）

所以为了测试我添加了这些行

    /* determine which way we need to ramp to match v */
    if ( in_v > data.old_v ) {
        ramp_a = maxa;
    } else {
        ramp_a = -maxa;
    }
    if (min_v < 0 && max_v > 0 && data.old_out < 0 && lin > min_) {
        ramp_a = maxa;
    }

这似乎解决了当前的问题（至少在我到目前为止的测试中）
这是一个问题，我有点尴尬……我想不出更好的方法。

三星币

不完全正确。我知道令人震惊

三星币

好的-看看这个。我认为这至少可以解决一个极端情况……我还没有失败……

From 29ec4493096bd1d374f254bdf8c715a7d980a98a Mon Sep 17 00:00:00 2001
From: Sam Sokolik <samcoinc@gmail.com>
Date: Thu, 19 Oct 2017 17:20:13 -0500
Subject: Inital fix for limit3 negative run away.

Signed-off-by: Sam Sokolik <samcoinc@gmail.com>

diff --git a/src/hal/components/limit3.comp b/src/hal/components/limit3.comp
index 6ff14a7b1..3200f56a0 100644
--- a/src/hal/components/limit3.comp
+++ b/src/hal/components/limit3.comp
@@ -18,6 +18,7 @@ typedef struct {
     double old_in;	/* previous input */
     double old_out;	/* previous output */
     double old_v;	/* previous 1st derivative */
+    double older_v;     /* Fix for negative run away */
 } limit3_data;
 
 FUNCTION(_) {
@@ -71,6 +72,10 @@ FUNCTION(_) {
 	} else {
 	    ramp_a = -maxa;
 	}
+        /* An inelegant fix for slow negative runaway */
+        if (data.old_v == 0 && in_v == 0 && data.older_v < 0 ) {
+            ramp_a = maxa;
+        }
 	/* determine how long the match would take */
 	match_time = ( in_v - data.old_v ) / ramp_a;
 	/* where we will be at the end of the match */
@@ -90,9 +95,11 @@ FUNCTION(_) {
 	}
 	if ( ramp_a < 0.0 ) {
 	    lout = min_out;
+            data.older_v = data.old_v;
 	    data.old_v = min_v;
 	} else {
 	    lout = max_out;
+            data.older_v = data.old_v;
 	    data.old_v = max_v;
 	}
     }