Marlin: [バグ] SKR v1.3（またはその他のLPC1768）：bltouchで問題を引き起こすサーボ信号の問題

本物のBLTouchを試すことができますか？

本物のBLTouchを試すことができますか？

また、 Configuration_adv.h BLTouch設定を調整してみましたか？： BLTOUCH_DELAY 、 BLTOUCH_FORCE_SW_MODE 、 BLTOUCH_FORCE_MODE_SETなどの設定を調整できます。

ああ、すみません、私は言及するのを忘れました。 もちろん、以前はBLTOUCH_DELAY 、 BLTOUCH_FORCE_SW_MODE 、さらにはDELAY_BEFORE_PROBINGさまざまな組み合わせを試しました。 成功せずに。
さて、私が見つけたのは、問題が何であるか、明らかです、より長い遅延は役に立たないということです。 bltouchをこのエラー状態にする間違った20msパルスは、ビルドプレートに触れる数秒前にすでに発生しているためです。
BLTOUCH_FORCE_MODE_SETは、この古いバージョンのbltouchクローンではサポートされていません。 それは「賢い」ものではありません。

いいえ、本物のBLTouchにアクセスできません。 私と私の古いクローンにとって、上記のハックは問題なく機能するので、個人的にはこの問題を適切に修正する必要はありません。 しかし、実際のサーボでさえ、このパルスに短い揺れやその他の奇妙な動作で反応する可能性があるため、この問題はとにかく修正する必要があると思います。

うわー、 @ mlehnhoff 、あなたのパッチは私の痛みを和らげます。 SKR v1.3 +（古いバージョンかどうかわからない）triaglelab 3dtouch-同じ問題。 私自身の8/10の動作条件：BLTOUCH_FORCE_SW_MODE + BLTOUCH_DELAY1000。ただし、パッチはSW_MODEとDELAYなしで10/10で動作します。 Tnx！

リアーム（同じMCU）でサーボベースのタッチプローブをテストしましたが、問題はありませんでしたが、移動後に非アクティブ化機能を使用しました。

私はそれなしで試していません、juseは必要のないときにサーボを非アクティブにする論理的に理にかなっています

私は本物のBLTouchをいくつか持っていますが、それらはすべてSKR 1.3で正常に動作します。SKR1.3もLPC1768です。

だからここで銃をジャンプします、それはおそらくハードウェアの問題（ワイヤー、ノイズ接続）またはユーザー設定の問題ですか？

ほとんどの追加のBLTouchコード/構成オプションと同じ理由で、これはBLTouchクローンの問題です。

3DTouch！= BLTouchであることに注意してください。 これらのコピーに関連する多くのクローズされた問題があります。

私はそれをハードウェアの問題と呼ぶでしょう、

はい、3dtouch（およびその他）はBLtouchではありません

私にとっての大きなQは、マーリンがクローンをサポートしているのか、それとも本物の製品だけを気にしているのかということです。

個人的に少し考えてみると、マーリンがクローンをサポートするのは公平だとは思わない

しかし、私は間違っている可能性があります、考え？

XXtouchの名前に関係なく、私の2セント。 それらのいずれかがSERVOSピンに接続します（BLtouch特殊ピンではありません）。 SERVOSはサーボのように機能するはずです。

しかし、実際のサーボでさえ、このパルスに短い揺れやその他の奇妙な動作で反応する可能性があるため、この問題はとにかく修正する必要があると思います。
（ @mlehnhoffコメントから）

これは、プローブハードウェアのせいにするべきではありません。 ボードから生成されている信号は正しくなく、オシロスコープを使用して検証されました。 それは修正されるべきです。

また、SKR Mini E3ボードで同様の問題を引き起こしているタイマーの競合をすべてデバッグしたときに、報告された動作が本物のBLTouchハードウェアと非常に似ていることも確認できます。 無効なパルス長は、BLTouchが何をしていたかを単に忘れて、失敗を引き起こしたように見えました。

@mlehnhoff 、この問題に添付できる、問題を示すオシロスコープからの画像をキャプチャしましたか？

完全な解決策として現在の回避策が好きではないと思いますが、問題を説明するために提供された詳細レベルと、パルスが問題の根本原因であることを示す回避策に本当に感謝しています。

申し訳ありませんが、スコープのスクリーンショットをすぐに提供しませんでした。 私はいくつか作ったと思いますが、何かがうまくいきませんでした。 しかし、スコープを返すまで気づきませんでした（私のものではありません）。
しかし今、私は新しいものを作りました：

写真では、1472µsから544µsへの移行が見られますが、最初の新しい

パルスは20544µsです。

さらに、実際のサーボを試しましたが、この問題は3dtouchや他のクローンだけに限定されないことが証明されています。

IMG_4677.zip

サーボは90°（中央のレバー）から0°（レバーダウン）に回転する必要がありますが、障害のあるパルスが発生すると、実際には最初は上昇してから下降します。

ちなみに、本物のbltouchには少なくとも8つの異なるバージョン（クラシックv1.0、v1.2、v1.3、スマートv1.0、v2.0、v2.2、v3.0、v3.1）があり、それらすべてが正しく機能するかどうかはわかっています;-)

別のヒントを次に示します。M280コマンドを手動で送信した場合、問題が発生する可能性はほとんどありません。 サーボ（ビデオで使用）を切り替えるスクリプトを作成しました。これにより、可能性が大幅に高まります。
Servo_toggle.gcode.txt

これは、BLTouchで発生している問題に関連しているのでしょうか。
USB経由でRe-ARMに電力を供給し、 M80を使用して12V電源をオンにします。 BLTouchに電力を供給する12V電源に接続された5V降圧コンバータがあるため、BLTouchは12V電源が作動するまで電力を供給されません。
ボードの電源が入ると、BLTouchが赤く点滅します。これは、BLTouchが電源を入れる前に信号を受信した場合、明らかに正常なことなので、心配していません。
ただし、 M280 P0 S160リセットしようとしても、まったく効果がありません。 展開されている場合、ピンを引っ込めることもありません。
ただし、 M280 P0 S60正常にSWモードに切り替わり、点滅も停止します。
点滅とS160明らかに無視されていることを除けば、BLTouchは完全に機能しているようです。 まばたきをしているときでも、適切に展開、収納、プローブします-私はフルベッドプローブを実行しましたが、プローブの故障は見たことがなく、再現性は優れています。
これは本物のV3.1BLTouchであり、クローンではありません。

安価なミニDSOと大きなCRTオシロスコープの両方でパルスをチェックしたことを忘れてしまいましたが、パルスの長さは問題ないようです。 また、リセットをトリガーする値を見つけることなく、さまざまなS値（155から165）を試しました。

LPCのサーボライブラリがどのように機能するかは調べていませんが、次のようになります。
サーボ信号はPWMです。 これがSTM32ハードウェアタイマーで実現される場合、このエラーは、比較レジスタのプリロードレジスタに新しい値を更新するのではなく、カウンタ比較レジスタを直接更新することによって発生する可能性があります。 カウンタが低い値と高い値の間にあるときに比較レジスタを高い値から低い値に変更すると、（等しい）比較はスキップされ、カウンタがオーバーランして新しい値に達するまでピンは変更されません。 。 プリロードレジスタが使用されている場合、カウンタがオーバーランしたとき、または（古い）比較値が一致したときに、比較レジスタが更新されます。 これには、大きなパルスのリスクはなく、最大で約1 PWM周期（20ms）の遅延が発生する可能性があります。
編集：エラーの可能性は、1ms後方にスキップするごとに5％になります。
ここに似たようなものがあると思います。

これは、lpcフレームワークがハードウェアpwmをラッチモード（パルス幅レジスタがシャドウされ、各周期でラッチインされる）で実行されていないためです。単純なモードビットでそれを実行できるはずですが、残念ながらできません。確実に動作させるために、1周期のグリッチが発生する可能性があるか、パルス幅がランダムに（ただし、更新の頻度に応じて非常に頻繁に）変化しないようにします。

この問題についてさらに調査することもできますが、それは実際には複雑な周辺機器ではありません。私はその不具合に長い時間を費やし、最終的に他のことに注意が必要でした。

@mlehnhoff @kockockockocパッチをどのように適用しますか？

@mlehnhoff @kockockockocパッチをどのように適用しますか？

正直なところ、私はgitにかなり慣れていないので、「gitdiff」を使用してこのパッチを作成できてうれしいです。 このパッチを適用し直すには、別のgitコマンドが必要だと確信しています。 たぶん@kockockockocが助けてくれるでしょう...
しかし、この非常に小さなコードフラグメントの場合は、手動で行うこともできます。 ファイル「Marlin / src / HAL / HAL_LPC1768 / Servo.h」（もちろん「+」なし）の表示位置に「+」で始まる4行を追加するのと同じくらい簡単です。

こんにちは。同じボードBigtreetechSKRv1.3と3DTouchを使用していますが、3DTouchが機能しません。 Arduino Megaのコードを使用して3dTouchをテストしましたが、完全に機能します。 だから、私は見つけた提案と@mlehnhoffパッチを3DTouchがフリーズします。 マーリンが開始すると、3Dタッチがセルフテストを実行し、ピンが収納され、変更なしで永久にこの状態に留まります（M43 Sまたはマーリンメニューから）
この問題を解決するために何をしなければならないのかわからないので、私はそれについて本当に心配しています。 どんな提案も歓迎します。

このバグは私がここで報告したものと同じだと思います： https ：

私はまだ問題なく6/22/19からバグ修正コミットを実行しています。 今日、最新のバグ修正コミットを試しましたが、サーボの問題はまだ存在しています。

@ Reywas62とすべて、私は問題を解決できるこの記事http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.htmlを見つけました。 どうやらいくつかのSKRボードは、適切に動作するためにかなりの量の電流を必要とする低インピーダンス（約200オーム）の出力信号を持っている可能性があります（そしてそれはArduinoボードでは起こりません、それが私の3Dタッチプローブが正しく動作する理由ですArduinoで）それで、どうやらそれはファームウェアとは関係ありません。

私のボードがMarlinbugfix 2.0.x（6/22/19）の以前のコミットで正常に動作することを除いて、私はその説明を購入します。

mlehnhoffの「 機能していることを確認できます。 BLTouchクローンを使用して9x9UBLメッシュをプローブします。 通常、メッシュ生成を実行すると、81ポイントメッシュの1つまたは2つのポイントが失敗します。 しかし、「修正」を使用すると、すべてが正常に機能します。 だから私はこのソリューションを使い続けます。 私の場合、プッシュピンが展開されていてセンサーがトリガーされないため、長いサーボパルスに問題があると思います。

3DTouchの問題が解決したことを確認したいと思います。 問題は、SKR1.3サーボピンの低電流です。 回路を作ってテストしました。 M43を実行した後、次の情報を受け取りました。
送信：M43 S
サーボプローブテスト
。 インデックスを使用：0、展開角度：10、収納角度：90
。 プローブZ_MIN_PIN：57
。 Z_MIN_ENDSTOP_INVERTING：false
。 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（または互換性のある）が検出されました

ここでセットアップを試してみますが、SG90とMG90の両方のサーボモーターがあり、断続的に無効に戻ります。 Z-Probeスイッチを保持しているので、ベッドに衝突したときにマシンを殺します。 前回のクラッシュは、Creality CR10S5のホイールマウントの合計でした。 > _

機会があれば、回路を試して、それがうまくいくかどうかを確認します。 ファームウェアハックも試してみます。 :)

ファームウェアハックを試した後、私には何の変化もありませんでした（私が思ったように、ハックはbl-touchクローンを修正するので、必ずしもサーボの動きではありません）。 サーボは、移動を完了した後、さらに後方に移動することがありました。

それを考慮して、私はハックを元に戻し、サーボを無効にしないようにマーリンに言いました、そしてそれは後退の問題がなくなったようです。 サーボを無効にすると問題が発生するようです。 幸い、私が使用しているMG90は、選択した角度で​​振動/揺れを示しません。 :)

私は間違いなくmlehnhoffのgcodeをテストしてくれたことに感謝したいと思います。 実行するたびにサーボが3〜4回再生され、marlinにサーボを有効にしておくように指示すると、スクリプトは3回続けて正常に実行されました。 低電流の報告を考慮して、ヒーターをオンにしてテストを実行し、PSUに負荷をかけました。 :)

それが重要かどうかはわかりませんが、私のサーボ角度は172（展開）と35（収納）であり、毎回同じ量だけサーボを後方に動かすように見えました。 サーボは決して前進しませんでした。

ファームウェアハックは私の問題を修正しませんでしたが、サーボを有効のままにしておくと、DarkAlaranthの場合と同様に、サーボの誤動作が防止されます。 実際には修正ではありませんが、許容できる回避策です。

少し余分な背景過去数日間にいくつかのプラットフォームでこれを試しましたが、AntLab BLtouchの両方が壊れている可能性があると思ったので、3つ目を注文しました。

これが私が以下のプラットフォームで観察したものです
SKR ProV1.1が機能しない
SKRv1.3が機能しない
RAMPS1.4が機能しない
SKRv1.4が機能しない
RAMPS1.6が機能しない

M119で読み取りをプローブする前の症状
エンドストップステータスの報告
x_min：トリガー済み
y_min：トリガー済み
z_min：トリガー済み

ピンファイルも調整しましたが、同じ結果になりました。

これが私が様々なマーリンヴィンテージのいくつかのビデオで使用したプロセスです
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タッチの電源設定が多数含まれています。

Z軸をホーミングするときにレポート温度が必要ですか？
デバッグは次のとおりです。
送信済み：G28 Z0
送信：M114
送信済み：M105
RECV：エラー：!! BLTouchエラーのためにSTOPが呼び出されました-M999で再起動してください
[エラー]エラー：!! BLTouchエラーのためにSTOPが呼び出されました-M999で再起動してください

RAMPS 1.6 / MEGA2560上のM119
z-minで開くために正しい読み取り
プロービングが機能していないようです。

この問題があります。
Ender 3、SKR Mini E3 v1.2、純正BLTouch v3.1

V2で問題なく動作します
skr1.3の配線はストックの向きとは異なります。 Marlin2.0.1のリリースバージョンを使用しています

別のBLTouchを試すことはできますか？ プローブが損傷していないことを確認するには？

いいえ、ごめんなさい。 私は通常のBLTouchしか持っていません。 障害は約200分の1にのみ発生します。

@mlehnhoff時間が取れたら、再テストしてください

バグ修正2.0.xは毎日更新されるため、14日ごとに再テストしてください。

最新のバグ修正ビルド[2020.01.24]を再コンパイルしました。
それぞれ150の2つのプローブ再現性テストを行いました。

1. ベッドの暖房がオフ、正常に終了、標準偏差：0.003928。
2. ベッド暖房ON、プロービング失敗、137で失敗。

クローンBLTouch（3DTouch）を備えたSKR1.1ボード（LPC1768）でバグ修正2.0.xを使用した場合にも、同様の動作が見られました。
さまざまな回避策を試しましたが、25のプローブポイントのうち、少なくとも1つのプローブポイントでは、ピンの解放が早すぎます（展開の直後に収納するなど）。

@mlehnhoff時間が取れたら、再テストしてください

@boelle ： @ p3pで前述したように、問題は実際にはMarlin自体ではなく、LPCフレームワークにあるため、再テストは必要ありません。 彼は、PWMラッチモードが適切に機能しなかったため、コメントを解除する必要があると述べました。 したがって、これが修正されない限り、確実に機能するbltouchが必要な場合は、私の醜いが回避策を使用する必要があります。
現時点では、残念ながらオシロスコープにアクセスできません。それ以外の場合は、この問題のデバッグでP3Pをサポートしたいと思います。 他の誰かがこれをさらに深く掘り下げたい場合は、遠慮なく： https ：

この問題があります。
Ender 3、SKR Mini E3 v1.2、純正BLTouch v3.1

SKR Mini E3 v1.2は、LPC1768ではなくSTM32マイクロコントローラーを使用します。

PWMのラッチに関する問題は、次のLPC176xエラッタに関連しているのでしょうか。

3.13 PWM.1：PWM1.1のデューティサイクルを100％から更新する場合、
場合によっては、出力がPWM期間全体にわたってローのままになることがあります。
更新が有効になります
前書き：
LPC176x PWMペリフェラルでは、2つのマッチレジスタを使用して1つのマッチレジスタを提供できます。
エッジ制御PWM出力。 1つのマッチレジスタ（PWM1MR0）がPWMサイクルを制御します
一致時にカウントをリセットすることによるレート。 もう一方のマッチレジスタはPWMエッジを制御します
ポジション。 例として、マッチレジスタPWM1MR1はPWM1のエッジ位置を制御します。
複数のシングルエッジ制御PWM出力はすべて、最初に立ち上がりエッジがあります。
PWM1MR0の一致が発生したときの各PWMサイクル。
問題：
シングルエッジモードでのみ、PWM1.1のデューティサイクル（パルス幅変調器1、チャネル）
1出力）が100％（PWM1MR1 = PWM1MR0）から更新され、次にPWM1.1の出力が更新されます。
新しい望ましいデューティサイクルの前に、PWM期間全体にわたって予期せずローのままになる可能性があります
有効になります。 この問題は、PWM1.1の出力にのみ影響します。 その他のPWMチャネル
（PWM1.2からPWM1.6）はこの問題の影響を受けません。
回避策：
ユーザーがPWM1MR1をロードできるソフトウェア修正を実装できます。
PWM1.1の出力更新の遅延を回避するためのPWM1MR0 + 1（少なくとも1）。

サーボピンを100％PWMモードにすることはないと思うので、そうではないと思います。

次に、PWM 1.1では、SKR1.3のサーボピンであるP2_0に使用されます。

私は同様の問題を調査しています（純正のBL Touch3.1とSKRPRO 1.1を使用）。
＃16986で見つけたものを文書化しましたが、基本的には、私のものがXY_PROBE_SPEEDに関連していることがわかりました。 10000の数字は、BL Touch信号を15プロービングポイント（最初のY移動後の最初のプローブポイントでもあります）でパルスからDCレベルに変更します。6000の数字は問題を示しませんでした。

この回避策は、SKRv1.3と3DTouch v2（およびPi 3B）を搭載した2つのEnder3で1か月以上テストしました。 以前は、ABL（3〜5回の印刷に少なくとも1回）を実行すると、プローブがトリガーされず（ただし、すぐに赤く点滅）、ノズルがベッドに衝突するという定期的な障害が発生していました。 -わざと立ち去った。 そして、Marlin2.0.xのプロービング/ BLタッチ構成のすべてではないにしてもほとんどの順列を試しました。
これらの週の数え切れないほどのプロービング（M48と多くの実際のプリントの両方）で失敗がなかったので、私の場合、この回避策は明らかに成功したと見なす必要があります。 もちろん、結果が変わった場合は、調査結果を更新します。
また、XYプローブ速度（6-8-10000 mm / sを試した）、Zプローブ速度に関係なく、プローブ中にヒーター/ステッパーを無効にせずに動作することもテストしました。 基本的に、Marlinでのプロービングのセットアップは、障害を回避するための要因ではなくなったようです（ただし、少なくともZ速度は精度に影響を与える可能性があります）。
唯一の問題は、LCDのバックライト（5V）がSKRから引き出されている場合、プローブ中に一時的に点滅することです。これは、プローブの消費電流による電圧降下を示している可能性があります（ただし、スコープですべてを分離してプローブしたくありませんでした）。 。 したがって、代わりに5VをPiに配線し（ただし、外部5Vソースでもかまいません）、プローブの近くで2本のGNDワイヤーを接続し、1本はSKRに接続し、もう1本はPiに接続しました（貧乏人のスターグラウンド用）。 。

@mlehnhoff
bugfix-2.0.xブランチをテストして、それがどこにあるかを確認してください。

間もなく本物のBLTouchでこれをテストしますが、同じ問題があると思います。

編集：同じボード（STM32F103RC）ではありませんが、同じ問題です！ それがタイミングの問題か何か他のものかどうかを理解しようとしています！ しかし、91 UBLメッシュを実行すると、ここで説明したのと同じ方法で、おそらく1つまたは2つのプローブが失敗しますか？

ボードが「共有」サーボコードを使用しているようだとわかりました。 試行錯誤の末、以下を追加しましたが、safe_delayが6ms / usのようです。 仕事中！ それが理にかなっている場合、センサーはより速くトリガーするようですか？ そして、センサーが故障することなく最初のメッシュを取得することができましたか？ それを監視し、より多くのテストを実行しますが、最初は有望に見えます！ これは本物のBLTouchで、故障だと思って2つ目を注文しました。 このセットアップは元のストックボードで正常に機能していたため、他のハードウェアはないと思います。BTTV2.0に移行し、Marlinでこの問題が発生したためです。 以前は、問題なくKlipperを実行していました。

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

@ aslater3ボード（SKR Mini E3 v1.2）に「共有」サーボコードがあるかどうかを確認するにはどうすればよいですか？

@boelle申し訳ありませんが、私はさまざまなことにかなり忙しかったです。 最新のバグ修正-2.0.x（2.0.5.4のようです）をテストしました。 問題はまだ存在しています。 これは、pio-framework-arduino-lpc176xではまだ修正されていないためです。
しかし、私はオシロスコープにアクセスできるようになりました。これをさらに調査して（そして最終的には修正して）喜んでいます...

2.0.5.4 （ 2.0.x ）とbugfix-2.0.xは2つの異なるブランチです。 最新のbugfix-2.0.xを試して、この問題が引き続き発生するかどうかをお知らせください。

2.0.5.4 （ 2.0.x ）とbugfix-2.0.xは2つの異なるブランチです。 最新のbugfix-2.0.xを試して、この問題が引き続き発生するかどうかをお知らせください。

はい、わかっています。最新のバグ修正2.0.xを使用しました。 2.0.5.4はLCDメニューが教えてくれることだけです

しかし、これはとにかく問題ではありません。バグはMarlinFwコード内になく、pio-framework-arduino-lpc176x内にあるからです。

コードのどの部分が問題を引き起こしているのか、つまりHW-PWMのラッチが無効になっていることもよく知られています。

問題は、他の問題を起こさずにラッチを再度有効にする方法を見つけることです。 これが、ラッチが無効になっている理由です。

他のプラットフォームでも同様の問題を調査しているので、これについて@ p3pとチャットしていました。 この動作が変更された可能性はないと思います。実際に永続的なソリューションを実装する一環でない限り、今すぐ再テストする価値はありません。

2.0.5.4はLCDメニューが教えてくれることだけです

次に、最新のバグ修正を使用していません。 LCDにはbugfix-2.0.xます。

新しい一致値をすでに通過した後、より短いデューティサイクルを設定すると、1周期の不具合が発生することを認識しています。現在、この問題を軽減する方法がわかりません。 ハードウェアは、pwmシャドウレジスタが有効になっている場合に想定されていることを実行していないようです。

2.0.5.4はLCDメニューが教えてくれることだけです

次に、最新のバグ修正を使用していません。 LCDにはbugfix-2.0.xます。

さて、私の悪い、私は誤ってバグ修正-2.0.xの代わりにブランチ2.0.xを複製しました...今私はそれを修正しました->違いはありません（もちろん）

新しい一致値をすでに通過した後、より短いデューティサイクルを設定すると、1周期の不具合が発生することを認識しています。現在、この問題を軽減する方法がわかりません。 ハードウェアは、pwmシャドウレジスタが有効になっている場合に想定されていることを実行していないようです。

@ p3pラッチを有効にしたときに、どのような問題が発生したか教えてください。

私が覚えていることから（これをデバッグしてから長い時間が経ちました）、シャドウレジスタを有効にすると、パルス幅が散発的にまったく更新されませんでした。これではなく、1周期のグリッチを選択したことが想像できます。 同じ期間にパルス幅を複数回更新したことが原因のようですが、よくわかりませんでした。

指令されたサーボ角度は、変更されたパルス幅として出力に表示されるために、少なくとも20ミリ秒を維持する必要があります。
新しいパルス幅をデバイス/サーボで認識できるようにするには、いくつかのパルスを維持する必要があります。
したがって、少なくとも20ミリ秒以内に角度を変更することは禁止する必要があります。
@sjasonsmithがBL_Touchについて見つけ、 https： //github.com/MarlinFirmware/Marlin/issues/18598#issuecomment-657406598で指摘したことから約60ミリ秒。

シャドウレジスタをより頻繁に更新しても意味がありません。 レジスタは、角度値が変化するよりも頻繁に書き込まれるべきではありません。 （シャドウレジスタのシャドウ変数？）
頻繁な変更を防ぐために、サーボライブラリの上位レベルに追加のパッチが必要になる可能性があります。 SERVO_DELAYに似たものがすでにあります。これは、元々、サーボが（機械的に）ターゲットに到達する前にサーボ信号がシャットダウンするのを防ぐためのものです。

@AnHardtシャドウレジスタを期間ごとに複数回変更しても意味がないことは知っていますが、期間終了時に値が実際のレジスタにプッシュされる前にシャドウレジスタを複数回変更すると問題が発生する理由がわかりません。何が原因かわかりません。クライアントアプリケーションがハードウェアPWMを頻繁に更新するのを停止するための解決策は、（それが本当に問題である場合）とにかく何らかの形で重大なパフォーマンスの低下を伴わないことです。

@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_angleを設定した後、 SERVO_DELAY （数百ミリ秒）の一時停止が発生しました。 それと比較して、私が今提案しているはるかに短い遅延は、パフォーマンスの向上です。

BL-Touchコードがサーボとステッパーを同時に動かそうとすると、ボールをプレイしなければならないように感じません。

BL-Touchesは常にサーボ信号をオンにしたいので、 DEACTIVATE_SERVOS_AFTER_MOVEは不可能です。 割り込み駆動のサーボライブラリの場合、遅延割り込みは壊滅的になり、サーボ信号を台無しにしました。 ハードウェア駆動のPWMは影響を受けません。 通常、サーボは1つしかありません。

ただし、一時停止のないset_servo(0); set_servo(180); set_servo(0);は、実際のサーボでもBL-Touchでも、まったく反応を引き起こさないと確信しています。

ごめんなさい。 おそらく私の考えはハードウェアPWMに焦点を当てているようです。現時点では、タイマーがレジスタを比較するだけで、時々更新する必要があります。

ごめんなさい。 おそらく私の考えはハードウェアPWMに焦点を当てているようです。現時点では、タイマーがレジスタを比較するだけで、時々更新する必要があります。

この問題はハードウェアPWMにあり、あなたが言ったことすべてに同意します。クライアントアプリケーションが大量の更新を行っている場合でもハードウェアを確実に機能させる方法のように、フレームワークレベルで問題を考えていました（Marlin ）同じ期間に。 クライアントは、最初の更新ではなく最後の更新が有効になることを期待します。期間が終了する前に後続の更新が行われないことを私は知る方法がありません。

新しい解決策が思い浮かぶかどうか、そしてその診断が実際に正しく、私が愚かではなかったかどうかを確認するために、問題をもう一度見直す必要があります。

やってみます
持続する位置を短くするタイミングは省略できます。

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ミリ秒一定に保たれ、最新のコマンド角度のみが入力されます。 ただし、次にどの角度が来るのか、または更新がまったく続くのかどうかはわかりません-それを知ることは不可能です-いつ開始する必要があるかはわかりません。 送信パルスを読み取ることができ、シャドウレジスタが頻繁に更新されないことが保証されます。

すべての更新が少なくともその時間行われることを保証するには、揮発性変数をキューに置き換える必要があります。

RCフライングでは、中間位置を省略できる可能性があります。 BL-Touchの収納、展開、リセット、changeing_modesの場合、...すべてが等しく重要です。 これに注意することは省略できます、すべてのコマンドは認識されるのに十分長くとどまらなければなりません。 ユニバーサルサーボライブラリには、ユニバーサルな正しいソリューションはありません。

さらに、BL-Touchの場合、すべてのコマンドがステッパーの動きと同期している必要があります。 プローブのために降りている間にプローブを引っ込めるのは省略したほうがよいでしょう。 :-)
したがって、私の観点からは、マーリンは角度を頻繁に更新しない責任があるはずです。

編集：
おそらく、比較割り込みは、シャドウ比較レジスタを更新するのに適切な割り込みです。 その後、割り込みは、優先度の高い割り込みによって約17ミリ秒遅延する可能性がありますが、オーバーフローが発生したときに、更新レジスタを比較レジスタにコピーする準備ができています。
カウンタが3を超えている場合、割り込みを停止できるはずです。inter_angleが更新されたときに再起動できますか。

SKR mini1.1でも同じ問題が発生しています。
どの位置に置いても、サーボは常に同じポイントに移動します。

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

@Matheusschmitz SKR miniは別のプラットフォームを使用しており、この問題とは異なります。 STM32F1ボード（あなたのような）のBLTouchの信頼性を向上させるために、1週間ちょっと前にいくつかの変更が行われました。 bugfix-2.0.xブランチを使用して、問題が解決するかどうかを確認してください。

それでも問題が解決しない場合は、Discordなどのサポート会場で話し合ってください。 この特定の問題は、LPC176xボードに引き続き焦点を当てる必要があります。

また、SKR1.3とBLTouchクローンでこの問題が発生しました。
私はそれをビデオでキャプチャすることができました、ちょうど1:54マークのあたり：
https://www.youtube.com/watch?v=wF0Mia49ECI&t=114s
（ビデオは1080pですYouTubeはそれを処理する必要があります）

これは、UBL中に発生した場合の動作を示す画像でもあります

他の人と同じように、役立つさまざまな設定を試しましたが、役に立ちませんでした。
私は最新のバグ修正-2.0.xブランチを使用しています

私の側でも同じ問題。
回避策もテストします

この問題は過去30日間活動していません。 この問題をアクティブな状態に保ちたい場合は、返信を追加してください。そうしないと、7日以内に自動的にクローズされます。

恒久的な解決策が見つかるまで、これはオープンにしておく価値があると思います。

私はその感情に同意します

この問題は過去30日間活動していません。 この問題をアクティブな状態に保ちたい場合は、返信を追加してください。そうしないと、7日以内に自動的にクローズされます。

この問題は未解決のままにしておくべきだと思います。