motion.requested-vel 至少被几个等离子割炬高度控制 (THC) 系统使用，以允许将角锁定阈值设置为进给率的百分比。不幸的是，motion.requested-vel 是 TP 请求的速度，而不是 gcodes 指定的进给速率
，因此 THC 速度比较在某些情况下可能会失败。一种解决方案是向运动添加一个新的针脚，该针脚刚刚报告来自 gcode 的进给率

我认为此功能将需要状态标签分支才能正确执行。

… 或者可能不是。也许tpActivateSegment()可以只放tc->reqvel一个别针。当tcq排水管时，将该引脚设置为 0。

我尝试了 Seb 的建议并且成功了！请参阅https://forum.linuxcnc.org/plasma-laser/34650-thc-servo-start?start=30#112187
我不明白这是什么意思“当 tcq 耗尽时，将该引脚设置为 0”（猜测它是关于队列的）但似乎该引脚自行重置为 0。

@rodw-au， 整洁的！你有我可以看看的地方的分支机构吗？

Seb，让我看看在我做更多测试以确保它有效之后我是否可以学习如何做到这一点。我也需要在 master 分支而不是 dgarr/external_offsets 上重做它。

当然，让我知道我是否可以在任何 git 方面提供帮助。

测试失败，因此回到方块 1。tc->reqvel 是 motion.requested-vel 的副本。我还尝试了 tc->target_vel
我希望能够从 hal 访问设置->进给率。我已经将其跟踪到 CanonConfig_t.linearFeedRate 但它在存储之前已经在 SET_FEED_RATE() 中进行了修改。我认为应该在 CanonConfig_t 中添加一个新字段，并且 SET_FEED_RATE() 可以存储原始 F 参数。但我不知道如何将它从那里带到 hal in control.c 可以看到的地方。有什么想法吗？

Motion 从 Task 中获取一系列段（线和弧）。每个段都带有自己请求的进给速率，正如您所指出的，它在 Motion ontc->reqvel和 HAL 中显示为motion.requested-vel。
任务用于线的请求速度通常是 F 字，除非这会违反 ini 配置中的轴速度约束。
任务用于弧的请求速度通常是请求的 F 字，除非这会违反 ini 配置中的轴速度或加速度限制。
下图演示了此行为。这是一台低加速度机器，运行一个由交替的直线和圆弧组成的程序，其中圆弧开始时很小，然后沿着序列半径增加。注意如何motion.requested-vel对于直线总是很高，对于圆弧，它开始时对于小圆弧来说很小，然后逐渐增长以匹配直线要求的速度，一旦半径变得足够大以至于低机器加速度可以跟上圆弧路径。

这就是说：Motion 不知道编程的进给速率，它只知道每个段的请求速度。这个请求的速度由 Canon（Interpreter 和 Motion 之间的接口，在 Task 中）基于机器约束生成。

所以我又回到了我认为这必须等待状态标签的下意识反应。

我不熟悉 Torch Height Control，有人能告诉我这个用例吗，在这个用例中，编程的进给速率比当前可用的两种速度（motion.current-vel 和 motion.requested-vel）中的任何一种更有用？

我不是专家，但我认为需要的是一种比较 gcodes 编程进给率 (FXXXX) 的方法，它是所需的等离子切割速度与实际速度（当前速度），因此可以禁用 THC（冻结在当前高度）当当前速度下降到编程进给率的指定百分比时（以避免在拐角处俯冲）。

割炬高度控制 (THC) 是等离子操作的基础。对于等离子，割炬电压和切割高度之间存在线性关系。制造商发布的切割表说明了给定材料和厚度的理想高度、切割速度和电弧电压。进给率通常根据这些参数设置。电弧电压用作对控制 Z 轴高度的 PID 的反馈。当 TP 减慢电流速度时，电压会增加，因此 PID 会降低割炬高度，有时会导致碰撞。解决方案是在电流值低于制造商数据设定的进给速率的 85% 时禁止 PID 控制。（速度保持）

此问题源于不正确的文档，指出 requested-vel 是 F 参数。
在等离子中使用的高速下，请求速度的变化通常是剧烈的。

如果用户依赖于不正确的文档，THC 操作会由于片段的请求级别下降而意外启用，并且可能会发生剧烈和意外的更正，从而导致剪辑中出现草皮。

由于当前请求的速度行为，解决方案是从 Gcode 发送进给速率两次，一次作为 F 代码，另一次作为 M67/M68。这种数据重复是非常不受欢迎的，因为它会导致错误。

我花了几个小时研究代码，并开始理解 Seb 描述的模块之间的关系。我注意到 EMCMOTSTATUS 在源代码中被描述为全局的，我确实尝试从 canon 内部（来自 SET_FEED_RATE 过程）在结构中设置一个新变量，但是出现了运行时错误，所以我假设它只是全局的运动。

全局 EMCMOTSTATUS 数据可以从佳能更改吗？
状态标签有分支吗？
你能解释一下状态标签的作用吗？

我不太确定文档是否不正确，只是它不完整
那是 motion.requested-vel 是 TP 的要求，这意味着
与裸 gcode 进给率数字相比它有额外的限制

狡辩一下，真的应该叫速度，而不是速度……

2.8 文档位于http://linuxcnc.org/docs/devel/html/config/core-components.html#sec:motion-pins
state:
motion.requested-vel – (float, out) 当前请求的用户单位速度每秒从 G 代码文件中的 F=n 设置。没有进给覆盖或任何其他调整应用于此引脚。

除了速度和速度之外，没有任何关于它在每段基础上通过机器和 TP 约束进行调整的说法。

啊，我只是按照手册页说的更少：

motion.requested-vel OUT FLOAT
没有调整进给倍率的请求速度

文档比手册页更具误导性，尽管它确实是
从 F=N 设置派生的，它只是有额外的限制

我更新了文档（联机帮助页和 html 文档，在 2.7 和 master 中）以尝试更加清晰。

@pcw-mesa，我同意它是速度，而不是速度，但我认为称它requested-speed会更令人困惑，因为“速度”是主轴转速的专业术语。我们也不能称之为requested-feed，因为那样会排除急流……

你能简要介绍一下“状态标签”的作用吗？我找到了关于合并它的讨论，但仍然没有人知道它会实现什么。

对于等离子使用，我认为可以在一个组件中合成一个进给率，该组件监控请求的速度并有一个输出引脚，只要请求的速度增加，它就会上升，并在运动停止时重置为零。

感谢您更新文档。我现在可以看到变化。

我只是所有这一切的新手，但我想我只是发现有一个简单的解决方法。也许等离子用户应该重新映射 Fnn 并发出 M68 E1 Pnn 以将原始进给率发送到 HAL。这种方法是否有任何可能的负面影响？

我没有意识到 F 可以重新映射，但它似乎可以：http ://linuxcnc.org/docs/2.7/html/remap/remap.html#remap:remappable-codes

这应该工作得很好，因为它不需要后处理器是 THC 感知的。

哈 – 我也不知道 F 可以重新映射..很酷 – 我想我也有一个应用程序。

山姆

只是为了确认重新映射 F 代码是我们几个人测试过的解决方案，它会起作用。但是在我们关闭这个问题之前，虽然我们一直在更新这个问题的早期文档，但我可以指出重新映射文​​档很缺乏并且 F 代码部分有几个 TBD，我认为这意味着要完成。

这是一个基于 axis/remap sim 的 gcode setfeed.ngc sub 示例，它可以工作，也许它可以在文档中使用

o<setfeed> sub 
(debug, in setfeed feed=#<feed>) 
; using the code being remapped here means 'use builtin behaviour' 
M67 E1 Q[#<feed>/60] 
F#<feed> 
; signal success be returning a value > 0:
o<setfeed> endsub [1] 
m2