Marlin: [BUG] SKR v1.3（或任何其他LPC1768）：伺服信号出现问题，导致bltouch出现问题

创建于 2019-12-09 · 72评论 · 资料来源: MarlinFirmware/Marlin

错误说明

最近，我已将3d打印机升级到Bigtreetech SKR v1.3。不幸的是，我的bltouch克隆（较旧的triaglelab 3d touch版本）遇到了一些麻烦。
从现在开始，并且比在G28或G29上更高，bltouch不会触发，并且打印头继续向下滑入床中。
最初，我试图在Inernet中找到解决方案，但仅在论坛上发现有人说SKR v1.3的5V电源不良。一些额外的电容器或外部5V电源应该会有所帮助。我都尝试过，但没有任何帮助！ 5V电源不是问题！
我自己做了一些调查，并在示波器的帮助下发现了实际的问题：
LPC1768（可能还有其他）的HAL中似乎存在问题，可能在伺服输出上产生错误的信号。当伺服脉冲应从1472µs（M280 P0 S90；收起的bltouch引脚）更改为647µs（M280 P0 S10；展开的引脚）时，有时一个周期的脉冲长度为20650µs。
较长的脉冲似乎会使bltouch（克隆）感到困惑，即使已部署销，在这种情况下，传感器在接触到床时也不会触发终点挡块。
我相信，每当在小窗口中发出“ M280 P0 S10”命令时，都会发生这种情况，在小窗口中，伺服引脚的高电平持续时间超过647μs，但小于1472μs。到此循环的下降沿已经结束，并且直到下一个20ms cylce才执行（只是一个猜测，我没有证据...）。
但是我找到了一个适合我的快速而肮脏的解决方案：

diff --git a/Marlin/src/HAL/HAL_LPC1768/Servo.h b/Marlin/src/HAL/HAL_LPC1768/Servo.h
index 1bbf84c73..97a7bcb54 100644
--- a/Marlin/src/HAL/HAL_LPC1768/Servo.h
+++ b/Marlin/src/HAL/HAL_LPC1768/Servo.h
@@ -58,6 +58,12 @@ class libServo: public Servo {
     static_assert(COUNT(servo_delay) == NUM_SERVOS, "SERVO_DELAY must be an array NUM_SERVOS long.");

     if (attach(servo_info[servoIndex].Pin.nbr) >= 0) {    // try to reattach
+      /* workaround for too long pulse on the servo pin */
+      if ( (servoIndex == 0) && ( extDigitalRead(SERVO0_PIN) == 1 ) ) {
+        safe_delay(3);
+      }
       write(value);
       safe_delay(servo_delay[servoIndex]); // delay to allow servo to reach position
       #if ENABLED(DEACTIVATE_SERVOS_AFTER_MOVE)

它仅检查伺服引脚的当前状态。如果为高电平，则信号的更改会延迟3ms。这样可以确保在应用更改时该引脚绝对为低电平，因为伺服脉冲不能超过2.4ms。

但这只是一个快速而肮脏的技巧，应该在HAL中修复。并且还应该检查它是否在其他控制器上也可能发生此问题。

我的配置

Marlin_Configuration.zip

重现步骤

使用配置了伺服器（#define NUM_SERVOS 1）的SKR v1.3板（或任何其他LPC1768）
发送M280 P0 S90
发送M280 P0 S10
观看伺服信号（SKR v1.3：引脚P2_00）

预期的行为： [您期望发生的事情]
从1472µs的脉冲宽度到647µs的信号完全过渡。

实际行为： [实际发生的情况]
在命令之后的第一个周期中，您将不时地看到超过20ms的脉冲宽度。

附加信息

如果改用“ M280 P0 S180”和“ M280 P0 S0”，则更有可能看到。（差异更大->更大的问题窗口）

LPC176x Confirmed ! BLTouch

资料来源

mlehnhoff

👍4

最有用的评论

这不应归咎于探针硬件。从板产生的信号不正确，并且已使用示波器进行了验证。应该解决。

当我调试所有那些导致SKR Mini E3板上类似问题的计时器冲突时，我还可以确认报告的行为与正版BLTouch硬件非常相似。无效的脉冲长度似乎使BLTouch忘记了正在做什么并导致了故障。

@mlehnhoff ，您是否从示波器捕获了任何可证明该问题的图像，并且可以将其附加到该问题上？

我认为我不喜欢当前的解决方法作为完整的解决方案，但是我真的很感激mlehnhoff提供的详细描述问题的方法，以及证明脉冲显然是问题根源的解决方法。

sjasonsmith 于 2019-12-11

👍4

所有72条评论

您可以尝试使用真正的BLTouch吗？

Grogyan 于 2019-12-10

您可以尝试使用真正的BLTouch吗？

另外，您是否尝试过在Configuration_adv.h ？中调整BLTouch设置？：您可以调整BLTOUCH_DELAY ， BLTOUCH_FORCE_SW_MODE ， BLTOUCH_FORCE_MODE_SET等设置。

thisiskeithb 于 2019-12-10

哦，对不起，我忘了提。当然，我之前确实尝试过BLTOUCH_DELAY ， BLTOUCH_FORCE_SW_MODE甚至DELAY_BEFORE_PROBING不同组合。没有成功。
现在，我发现问题出在哪里了，很明显，更长的延迟无济于事。因为错误的20ms脉冲使bltouch进入此错误状态，所以在触摸构建板之前已经发生了几秒钟。
此旧版本的bltouch克隆不支持BLTOUCH_FORCE_MODE_SET 。它不是“智能”的。

不，我没有使用正版BLTouch的权限。对我和我的旧克隆而言，上述破解工作正常，因此我个人不需要针对此问题的适当修复。但是我认为无论如何都应该解决此问题，因为我认为即使是实际的伺服器也可能对此脉冲产生短暂的抖动或任何其他怪异的反应。

mlehnhoff 于 2019-12-10

哇， @ mlehnhoff ，您的补丁减轻了我的痛苦。 SKR v1.3 +（不确定是否使用旧版本）triaglelab 3d touch-同样的麻烦。我自己的8/10工作条件：BLTOUCH_FORCE_SW_MODE + BLTOUCH_DELAY1000。但是您的补丁在10/10上工作，而没有SW_MODE和DELAY。天哪！

kockockockoc 于 2019-12-10

👍1

我在重新武装（相同的MCU）上测试了基于伺服的测头，但没有任何问题，但是我使用了运动后禁用功能。

我没有尝试过，在不需要时，juse具有逻辑意义，可以停用伺服器

boelle 于 2019-12-11

我有一些真正的BLTouches，它们都可以在LPC1768的SKR 1.3上正常工作。

thisiskeithb 于 2019-12-11

所以在这里开枪，这很可能是硬件问题（电线，噪声连接）还是用户配置问题？

boelle 于 2019-12-11

大多数其他BLTouch代码/配置选项的原因相同，这是BLTouch克隆问题。

请记住，3DTouch！= BLTouch。与这些副本有很多未解决的问题。

thisiskeithb 于 2019-12-11

那我将其称为硬件问题，

是的，我现在3dtouch（和其他产品）不是BLtouch

对我来说，最大的问题是马林枪支支持克隆的产品是什么，或者我们只关心真正的产品吗？

boelle 于 2019-12-11

给个人一些想法，我认为马林鱼应该支持克隆人是不公平的

但是我可能是错的，想法？

boelle 于 2019-12-11

我的两毛钱，不管XXtouch叫什么名字。它们中的任何一个都连接到SERVOS引脚（不是BLtouch专用引脚）。 SERVOS应该像伺服一样工作。

但是我认为无论如何都应该解决此问题，因为我认为即使是实际的伺服器也可能对此脉冲产生短暂的抖动或任何其他怪异的反应。
（来自@mlehnhoff评论）

kockockockoc 于 2019-12-11

这不应归咎于探针硬件。从板产生的信号不正确，并且已使用示波器进行了验证。应该解决。

@mlehnhoff ，您是否从示波器捕获了任何可证明该问题的图像，并且可以将其附加到该问题上？

sjasonsmith 于 2019-12-11

👍4

抱歉，我没有立即提供范围屏幕截图。我本来做了一些，但是出了点问题。但是直到我将范围退还给我时才意识到（这不是我的）。
但是现在我做了一个新的：
scope_0
在图片上您可以看到从1472µs到544µs的过渡，

脉冲为20544µs。

再加上我尝试了一个实际的伺服器，这就是证明，这个问题不仅限于3dtouch或其他克隆。

IMG_4677.zip

伺服应该从90°（中间的杠杆）转到0°（杠杆的向下），但是当出现故障脉冲时，它实际上首先是上升，然后才下降。

顺便说一下，至少有八个不同版本的正版bltouch（经典v1.0，v1.2，v1.3，智能v1.0，v2.0，v2.2，v3.0，v3.1），并且没有一个人知道，如果所有的人都能正常工作;-)

这是另一个提示：当您手动发送M280命令时，出现问题的可能性很小。我编写了一个脚本来切换伺服器（在视频中使用），这极大地增加了可能性：
Servo_toggle.gcode.txt

mlehnhoff 于 2019-12-11

我想知道这是否与我使用BLTouch遇到的问题有关。
我通过USB为我的Re-ARM供电，并使用M80打开12V电源。有一个连接到12V电源的5V降压转换器为BLTouch供电，因此BLTouch在12V电源启动之前不会通电。
电路板加电时，BLTouch呈红色闪烁-如果BLTouch在加电之前收到信号，这显然有些正常，因此我对此并不担心。
但是，任何使用M280 P0 S160重置它的尝试绝对无效。如果已部署，则销钉也不会缩回。
但是， M280 P0 S60成功切换到SW模式，并且也停止了闪烁。
除了闪烁和S160显然被忽略之外，BLTouch似乎运行完美。即使闪烁，它也可以正确部署，收起并放置探针-我做过全床探针，但从未见过探针故障，重复性极好。
这是真正的V3.1 BLTouch-不是克隆。

ManuelMcLure 于 2019-12-11

我忘了提一下，我用廉价的迷你DSO和大型CRT示波器检查了脉冲，脉冲长度似乎还不错。我还尝试了不同的S值（从155到165），但没有找到一个会触发复位的值。

ManuelMcLure 于 2019-12-11

我还没有查找LPC伺服库的工作方式-但：
伺服信号是PWM。如果使用STM32硬件计时器实现此错误，则可能是由于直接更新计数器比较寄存器而不是将新值更新到比较寄存器的预加载寄存器而导致此错误。如果在计数器处于低值和高值之间时将比较寄存器从高值更改为低值，则跳过（相等）比较，直到计数器超限并且达到新值后，引脚才会更改。如果使用了预加载寄存器，则在计数器溢出或（旧）比较值匹配时更新比较寄存器。这样就没有脉动的风险，只有大约一个PWM周期（20ms）的最大可能延迟。
编辑：该错误的机会将是5％，每向后跳1ms。
我想，这里我们有类似的东西。

AnHardt 于 2019-12-12

这是因为lpc框架未在闩锁模式下运行硬件pwm（其中脉宽寄存器在每个周期被屏蔽和闩锁），应该可以通过一个简单的模式位来完成此操作..但是不幸的是我不能要使其可靠地工作，可以在可能的1个周期的毛刺或随机的脉冲宽度之间进行选择（但频率经常取决于更新的频率），而根本不改变。

可以对此事做进一步的研究，但实际上这并不是一个复杂的过程，我在这种故障上浪费了很长时间，最后还需要注意其他事项。

p3p 于 2019-12-12

@mlehnhoff @kockockockoc请问您如何申请dp？

cronos45 于 2019-12-16

@mlehnhoff @kockockockoc请问您如何申请dp？

老实说，我对git很陌生，我很高兴可以通过“ git diff”创建此补丁。我敢肯定，必须有其他git命令才能应用此补丁。也许@kockockockoc可以帮忙...
但是对于这个很小的代码片段，您甚至可以手工完成。就像在显示位置在文件“ Marlin / src / HAL / HAL_LPC1768 / Servo.h”（当然不带“ +”）中添加以“ +”开始的四行一样简单...

mlehnhoff 于 2019-12-16

嗨，我使用的是Bigtreetech SKR v1.3和3D Touch，但3D Touch无法正常工作。我已经在Arduino Mega中使用一些代码测试了3dTouch，并且运行完美。因此，我尝试了所有发现的建议以及@mlehnhoff补丁，但我仍然遇到相同的问题= 3D Touch被冻结。当Marlin启动时，3D Touch会进行自检，然后将销钉收起并永久保持此状态，而无需进行任何更改（通过M43 S或从Marlin菜单进行）
我真的很担心，因为我不知道要解决这个问题必须做什么。任何建议都是可以的。

javata70 于 2019-12-18

我怀疑此错误与我在此处报告的错误相同： https :

我仍然从19/22/19运行错误修正提交，没有任何问题。我今天尝试了最新的错误修正提交，但伺服问题仍然存在。

Reywas62 于 2019-12-19

@ Reywas62以及所有其他内容，我发现本文http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html可以解决此问题。显然，某些SKR板可能具有低阻抗（大约200欧姆）的输出信号，这将需要大量电流才能正常工作（而Arduino板上则不会发生，这就是我的3D测头能够正常工作的原因因此，显然它与固件无关。

javata70 于 2019-12-20

好吧，我会买那个解释，除了我的董事会在早期提交Marlin bugfix 2.0.x（6/22/19）时可以正常工作。

Reywas62 于 2019-12-20

我可以确认mlehnhoff的“快速处理”解决方案正在工作。我使用BLTouch克隆探测9x9 UBL-Mesh。通常，当我运行网格生成时，81点网格中的1或2点会失败。但是使用“修复”，一切正常。因此，我将继续使用此解决方案。我的情况下，我认为长伺服脉冲会出现问题，因为我的图钉已部署，传感器无法触发。

dermigoe 于 2019-12-20

👍1

我想确认我的3D Touch问题已解决。问题是SKR 1.3伺服引脚的电流低。我制作了电路并成功进行了测试。现在，在运行M43之后，我已经收到以下信息：
发送：M43 S
伺服探头测试
。使用索引：0，展开角度：10，收起角度：90
。探针Z_MIN_PIN：57
。 Z_MIN_ENDSTOP_INVERTING：否
。检查BLTOUCH
=检测到BLTouch Classic 1.2、1.3，Smart 1.0、2.0、2.2、3.0、3.1。
*请在30秒内触发探针*
。脉冲宽度（+/- 4ms）：10
=检测到BLTouch pre V3.1（或兼容）

javata70 于 2019-12-21

我将在这里尝试我的设置，但是我同时拥有SG90和MG90伺服电机，它们在禁用时间歇性地返回。当它握住Z-Probe开关时，这会在机器撞到床上时杀死机器。上次坠机共造成Creality CR10 S5的轮架。 > _

当我有机会的时候，我将尝试一下电路，看看它是否能解决问题。而且还要尝试固件破解。 :)

DarkAlaranth 于 2019-12-25

尝试了固件破解之后，对我来说没有任何变化（正如我所怀疑的那样，因为该黑客修复了bl-touch克隆，不一定是伺服运动）。完成移动后，伺服器偶尔仍会向后移动。

考虑到这一点，我撤消了黑客攻击，并告诉马林不要禁用伺服器，并且似乎后退问题已经消失了。似乎禁用伺服会触发我的问题。幸运的是，我使用的MG90在我选择的角度上没有任何振动/抖动。 :)

我绝对要感谢mlehnhoff用于测试的gcode。每当我运行它时，伺服器就会播放3到4次，而当我告诉马林保持启用伺服器时，脚本会连续运行3次。考虑到有关低电流的报道，我还对加热器进行了测试，以使PSU处于负载状态。 :)

不知道这有什么关系，但是我的伺服角度是172（展开）和35（收起），看起来它会向后移动伺服，每次都相等。伺服器从未向前移动。

DarkAlaranth 于 2019-12-25

固件破解无法解决我的问题，但是保持启用伺服状态可以防止伺服系统出现异常，就像DarkAlaranth一样。并不是真正的解决方法，而是可以接受的解决方法。

Reywas62 于 2019-12-28

在过去的几天中，我曾在多个平台上尝试过一些额外的背景知识，并认为我可能已经破坏了我的两个AntLab BLtouch，所以我订购了第三个。

这是我在以下平台上观察到的
SKR Pro V1.1无法正常工作
SKR v1.3无法正常工作
RAMPS 1.4无法正常工作
SKR v1.4无法正常工作
RAMPS 1.6无法正常工作

在M119上进行探测之前的症状
报告终止状态
x_min：已触发
y_min：已触发
z_min：已触发

我也调整了pins文件，结果也一样。

这是我在各种马林鱼老式视频中使用的过程
https://www.youtube.com/watch?v=5cSzFCv7K4Q&t=14s
https://www.youtube.com/watch?v=R0HeFV9nKCM
https://www.youtube.com/watch?v=HR-zn4dv1fY&t=2s
https://www.youtube.com/watch?v=-4o6-8TgpNM

我可以发布更多视频，但我的观点是，使用3种真正的BL触摸技术无法在其中任何视频上使用。

配置发生了变化吗？现在，configuration_adv.h具有大量的BL触摸电源设置。

ebraiman 于 2019-12-29

Z轴归位时是否应该有温度报告？
这是调试：
发送：G28 Z0
发送：M114
发送：M105
记录：错误：！由于BLTouch错误而调用了STOP-用M999重新启动
[错误]错误：!! 由于BLTouch错误而调用了STOP-用M999重新启动

ebraiman 于 2019-12-29

RAMPS 1.6 / MEGA2560上的M119
读取正确，可在z分钟内打开
探测似乎不起作用。

ebraiman 于 2019-12-29

有这个问题。
Ender 3，SKR Mini E3 v1.2，原装BLTouch v3.1

qwewer0 于 2020-01-05

V2对我来说效果很好
skr1.3的接线与库存方向不同。我正在使用Marlin 2.0.1的发行版

您可以尝试其他BLTouch吗？要验证它不是损坏的探头？

Grogyan 于 2020-01-05

不，对不起我只有一个普通的BLTouch。大约只有200左右发生故障。

qwewer0 于 2020-01-05

@mlehnhoff，如果您有时间，请重新测试

并且由于bugfix 2.0.x每天更新，请每14天左右重新测试一次

boelle 于 2020-01-24

重新编译了最新的错误修正版本[2020.01.24。]。
进行了两次探针重复性测试，每次重复150次。

床加热关闭，成功完成，标准偏差：0.003928。
床加热开启，探测失败，失败于137。

qwewer0 于 2020-01-24

我在带有克隆BLTouch（3DTouch）的SKR1.1板（LPC1768）上使用bugfix 2.0.x时观察到了类似的行为。
我尝试了不同的解决方法，但在25个探测点中，至少在一个探测点中，销钉过早释放（例如立即展开并随后收起）。

obertr0n 于 2020-01-28

@mlehnhoff，如果您有时间，请重新测试

boelle 于 2020-02-02

@boelle ：不需要重新测试，因为正如前面提到的@ p3p ，问题实际上不在Marlin本身，而是在LPC框架中。他说，他必须取消对PWM锁存模式的注释，因为它无法正常工作。因此，只要这不是固定的，每个想要拥有可靠工作的bltouch的人都必须使用我的丑陋但可行的解决方法。
目前，很遗憾，我无法使用示波器，否则，我想在调试此问题时支持P3P。如果有人想对此进行更深入的研究，请随意： https :

mlehnhoff 于 2020-02-04

👀1

有这个问题。
Ender 3，SKR Mini E3 v1.2，原装BLTouch v3.1

SKR Mini E3 v1.2使用STM32微控制器，而不是LPC1768。

goofball222 于 2020-02-05

我想知道锁存PWM的问题是否与以下LPC176x勘误表有关：

3.13 PWM.1：从100％更新PWM1.1的占空比时，
在某些情况下，输出可能在整个PWM周期之前保持低电平，然后
更新生效
介绍：
在LPC176x PWM外设上，两个匹配寄存器可用于提供一个
边沿控制的PWM输出。一个匹配寄存器（PWM1MR0）控制PWM周期
率，方法是在比赛进行时重置计数。另一个匹配寄存器控制PWM边沿
位置。例如，匹配寄存器PWM1MR1控制PWM1的边沿位置。
多个单边沿控制的PWM输出在输出开始时都具有上升沿
每个PWM周期，当PWM1MR0匹配发生时。
问题：
仅在单边沿模式下，如果占空比为PWM1.1（脉冲宽度调制器1，通道
1个输出）从100％更新（PWM1MR1 = PWM1MR0），然后是PWM1.1的输出
在新的所需占空比之前的整个PWM周期内可能会意外地保持低电平
生效。此问题仅影响PWM1.1的输出。其他PWM通道
（PWM1.2至PWM1.6）不受此问题的影响。
解决方法：
可以实施软件修复，使用户可以通过以下方式加载PWM1MR1：
PWM1MR0 + 1（至少1），以避免PWM1.1输出更新中的任何延迟。

我希望不是这样，因为我认为我们永远不会将伺服引脚置于100％PWM模式。

ManuelMcLure 于 2020-02-05

然后再次在PWM 1.1上将P2_0用作SKR 1.3上的伺服引脚...

ManuelMcLure 于 2020-02-05

我一直在研究类似的问题（使用真正的BL Touch 3.1和SKR PRO 1.1）。
我已经记录了在＃16986中找到的内容，但基本上我发现我的内容与XY_PROBE_SPEED有关。数字10000会导致BL Touch信号在15个探测点（也是第一个Y移动之后的第一个）从脉冲变为直流电平，而对我来说6000并没有显示任何问题。

yavinmaster 于 2020-03-01

👍1

我已经在两个Ender 3的SKR v1.3和3D Touch v2（和Pi 3B）上测试了这种解决方法一个多月。以前，在执行ABL（3-5次打印中至少1次）时，我总是会出现常规故障，如果不是机械Z端，探针将不会触发（但会立即闪烁红色）并且喷嘴会冲入床中。停止我故意离开。我已经尝试了Marlin 2.0.x中探测/ BL Touch配置的大多数（即使不是全部）排列。
由于这几周（无数次M48和许多实际打印）的无数次探测中，我有0次失败，因此我必须认为这种解决方法在我的情况下显然是成功的。当然，如果结果有所变化，我将更新我的发现。
我还测试了它的工作方式与XY测头速度（尝试6-8-10000 mm / s），Z测头速度无关，并且在探测过程中没有禁用加热器/步进器。基本上，Marlin中的探测设置似乎不再是避免故障的因素（但仍可能影响精度，至少Z速度如此）。
唯一的问题是，如果LCD的5V是从SKR引出的，则LCD的背光（5V）会在探测过程中暂时闪烁，这可能表示由于探头的电流消耗导致电压下降（但我不想用我的示波器来隔离和探测整个物体）。因此，我改用5V连接到Pi（但也可以是任何外部5V电源），在探头附近拼接了两根GND线，一根接地线连接到SKR，另一根接地线连接到Pi（用于穷人的星地）。

nife87 于 2020-04-30

@mlehnhoff
请测试bugfix-2.0.x分支以了解其位置。

boelle 于 2020-06-23

👍1

我将很快在真正的BLTouch上进行测试，我相信我也有同样的问题。

编辑：不是同一块板（STM32F103RC），而是相同的问题！试图找出是否是时间问题或其他问题！但是，当执行91 UBL网格时，我可能会以与此处所述相同的方式获得1或2个失败的探针？

aslater3 于 2020-07-01

好吧，我发现我的主板似乎正在使用“共享”伺服代码。经过一些反复试验后，我添加了以下内容，似乎safe_delay为6ms / us？正在工作！如果这有意义，传感器似乎会更快地触发？现在，我设法在没有任何传感器故障的情况下获得了第一个网格？将密切关注并进行更多测试，但最初看起来很有希望！这是真正的BLTouch，我已下令第二个以为它有问题！我不认为其其他硬件，因为此设置在原始股票板上无法正常工作，只是自转至BTT V2.0和Marlin之后才出现此问题。以前我运行Klipper没问题。

if ( (servoIndex == 0) && ( extDigitalRead(SERVO0_PIN) == 1 ) ) { safe_delay(6); }

aslater3 于 2020-07-02

@ aslater3如何判断我的主板（SKR Mini E3 v1.2）是否具有“共享”伺服代码？

qwewer0 于 2020-07-02

@boelle对不起，我很忙于其他事情。我刚刚测试了最新的bugfix-2.0.x（似乎是2.0.5.4）。问题仍然存在。那是因为它在pio-framework-arduino-lpc176x中仍然没有固定。
但是我现在可以使用示波器了，我愿意进一步研究它（并最终对其进行修复）...

mlehnhoff 于 2020-07-14

2.0.5.4 （ 2.0.x ）和bugfix-2.0.x是两个不同的分支。请尝试最新的bugfix-2.0.x并让我们知道您是否仍然遇到此问题。

thisiskeithb 于 2020-07-14

2.0.5.4 （ 2.0.x ）和bugfix-2.0.x是两个不同的分支。请尝试最新的bugfix-2.0.x并让我们知道您是否仍然遇到此问题。

是的，我知道，我确实使用了最新的bugfix-2.0.x！ LCD菜单仅告诉我2.0.5.4

但这没关系，因为该错误不在MarlinFw代码内部，而是在pio-framework-arduino-lpc176x内部

甚至众所周知，代码的哪一部分引起了问题：HW-PWM的禁用锁存。

问题是找到一种在没有其他问题的情况下重新启用闩锁的方法。这就是为什么锁存被禁用的原因。

mlehnhoff 于 2020-07-15

我一直在与@ p3p聊天，因为我一直在调查其他平台上的类似问题。我认为这种行为没有任何机会被改变，除非真正实施更永久的解决方案，否则现在不值得重新进行测试。

sjasonsmith 于 2020-07-15

LCD菜单仅告诉我2.0.5.4

则您没有使用最新的错误修正。您的液晶显示屏上会显示bugfix-2.0.x 。

thisiskeithb 于 2020-07-15

在已经通过新的匹配值之后，设置较短的占空比时，我知道1周期的毛刺，目前我不确定如何缓解此问题。启用pwm影子寄存器后，硬件似乎没有执行应有的功能。

p3p 于 2020-07-15

LCD菜单仅告诉我2.0.5.4
则您没有使用最新的错误修正。您的液晶显示屏上会显示bugfix-2.0.x 。

好吧，我不好，我不小心克隆了分支2.0.x而不是bugfix-2.0.x ...现在，我修复了->没有区别（当然）

mlehnhoff 于 2020-07-15

在已经通过新的匹配值之后，设置较短的占空比时，我知道1周期的毛刺，目前我不确定如何缓解此问题。启用pwm影子寄存器后，硬件似乎没有执行应有的功能。

@ p3p您能告诉我，启用锁存后遇到了哪些问题？

mlehnhoff 于 2020-07-15

从我记得的情况（调试该功能已经有很长时间了），启用阴影寄存器后，脉冲宽度根本不会更新，因为您可以想象，我选择了1个周期的毛刺而不是那个。这可能是由于在同一时期多次更新脉冲宽度引起的，但我不确定。

p3p 于 2020-07-15

命令的伺服角度必须至少保持20 ms，才能在输出上以变化的脉冲宽度看到。
为了使新的脉冲宽度可由设备/伺服器识别，它可能需要停留几个脉冲。
因此必须禁止在至少20 ms内更改角度。
@sjasonsmith发现了BL_Touch，并在https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment -657406598指出了大约60毫秒。

更频繁地更新影子寄存器是没有意义的。寄存器的写入次数不应超过角度值的变化。（影子寄存器的影子变量？）
可能需要在伺服库的更高级别上附加一个补丁，以防止过于频繁的更改。我们已经有了与SERVO_DELAY类似的东西，最初应该是为了防止在伺服器（机械地）到达其目标之前关闭伺服器信号。

AnHardt 于 2020-07-16

@AnHardt我知道每个周期多次更改影子寄存器是没有意义的，但是我不明白为什么在将值推到周期末的实际寄存器之前多次更改它们会引起问题，我不确定解决该问题的方法是停止客户端应用程序过于频繁地更新硬件PWM（如果确实是问题所在），而无论如何都不会对性能造成重大影响。

p3p 于 2020-07-16

@AnHardt我知道每个周期多次更改影子寄存器是没有意义的，但是我不明白为什么在将值推到周期末的实际寄存器之前多次更改它们会导致问题，

我也不知道为什么或是否有问题。但是，如果您告诉我们这会导致问题，我们应该尽量避免这种情况。
像这样的构造：

static float last_servo_angle = 0.0f;
if (servo_angle != last_servo_angle) {
  set_servo(sevo_angle);
  last_servo_angle = servo_angle;
}

至少可以防止多次以相同的值写入影子寄存器。

如果我没记错的话，上次我在BL-Touch出现之前触摸SERVO_PROBE代码时，我小心地避免了同步移动伺服器和步进器-但是我始终使用DEACTIVATE_SERVOS_AFTER_MOVE进行测试，因为步进器移动时，我的伺服器抖动，在设置了伺服角后产生了SERVO_DELAY （几百毫秒）的暂停。相比之下，我建议延迟要短得多，这是性能上的胜利。

如果BL-Touch代码尝试同时移动伺服器和步进器，那对我来说我不喜欢打球。

因为BL-Touch想要持续提供伺服信号，所以DEACTIVATE_SERVOS_AFTER_MOVE是不可能的。对于由中断驱动的伺服库，延迟的中断将导致灾难性的后果，使伺服信号混乱。硬件驱动的PWM将不受干扰。通常我们只有一个伺服器。

但是，我很确定没有暂停的set_servo(0); set_servo(180); set_servo(0);绝对不会引起任何反应-既不在真正的伺服系统上，也不在BL-Touch上。

AnHardt 于 2020-07-16

抱歉。目前，我的想法可能主要集中在硬件PWM上，此时计时器比较寄存器只需要不时更新。

AnHardt 于 2020-07-16

抱歉。目前，我的想法可能主要集中在硬件PWM上，此时计时器比较寄存器只需要不时更新。

这个问题与硬件PWM有关，我同意您所说的一切，我只是在框架级别考虑问题，例如即使客户端应用程序进行了疯狂的更新，如何使硬件可靠地工作（Marlin ）。客户希望最后一次更新生效，而不是第一次生效，而且我无法得知在此期限结束之前不会进行后续更新。

我必须再次查看问题，以查看是否有新的解决方案出现，以及该诊断是否确实正确，而不仅仅是让我变得愚蠢。

p3p 于 2020-07-16

我会尝试
什么时候可以卖空，可以省略：

servo_update(angle) only updates a volatile variable lets say inter_angle.

an interrupt, either overflow or compare could be:
{  
  static uint32_t counter = 0;
  static uint16_t last_inter_angle = 0;
  if (counter++ > 3) { // if counter should overflow there is a small risk of delaying another 3*20 ms. Every ~55min if 16 bit.
    if (inter_angle != last_inter_angle) { // if counter above 3 the update will be immediate when inter_angle changed.
      update_shadow_compare_register(inter_angle);
      counter = 0;
      last_inter_angle = inter_angle;
    }
  }
}

大约每20毫秒运行一次。
那应该使输出脉冲长度恒定至少保持3 * 20 ms，然后仅置于最新的指令角度。但是，它不知道接下来要发生什么角度，或者根本不知道是否会进行更新-这是未知的-有些时候您必须开始。您保证可以读取发送脉冲，并且不经常更新影子寄存器。

为了保证每次更新至少在该时间内完成，必须将可变变量替换为队列。

在RC飞行中，中间位置可能会省略。在BL-Touch存放的情况下，部署，重置，changeing_modes，...同样重要。可以忽略这一点，每个命令不必停留足够长的时间才能被识别。通用伺服库没有通用解决方案。

此外，对于BL-Touch，所有命令都必须与步进器的移动同步。最好在下降探头时缩回探头。 :-)
因此，从我的角度来看，马林必须负责不更新频繁的角度。

编辑：
比较中断可能是更新影子比较寄存器的正确方法。然后，该中断可能会被较高优先级的中断延迟大约17ms，并且仍将及时使更新寄存器准备好在发生溢出时复制到比较寄存器。
如果计数器大于3，应该可以停止中断。可以在更新inter_angle时重新启动。

AnHardt 于 2020-07-16

我在SKR mini 1.1上遇到了同样的问题。
无论我放置在什么位置，伺服器始终都指向同一点。

https://www.youtube.com/watch?v=HVyaKdpJsP0