我最近在我的 dibond Mendel90 w/Panelolu2（我自己的 Marlin tho 分支）上也看到了这一点，我尝试将 BLOCK_BUFFER_SIZE 增加到 64，但它似乎没有帮助。在注意到这之前我唯一改变的是启用固件收回，但我不能确定它以前是否发生过，我还没有尝试禁用它。它似乎与打印的复杂性无关，即使是简单的几何形状打印也会触发此问题。

使用 slic3r 并以 45 或 50mm/s 的恒定速度打印，同时使用 .20mm 和 .10mm 层。

我没有启用固件回收，所以我们可以消除它。

我觉得有趣的是，feedmultiply 似乎是一个可以通过 GCode 或通过 LCD 面板修改的设置，但我在代码中看到了几个实例，在某些操作之前/之后，它的值被保存和恢复。

如果这是必需的，那么 feedmultiply 可能在需要这种特殊保存/恢复处理的其他地方被修改。

我不知道这个问题是否是由于连接了 Panelolu2 而发生的，或者它是否一直发生但在没有显示器的情况下是不可见的。我原以为即使没有连接显示器，在长时间打印时测得的减速程度也会很明显。

值得测试的是在减少后将 feedmultiply 增加回 100%。我有一个想法，完成后它可能会保持在 100%。这是基于对一张印刷品的观察。我将不胜感激关于是否确实如此的反馈。

很难说有面板还是无面板，但我距离打印只有 3.5 毫米[1]，它已经决定放慢到 99%。我没有看到任何让我认为它应该放慢速度的印刷品，我的 minsegment 时间默认为 20000 毫秒。我想也许填充部分可能是问题的一部分，因为它们以 45mm/s 的速度打印，但我已经使用这些速度很长一段时间了，直到最近才注意到这种减速影响了我。

查看 planner.cpp，导致速度下降的代码似乎多年来没有改变，看起来非常简单。真的不确定为什么/发生了什么变化，开始怀疑 Slic3r 是否以某种方式负责。简单的“修复”是通过 m205 禁用减速或减少 minsegmenttime（此打印仅设置为 10000ms），但我不确定这是否会解决问题或只是进一步创可贴并增加如果缓冲区为空则停止的风险.

[1]
https://drive.google.com/file/d/0B25LBca0qlnuNVN0a3Z5b09xYTQ/edit?usp=sharing

我认为这与切片器无关（我使用 Skeinforge）。

呵呵，好吧，至少在那时可以排除这种可能性。

在 23 毫米标记附近再次减速至 99%。通过 LCD 将其重新启动，我们将看看它是否继续坚持它应该变慢。

你们都检查过编码器引脚上的噪音了吗？

或者也许添加滴答声作为编码器被感知为旋转的反馈？

我假设你们都使用短电缆而不是长电缆。

斯科蒂

2014 年 3 月 9 日下午 3:07，Matthew Schick notifications@github.com写道：

在 23 毫米标记附近再次减速至 99%。通过 LCD 将其重新启动，我们将看看它是否继续坚持它应该变慢。

—
直接回复此电子邮件或在 GitHub 上查看。

正要发布同样的东西。
在 pins.h 中将编码器引脚设置为 -1，以从等式中消除编码器。

有道理，可能是这个周末我才能再次测试。谢谢！

这似乎已经解决了。我尝试在 pins.h 中将编码器引脚设置为 -1，但它无法编译，所以我只是注释掉了 ultralcd.cpp 中的相关代码，现在我已经进行了 10.5 小时的打印，没有减速的迹象。我提交了 pull request #833来使 feed multiplier 控件也成为可选的。

真的不确定这种噪音是从哪里来的，也不知道为什么它最近似乎突然出现了。我使用的是套件随附的备用电缆，硬件方面没有任何重大变化。现在我只想让控件处于禁用状态。

既然您已经确定了问题，那么您可以使用多种解决方案。

一个建议的根，用于开始研究您想要使用的解决方案。

http://en.wikipedia.org/wiki/Active_EMI_reduction

如果我的编码器发生这种情况，小值电容器将是我的首选。

斯科蒂

2014 年 3 月 12 日下午 5:18，Matthew Schick notifications@github.com写道：

这似乎已经解决了。我尝试在 pins.h 中将编码器引脚设置为 -1，但它无法编译，所以我只是注释掉了 ultralcd.cpp 中的相关代码，现在我已经进行了 10.5 小时的打印，没有减速的迹象。我提交了 pull request #833来使 feed multiplier 控件也成为可选的。

真的不确定这种噪音是从哪里来的，也不知道为什么它最近似乎突然出现了。我使用的是套件随附的备用电缆，硬件方面没有任何重大变化。现在我只想让控件处于禁用状态。

—
直接回复此电子邮件或在 GitHub 上查看。

它本身可能不是噪音。但围绕信号转换抖动。固件不对编码器输入进行过滤（尽管通过 I2C 而不是直接读取编码器引脚可能会有所帮助）因此可能有一些范围可以在软件中修复此问题。

这是相当于反弹的编码器，而不是抖动。

1. 我不确定它是怎么发生的，除非你一直将编码器轴留在“不方便”的位置（即恰好在“点击”的边缘），并且
2. 我不确定您如何区分不需要的过渡和想要的过渡——两种情况下的占空比都不固定。

您可以进行过滤，以便在特定时间范围内需要两次转换才能接受输入，但这会使编码器看起来反应迟钝且挑剔（您需要快速将其移动两个定位器，然后从“空闲”位置返回一个定位器）。

此外，在调整菜单中的值和遍历菜单系统时，所有这些通常都是无关紧要的。这只是状态屏幕上的一个问题，因为从那里控制进给率倍增器的 UI 决定非常可疑。

如果它是任何一条线上的正交编码器噪声，则只会使其
偏离 +1 或 -1，然后再次返回。很难看出它如何
只在一个方向上前进，除非机械振动实际上是在
旋转编码器。

2014 年 3 月 13 日 13:26，Ante Vukorepa notifications@github.com写道：

这是相当于反弹的编码器，而不是抖动。

1. 我不确定它是怎么发生的，除非你一直把编码器轴放在一个“不方便”的位置（即就在 “咔嗒”
   的边缘），并且
2. 我不确定您如何区分不需要的过渡和想要的
   过渡——两种情况下的占空比都不固定。

您可以进行过滤，以便在特定
时间范围内需要两次转换才能接受输入，但这会使编码器看起来
反应迟钝且挑剔（您需要快速将其移动两个定位器，然后
从“空闲”位置返回一个定位器）。

此外，在调整菜单中的值和遍历菜单系统时，所有这些通常都是无关紧要的。这只是状态屏幕上的一个问题，因为 从那里控制进给率倍增器
的 UI 决定非常可疑。

直接回复此电子邮件或在 GitHub 上查看它 https://github.com/ErikZalm/Marlin/issues/825#issuecomment-37532045
。

谁说它必须在一条线上？
如果它是诱发的，则可能两者兼而有之。

正如关于这些面板多次指出的那样，通过这些扁平电缆传输的任何信号都没有适当的 ESD/EMI 保护。

抵抗者 caps chokes shielding all tweak the edges of the signals 并且在这里讨论这个大话题似乎不适合其他希望跟踪 git pull 请求问题的列表成员。

在软件方面，这些电路靠幸福之路的恩典工作，并且由于缺乏对极端情况的尊重和良好的异常处理而变得脆弱。

很可能是未知因素扰乱了这个特定的人的面板，使其偏离了之前的快乐路径，这很可能是对编码器轴的 ESD 冲​​击（它让很多操作员走过去，毕竟第一次接触它）被转移到MCU 并轻度损坏 MOSFET，使其阈值足以使该输入引脚更容易受到已经存在的噪声的影响。

ESD 的发生水平低于“静电冲击”，会对未受保护的电路造成损坏。这种伤害通常是我上面建议的较轻的形式，例如僵尸而不是尸体造成的。

小值电容器，就像我暗示的那样，有助于防止这种形式的 EMI/ESD。

新的 MakiBox 开发板和显然 Erik 的 ARM 开发板是声称解决这个长期被忽视的问题的两个开发板示例。但这样做会增加电路板 BOM、PCB 尺寸和成本以及爱好者的组装时间。

如果你打开一台 Stratasys 或 3D Systems 价值超过 60,000 美元的 3D 打印机，你将不会发现操作员触摸的旋转光学编码器输入设备直接挂在 MCU 上。事实上，您不会发现任何未受保护的电路板引脚。通过 FCC/CE 测试需要确保您已经敲掉了那些进入连接到板上的漂亮小天线的方形数字信号的硬角。

我很确定这里“最简单的解决方法”是用一个全新的芯片替换 AVR 芯片。最好的修复方法是通过给它们加壳来添加一些组件，这将有助于使 AVR 跛行并防止其受到进一步损坏。

斯科蒂

PS Erik，你的板子什么时候发货？？？:-)

2014 年 3 月 13 日上午 6:26，Ante Vukorepa notifications@github.com写道：

这是相当于反弹的编码器，而不是抖动。

1. 我不确定它是怎么发生的，除非你一直把编码器轴放在一个“不方便”的位置（即就在“咔嗒”的边缘），并且
2. 我不确定您如何区分不需要的过渡和想要的过渡——两种情况下的占空比都不固定。

您可以进行过滤，以便在特定时间范围内需要两次转换才能接受输入，但这会使编码器看起来反应迟钝且挑剔（您需要快速将其移动两个定位器，然后从“空闲”位置返回一个定位器）。

此外，在调整菜单中的值和遍历菜单系统时，所有这些通常都是无关紧要的。这只是状态屏幕上的一个问题，因为从那里控制进给率倍增器的 UI 决定非常可疑。

—
直接回复此电子邮件或在 GitHub 上查看。

我还想知道这是否与提交8d162e5中的 ENCODER_PULSES_PER_STEP 更改为 4 有任何关系，该时间与我开始注意到该问题的时间一致。虽然这个改变确实让编码器在其他方面的使用变得更好，所以我不想恢复它，但我最好的猜测是加上噪音是我们来到这里的原因。

It would surprise me if this was a hardware only issue given the number of
encoder/screen controllers out there (Panelolu2 and others).