Marlin: [BUG] SKR v1.3 (oder ein anderer LPC1768): Problem mit Servosignalen, die Probleme mit bltouch verursachen

Können Sie ein echtes BLTouch ausprobieren?

Können Sie ein echtes BLTouch ausprobieren?

Haben Sie auch versucht, die BLTouch-Einstellungen in Configuration_adv.h anzupassen ?: Sie können Einstellungen wie BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE , BLTOUCH_FORCE_MODE_SET usw. anpassen.

Oh, sorry, ich habe vergessen zu erwähnen. Natürlich habe ich vorher verschiedene Kombinationen von BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE und sogar DELAY_BEFORE_PROBING ausprobiert. Ohne Erfolg.
Nun, da ich herausgefunden habe, was das Problem ist, ist klar, dass längere Verzögerungen nicht helfen. Denn der falsche 20-ms-Impuls, der den bltouch in diesen Fehlerzustand bringt, tritt bereits einige Sekunden vor dem Berühren der Bauplatte auf.
BLTOUCH_FORCE_MODE_SET wird von dieser alten Version des bltouch-Klons nicht unterstützt. Es ist kein "kluger".

Und nein, ich habe keinen Zugang zu einem echten BLTouch. Für mich und meinen alten Klon funktioniert der oben erwähnte Hack einwandfrei, daher brauche ich persönlich keine richtige Lösung für dieses Problem. Aber ich denke, dass dieses Problem sowieso behoben werden sollte, weil ich denke, dass sogar ein tatsächliches Servo möglicherweise mit einem kurzen Schütteln oder einem anderen seltsamen Verhalten auf diesen Puls reagieren könnte.

Wow, @mlehnhoff , dein Patch

Ich habe eine servobasierte Berührungssonde an einem Re-Arm (dieselbe MCU) getestet und hatte keine Probleme, aber ich habe die Funktion zum Deaktivieren nach Bewegung verwendet.

Ich habe es nicht ohne versucht, juse machte logisch Sinn, das Servo zu deaktivieren, wenn es nicht benötigt wird

Ich habe eine Handvoll echter BLTouches und alle funktionieren gut mit einem SKR 1.3, der ebenfalls LPC1768 .

Ist es also höchstwahrscheinlich ein Hardwareproblem (Kabel, Rauschverbindung) oder ein Problem mit der Benutzerkonfiguration?

Der gleiche Grund für die meisten zusätzlichen BLTouch-Code- / Konfigurationsoptionen ist ein BLTouch-Klonproblem.

Denken Sie daran, dass 3DTouch! = BLTouch. Es gibt viele geschlossene Probleme im Zusammenhang mit diesen Kopien.

Ich würde es dann ein Hardwareproblem nennen,

yep ich jetzt 3dtouch (und andere) sind keine BLtouch

Das große Q für mich ist, was auch immer Marlin die Klone unterstützt oder ob wir uns nur um die Originalprodukte kümmern?

Ich denke nicht, dass es fair ist, dass Marlin die Klone unterstützt

aber ich könnte mich irren, gedanken?

Meine zwei Cent, egal wie der Name von XXtouch lautet. Jeder von ihnen wird an den SERVOS-Pin angeschlossen (nicht an den BLtouch-Spezial-Pin). Das SERVOS sollte wie ein Servo funktionieren.

Aber ich denke, dass dieses Problem sowieso behoben werden sollte, weil ich denke, dass sogar ein tatsächliches Servo möglicherweise mit einem kurzen Schütteln oder einem anderen seltsamen Verhalten auf diesen Puls reagieren könnte.
(aus @mlehnhoff Kommentar)

Dies sollte nicht auf die Sondenhardware zurückgeführt werden. Das von der Karte erzeugte Signal ist falsch und wurde mit einem Oszilloskop überprüft. Das sollte behoben werden.

Ich kann auch bestätigen, dass das gemeldete Verhalten der echten BLTouch-Hardware sehr ähnlich ist, als ich all diese Timer-Konflikte debuggte, die ähnliche Probleme auf SKR Mini E3-Karten verursachten. Ungültige Pulslängen schienen dazu zu führen, dass der BLTouch einfach vergaß, was er tat, und Fehler verursachte.

@mlehnhoff , haben Sie Bilder von Ihrem Oszilloskop aufgenommen, die das Problem demonstrieren, das Sie diesem Problem

Ich glaube nicht, dass mir die aktuelle Problemumgehung als vollständige Lösung gefällt, aber ich schätze den Detaillierungsgrad, den mlehnhoff zur Beschreibung des Problems und der Problemumgehung, die zeigt, dass der Puls anscheinend die Hauptursache des Problems ist, sehr.

Entschuldigung, dass ich nicht sofort einen Screenshot des Bereichs bereitgestellt habe. Ich dachte, ich hätte welche gemacht, aber etwas ging schief. Aber ich habe es nicht bemerkt, bis ich das Zielfernrohr zurückgegeben hatte (es ist nicht meins).
Aber jetzt habe ich eine neue gemacht:

Auf dem Bild sehen Sie den Übergang von 1472µs zu 544µs, aber den ersten neuen

Puls ist 20544µs.

Außerdem habe ich ein echtes Servo ausprobiert und hier ist der Beweis, dass dieses Problem nicht nur auf 3dtouch oder andere Klone beschränkt ist.

IMG_4677.zip

Der Servo sollte sich von 90 ° (Hebel in der Mitte) auf 0 ° (Hebel nach unten) drehen, aber wenn der fehlerhafte Impuls auftritt, dreht er sich zuerst, bevor er nach unten dreht.

Übrigens gibt es mindestens acht verschiedene Versionen von echtem bltouch (klassisch v1.0, v1.2, v1.3, smart v1.0, v2.0, v2.2, v3.0, v3.1) und Nr man weiß, ob alle richtig funktionieren ;-)

Hier ist ein weiterer Hinweis: Wenn Sie den M280-Befehl manuell senden, ist es sehr unwahrscheinlich, dass das Problem auftritt. Ich habe ein Skript zum Umschalten des Servos (im Video verwendet) geschrieben, das die Wahrscheinlichkeit erheblich erhöht:
servo_toggle.gcode.txt

Ich frage mich, ob dies mit einem Problem zusammenhängt, das ich mit meinem BLTouch sehe.
Ich schalte meinen Re-ARM über USB ein und benutze M80 , um das 12-V-Netzteil einzuschalten. An das 12-V-Netzteil ist ein 5-V-Abwärtswandler angeschlossen, der das BLTouch mit Strom versorgt, sodass das BLTouch erst mit Strom versorgt wird, wenn das 12-V-Netzteil einschaltet.
Wenn das Board eingeschaltet wird, blinkt das BLTouch rot - dies ist anscheinend etwas normal, wenn das BLTouch vor dem Einschalten ein Signal erhält, daher mache ich mir darüber keine Sorgen.
Jeder Versuch, es mit M280 P0 S160 hat jedoch absolut keine Auswirkungen. Der Stift wird auch nicht zurückgezogen, wenn er eingesetzt wird.
M280 P0 S60 erfolgreich in den SW-Modus und stoppt auch das Blinken.
Abgesehen davon, dass das Blinken und S160 anscheinend ignoriert werden, scheint das BLTouch perfekt zu funktionieren. Selbst wenn es richtig blinkt, wird es eingesetzt, verstaut und untersucht - ich habe Vollbettsonden durchgeführt und noch nie einen Sondenausfall gesehen, und die Wiederholbarkeit ist ausgezeichnet.
Dies ist ein echtes V3.1 BLTouch - kein Klon.

Ich habe vergessen zu erwähnen, dass ich die Impulse sowohl mit meinem billigen Mini-DSO als auch mit meinem großen CRT-Oszilloskop überprüft habe und die Impulslängen in Ordnung zu sein scheinen. Ich habe auch verschiedene S-Werte (von 155 bis 165) ausprobiert, ohne einen zu finden, der den Reset auslöst.

Ich habe nicht nachgeschlagen, wie die Servobibliothek für den LPC funktioniert - aber:
Ein Servosignal ist eine PWM. Wenn dies mit einem STM32-Hardware-Timer realisiert würde, würde dieser Fehler wahrscheinlich durch direktes Aktualisieren des Zähler-Vergleichsregisters verursacht, anstatt den neuen Wert in das Vorspannungsregister des Vergleichsregisters zu aktualisieren. Wenn das Vergleichsregister von einem hohen Wert auf einen niedrigen Wert geändert wird, während sich der Zähler zwischen dem niedrigen und dem hohen Wert befindet, wird der (gleiche) Vergleich übersprungen, der Pin wird nicht geändert, bis der Zähler überläuft und dann den neuen Wert erreicht . Wenn das Vorspannungsregister verwendet wird, wird das Vergleichsregister entweder aktualisiert, wenn der Zähler überläuft oder wenn der (alte) Vergleichswert übereinstimmt. Dies birgt kein Risiko eines langen Impulses, nur eine mögliche Verzögerung von maximal etwa einer PWM-Periode (20 ms).
BEARBEITEN: Die Wahrscheinlichkeit für den Fehler beträgt 5% pro 1 ms Rücksprung.
Ich nehme an, hier haben wir etwas Ähnliches.

Dies liegt daran, dass das lpc-Framework die Hardware pwm nicht im Latching-Modus ausführt (wobei das Pulsbreitenregister in jeder Periode schattiert und zwischengespeichert wird). Dies sollte mit einem einfachen Modusbit möglich sein. Aber leider kann ich das nicht Damit es zuverlässig funktioniert, haben Sie die Wahl zwischen einem möglichen Fehler von 1 Periode oder einer zufälligen Pulsbreite (aber ziemlich häufig, je nachdem, wie oft es aktualisiert wird), die sich überhaupt nicht ändert.

Weitere Forschungen zu diesem Thema könnten durchgeführt werden, aber es ist wirklich kein kompliziertes Peripheriegerät. Ich habe viel Zeit mit dieser Panne verschwendet und am Ende brauchten andere Dinge Aufmerksamkeit.

@mlehnhoff @kockockockoc Wie dp wenden Sie den Patch bitte an?

@mlehnhoff @kockockockoc Wie dp wenden Sie den Patch bitte an?

Um ehrlich zu sein, ich bin ziemlich neu in Git und ich bin nur froh, dass ich diesen Patch über "Git Diff" erstellen konnte. Ich bin sicher, es muss einen anderen git-Befehl geben, um diesen Patch wieder anzuwenden. Vielleicht kann @kockockockoc helfen ...
Aber für dieses sehr kleine Codefragment können Sie es sogar von Hand machen. Es ist genauso einfach wie das Hinzufügen der vier Zeilen, die mit einem "+" beginnen, zur Datei "Marlin / src / HAL / HAL_LPC1768 / Servo.h" (natürlich ohne das "+") an der angezeigten Position ...

Hallo, ich habe das gleiche Board Bigtreetech SKR v1.3 und 3D Touch, aber der 3D Touch funktioniert nicht. Ich habe das 3dTouch mit Code in einem Arduino Mega getestet und es funktioniert perfekt. Also habe ich jeden Vorschlag ausprobiert, den ich gefunden habe, und auch den @ mlehnhoff- Patch, aber ich habe immer noch das gleiche Problem = 3D Touch ist eingefroren. Wenn Marlin startet, führt der 3D Touch einen Selbsttest durch, und dann ist der Stift verstaut und bleibt für immer in diesem Zustand, ohne Änderungen vorzunehmen (über M43 S oder über das Marlin-Menü).
Ich mache mir darüber wirklich Sorgen, weil ich nicht weiß, was ich tun muss, um dieses Problem zu lösen. Jeder Vorschlag ist willkommen.

Ich vermute, dass dieser Fehler der gleiche ist, den ich hier gemeldet habe: https://github.com/MarlinFirmware/Marlin/issues/15370

Ich führe immer noch ein Bugfix-Commit vom 22.06.19 ohne Probleme aus. Ich habe heute das neueste Bugfix-Commit ausprobiert und das Servoproblem ist immer noch vorhanden.

@ Reywas62 und alle, ich fand diesen Artikel http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html , der das Problem lösen könnte. Offensichtlich könnten einige SKR-Karten ein Ausgangssignal mit einer niedrigen Impedanz (etwa 200 Ohm) haben, für dessen ordnungsgemäße Funktion eine erhebliche Strommenge erforderlich wäre (und dies ist bei Arduino-Karten nicht der Fall, weshalb meine 3D-Berührungssonde ordnungsgemäß funktioniert auf dem Arduino) Also, anscheinend hat es nichts mit Firmware zu tun.

Nun, ich würde diese Erklärung kaufen, außer dass mein Board mit einem früheren Commit von Marlin Bugfix 2.0.x (22.06.19) gut funktioniert.

Ich kann bestätigen, dass die "Quick an Dirty" -Lösung von mlehnhoff funktioniert. Ich untersuche ein 9x9 UBL-Mesh mit einem BLTouch-Klon. Normalerweise fallen 1 oder 2 Punkte des 81-Punkte-Netzes aus, wenn ich die Netzgenerierung ausführe. Aber mit dem "Fix" funktioniert alles gut. Also werde ich diese Lösung weiterhin verwenden. Und in meinem Fall denke ich, dass es ein Problem mit dem langen Servopuls ist, weil mein Druckstift eingesetzt ist und der Sensor nicht auslöst.

Ich möchte bestätigen, dass mein Problem mit dem 3D Touch behoben wurde. Das Problem ist der niedrige Strom der SKR 1.3 Servostifte. Ich habe die Schaltung gemacht und sie erfolgreich getestet. Jetzt habe ich diese Informationen nach dem Ausführen von M43 erhalten:
SENDEN: M43 S.
Servosondentest
. Verwenden Sie den Index: 0, den Einsatzwinkel: 10 und den Verstauungswinkel: 90
. Sonde Z_MIN_PIN: 57
. Z_MIN_ENDSTOP_INVERTING: false
. Überprüfen Sie auf BLTOUCH
= BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1 erkannt.
* Bitte Sonde innerhalb von 30 Sek. Auslösen *
. Impulsbreite (+/- 4 ms): 10
= BLTouch vor V3.1 (oder kompatibel) erkannt

Ich werde hier mit meinem Setup experimentieren, aber ich habe sowohl einen SG90- als auch einen MG90-Servomotor, der sich bei Deaktivierung zeitweise zurückbewegt. Wenn der Z-Probe-Schalter gedrückt gehalten wird, wird die Maschine dadurch getötet, wenn sie gegen das Bett stößt. Der letzte Crash summierte sich auf die Radhalterungen des Creality CR10 S5. > _

Wenn ich die Gelegenheit dazu bekomme, werde ich die Schaltung ausprobieren und sehen, ob sie das regelt. aber ich werde auch den Firmware-Hack ausprobieren. :) :)

Nachdem ich den Firmware-Hack ausprobiert hatte, gab es für mich keine Änderung (wie ich vermutete, da der Hack Bl-Touch-Klone repariert, nicht unbedingt Servobewegung). Der Servo bewegte sich gelegentlich nach Abschluss einer Bewegung immer noch weiter rückwärts.

In Anbetracht dessen habe ich den Hack rückgängig gemacht und Marlin angewiesen, das Servo NICHT zu deaktivieren, und es scheint, dass das Problem des Zurückziehens verschwunden ist. Scheint, als würde das Deaktivieren des Servos mein Problem auslösen. Glücklicherweise zeigt der MG90, den ich verwende, keine Vibrationen / Verwacklungen in den von mir ausgewählten Winkeln. :) :)

Ich möchte mich auf jeden Fall bei mlehnhoff für den Gcode bedanken, mit dem sie testen können. Jedes Mal, wenn ich es ausführte, wurde das Servo drei- oder viermal abgespielt, und als ich Marlin anwies, das Servo aktiviert zu halten, lief das Skript dreimal hintereinander einwandfrei. In Anbetracht der Berichte über niedrigen Strom habe ich den Test auch mit eingeschalteten Heizungen durchgeführt, um das Netzteil unter Last zu setzen. :) :)

Ich weiß nicht, ob es darauf ankommt, aber meine Servowinkel sind 172 (eingesetzt) ​​und 35 (verstaut) und es sah so aus, als würde das Servo jedes Mal um den gleichen Betrag rückwärts bewegt. Das Servo bewegte sich nie vorwärts.

Der Firmware-Hack hat mein Problem nicht behoben, aber wenn das Servo aktiviert bleibt, kann sich das Servo nicht schlecht verhalten, wie dies bei DarkAlaranth der Fall war. Nicht wirklich eine Lösung, aber eine akzeptable Problemumgehung.

Ein bisschen mehr Hintergrund Ich habe dies in den letzten Tagen auf mehreren Plattformen versucht und dachte, ich hätte möglicherweise beide AntLab BLtouch kaputt gemacht, also habe ich ein drittes bestellt.

Folgendes habe ich für die folgenden Plattformen beobachtet
SKR Pro V1.1 funktioniert nicht
SKR v1.3 funktioniert nicht
RAMPS 1.4 funktioniert nicht
SKR v1.4 funktioniert nicht
RAMPS 1.6 funktioniert nicht

Das Symptom vor dem Prüfen las auf einem M119
Endstop-Status melden
x_min: AUSGELÖST
y_min: AUSGELÖST
z_min: AUSGELÖST

Ich habe auch die Pins-Datei mit den gleichen Ergebnissen angepasst.

Hier ist der Prozess, den ich in mehreren Videos verschiedener Marlin-Jahrgänge verwendet habe
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

Ich könnte mehr Videos posten, aber mein Punkt ist, dass es bei keinem von ihnen mit 3 echten BL-Berührungen funktioniert.

Hat sich etwas an der Konfiguration geändert? Die configuration_adv.h verfügt jetzt über eine Reihe von BL touch-Energieeinstellungen.

Sollte es beim Referenzieren der Z-Achse eine Berichtstemperatur geben?
Hier ist das Debug:
SENT: G28 Z0
SENT: M114
SENT: M105
RECV: Fehler: !! STOP wegen BLTouch-Fehler aufgerufen - Neustart mit M999
[FEHLER] Fehler: !! STOP wegen BLTouch-Fehler aufgerufen - Neustart mit M999

M119 auf RAMPS 1.6 / MEGA2560
Liest korrekt für Öffnen auf z-min
Das Prüfen scheint nicht zu funktionieren.

Habe dieses Problem.
Ender 3, SKR Mini E3 v1.2, echtes BLTouch v3.1

Funktioniert gut für mich mit der V2
Die Verkabelung für den skr1.3 unterscheidet sich von der Lagerausrichtung. Ich verwende die Release-Version von Marlin 2.0.1

Können Sie ein anderes BLTouch ausprobieren? Um zu überprüfen, ob es sich nicht um eine beschädigte Sonde handelt?

Nein Entschuldigung. Ich habe nur einen normalen BLTouch. Der Fehler tritt nur bei einem von ~ 200 oder so auf.

@mlehnhoff Wenn Sie Zeit haben, machen Sie bitte einen

und da Bugfix 2.0.x täglich aktualisiert wird, wiederholen Sie den Test bitte alle 14 Tage oder so

Neu kompiliert den neuesten Bugfix Build [2020.01.24.]
Hat zwei Sondenwiederholbarkeitstests mit jeweils 150 durchgeführt.

1. Bettheizung AUS, erfolgreich beendet, Standardabweichung: 0,003928.
2. Bettheizung EIN, Prüfung fehlgeschlagen, bei 137 fehlgeschlagen.

Ich habe ein ähnliches Verhalten bei der Verwendung von Bugfix 2.0.x auf einer SKR1.1-Karte (LPC1768) mit einem Klon BLTouch (3DTouch) beobachtet.
Ich habe verschiedene Problemumgehungen ausprobiert, aber von 25 Prüfpunkten wird der Stift zumindest für einen Prüfpunkt zu früh freigegeben (wie bei einer Bereitstellung unmittelbar gefolgt von einem Verstauen).

@mlehnhoff Wenn Sie Zeit haben, machen Sie bitte einen

@boelle : Ein bereits erwähnt, nicht in Marlin selbst, sondern im LPC-Framework liegt. Er sagte, dass er den PWM-Verriegelungsmodus auskommentieren müsse, weil er nicht richtig funktioniere. Solange dies nicht behoben ist, muss jeder, der einen zuverlässig funktionierenden Bltouch haben möchte, meine hässliche, aber funktionierende Problemumgehung verwenden.
Im Moment habe ich leider keinen Zugang zu einem Oszilloskop, sonst möchte ich P3P beim Debuggen dieses Problems unterstützen. Wenn jemand anderes näher darauf eingehen möchte, wenden Sie sich bitte an: https://github.com/p3p/pio-framework-arduino-lpc176x/blob/master/system/lpc176x/HardwarePWM.h

Habe dieses Problem.
Ender 3, SKR Mini E3 v1.2, echtes BLTouch v3.1

SKR Mini E3 v1.2 verwendet einen STM32-Mikrocontroller, keinen LPC1768.

Ich frage mich, ob das Problem beim Verriegeln von PWM mit den folgenden LPC176x-Errata zusammenhängt:

3.13 PWM.1: Beim Aktualisieren des Arbeitszyklus für PWM1.1 von 100% in
In einigen Fällen kann der Ausgang für eine volle PWM-Zeit vor dem
Update wird wirksam
Einführung:
Auf dem PWM-Peripheriegerät LPC176x können zwei Übereinstimmungsregister verwendet werden, um ein einziges bereitzustellen
flankengesteuerter PWM-Ausgang. Ein Übereinstimmungsregister (PWM1MR0) steuert den PWM-Zyklus
Rate, indem die Anzahl bei Übereinstimmung zurückgesetzt wird. Das andere Übereinstimmungsregister steuert die PWM-Flanke
Position. Das Steuerregister PWM1MR1 steuert beispielsweise die Kantenposition von PWM1.
Mehrere PWM-Ausgänge mit Einzelflankensteuerung weisen zu Beginn eine steigende Flanke auf
jeder PWM-Zyklus, wenn eine PWM1MR0-Übereinstimmung auftritt.
Problem:
Nur im Single-Edge-Modus, wenn das Tastverhältnis für PWM1.1 (Pulse Width Modulator 1, Kanal)
1 Ausgang) wird von 100% (PWM1MR1 = PWM1MR0) aktualisiert, dann der Ausgang für PWM1.1
könnte unerwartet für eine volle PWM-Periode vor dem neuen gewünschten Arbeitszyklus niedrig bleiben
wirksam werden. Dieses Problem betrifft nur die Ausgabe für PWM1.1. Andere PWM-Kanäle
(PWM1.2 bis PWM1.6) sind von diesem Problem nicht betroffen.
Umgehung:
Ein Software-Fix kann implementiert werden, mit dem der Benutzer PWM1MR1 laden kann
PWM1MR0 + 1 (mindestens 1), um Verzögerungen bei der Ausgabeaktualisierung des PWM1.1 zu vermeiden.

Ich gehe davon aus, dass dies nicht der Fall ist, da ich nicht glauben würde, dass wir jemals einen Servostift in den 100% PWM-Modus versetzen.

Andererseits wird auf der PWM 1.1 für P2_0 der Servopin auf dem SKR 1.3 verwendet ...

Ich habe ein ähnliches Problem untersucht (mit einem echten BL Touch 3.1 und einem SKR PRO 1.1).
Ich habe dokumentiert, was ich in # 16986 gefunden habe, aber im Grunde habe ich festgestellt, dass meine mit der XY_PROBE_SPEED verwandt war. Eine Zahl von 10000 bewirkt, dass das BL Touch-Signal am 15-Prüfpunkt (der auch der erste nach der ersten Y-Bewegung ist) von einem Impuls auf einen Gleichstrompegel wechselt. Eine Zahl von 6000 zeigte für mich keine Probleme.

Ich habe diese Problemumgehung mehr als einen Monat lang auf zwei Ender 3 mit SKR v1.3 und 3D Touch v2 (und Pi 3B) getestet. Zuvor hatte ich immer regelmäßige Fehler bei der Durchführung von ABL (mindestens 1 von 3-5 Drucken), bei denen die Sonde nicht ausgelöst wurde (aber sofort rot blinkte) und die Düse gegen das Bett krachte, wenn nicht das mechanische Z-Ende wäre -stop Ich bin absichtlich gegangen. Und ich habe die meisten, wenn nicht alle Permutationen der Sondierungs- / BL-Touch-Konfigurationen in Marlin 2.0.x ausprobiert.
Da ich in diesen Wochen bei unzähligen Tests 0 Fehler hatte (sowohl M48 als auch viele tatsächliche Drucke), muss ich diese Problemumgehung in meinem Fall als klaren Erfolg ansehen. Ich werde meine Ergebnisse natürlich aktualisieren, falls sich die Ergebnisse ändern.
Ich habe auch getestet, dass es unabhängig von der XY-Sondengeschwindigkeit (versucht 6-8-10000 mm / s), der Z-Sondengeschwindigkeit und ohne Deaktivierung der Heizungen / Stepper während des Prüfens funktioniert. Grundsätzlich scheint das Sondierungssetup in Marlin kein Faktor mehr zu sein, um Fehler zu vermeiden (kann jedoch die Präzision beeinträchtigen, zumindest die Z-Geschwindigkeit).
Das einzige Problem ist, dass die Hintergrundbeleuchtung des LCD (5 V) während der Prüfung vorübergehend blinkt, wenn die 5 V aus dem SKR entnommen werden, was wahrscheinlich auf einen Spannungsabfall aufgrund des Stromverbrauchs der Sonde hinweist (aber nicht das Ganze mit meinem Zielfernrohr isolieren und prüfen wollte). . Daher habe ich stattdessen 5 V an den Pi angeschlossen (könnte aber genauso gut eine externe 5 V-Quelle sein), wobei zwei GND-Drähte in der Nähe der Sonde gespleißt sind, von denen einer zum SKR und der andere zum Pi führt (für den Stern eines armen Mannes). .

@mlehnhoff
Bitte testen Sie den Bugfix-2.0.x-Zweig, um zu sehen, wo er steht.

Ich werde dies in Kürze auf meinem echten BLTouch testen. Ich glaube, ich habe das gleiche Problem.

Bearbeiten: Nicht das gleiche Board (STM32F103RC), aber identische Probleme! Ich versuche herauszufinden, ob es sich um ein Timing-Problem oder etwas anderes handelt! Aber wenn ich ein 91 UBL-Netz mache, bekomme ich vielleicht 1 oder 2 ausgefallene Sonden auf die gleiche Weise wie hier beschrieben?

Nun, ich habe herausgefunden, dass mein Board den 'geteilten' Servocode verwendet. Ich habe das Folgende nach einigem Ausprobieren hinzugefügt und es scheint sicher zu sein, Verzögerung von 6 ms / us? funktioniert! Der Sensor scheint schneller auszulösen, wenn das Sinn macht? Und ich habe es jetzt geschafft, mein erstes Netz zu bekommen, ohne dass ein Sensor ausfällt? Wird ein Auge darauf haben und mehr Tests durchführen, sieht aber zunächst vielversprechend aus! Dies ist mit einem echten BLTouch, ich hatte einen zweiten bestellt, weil ich dachte, er sei fehlerhaft! Ich glaube nicht, dass es sich um eine andere Hardware handelt, da dieses Setup auf der ursprünglichen Standardplatine einwandfrei funktioniert hat, erst seit der Umstellung auf BTT V2.0 und Marlin ist dieses Problem aufgetreten. Zuvor hatte ich Klipper ohne Probleme ausgeführt.

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

@ aslater3 Wie kann ich feststellen, ob mein Board (SKR Mini E3 v1.2) einen gemeinsam genutzten

@ Boelle Entschuldigung, ich war ziemlich beschäftigt mit verschiedenen Dingen. Ich habe gerade den neuesten Bugfix-2.0.x getestet (der anscheinend 2.0.5.4 ist). Das Problem ist noch vorhanden. Das liegt daran, dass es in pio-framework-arduino-lpc176x immer noch nicht behoben ist.
Aber ich habe jetzt Zugang zu einem Oszilloskop und bin bereit, es weiter zu untersuchen (und es schließlich zu reparieren) ...

2.0.5.4 ( 2.0.x ) und bugfix-2.0.x sind zwei verschiedene Zweige. Bitte probieren Sie die neuesten bugfix-2.0.x und teilen Sie uns mit, ob dieses Problem weiterhin auftritt.

2.0.5.4 ( 2.0.x ) und bugfix-2.0.x sind zwei verschiedene Zweige. Bitte probieren Sie die neuesten bugfix-2.0.x und teilen Sie uns mit, ob dieses Problem weiterhin auftritt.

Ja, ich weiß und ich habe den neuesten Bugfix-2.0.x verwendet! 2.0.5.4 ist nur das, was mir das LCD-Menü sagt

Dies spielt jedoch keine Rolle, da sich der Fehler nicht im MarlinFw-Code befindet, sondern im pio-framework-arduino-lpc176x

Es ist sogar bekannt, welcher Teil des Codes das Problem verursacht: das deaktivierte Latching des HW-PWM.

Das Problem besteht darin, einen Weg zu finden, um die Verriegelung wieder zu aktivieren, ohne andere Probleme zu haben. Aus diesem Grund wurde die Verriegelung deaktiviert.

Ich habe mit @ p3p darüber gesprochen, da ich ähnliche Probleme auf anderen Plattformen untersucht habe. Ich glaube nicht, dass es eine Chance gibt, dass dieses Verhalten geändert wurde, und es lohnt sich nicht wirklich, es jetzt erneut zu testen, es sei denn, dies ist Teil der tatsächlichen Implementierung einer dauerhafteren Lösung.

2.0.5.4 ist nur das, was mir das LCD-Menü sagt

Dann verwenden Sie nicht den neuesten Bugfix. Auf Ihrem LCD wird bugfix-2.0.x .

Ich bin mir der 1-Perioden-Störung bewusst, wenn ein kürzerer Arbeitszyklus eingestellt wird, nachdem der neue Übereinstimmungswert bereits überschritten wurde. Derzeit bin ich mir nicht sicher, wie ich das Problem beheben kann. Die Hardware scheint nicht das zu tun, was sie tun soll, wenn die pwm-Schattenregister aktiviert sind.

2.0.5.4 ist nur das, was mir das LCD-Menü sagt

Dann verwenden Sie nicht den neuesten Bugfix. Auf Ihrem LCD wird bugfix-2.0.x .

okay, mein schlechtes, ich habe versehentlich den Zweig 2.0.x anstelle von Bugfix-2.0.x geklont ... jetzt habe ich das behoben -> kein Unterschied (natürlich)

Ich bin mir der 1-Perioden-Störung bewusst, wenn ein kürzerer Arbeitszyklus eingestellt wird, nachdem der neue Übereinstimmungswert bereits überschritten wurde. Derzeit bin ich mir nicht sicher, wie ich das Problem beheben kann. Die Hardware scheint nicht das zu tun, was sie tun soll, wenn die pwm-Schattenregister aktiviert sind.

@ p3p Können Sie mir bitte sagen, welche Probleme

Soweit ich mich erinnere (es ist lange her, seit ich dies debuggt habe), würde die Impulsbreite bei aktivierten Schattenregistern sporadisch überhaupt nicht aktualisiert werden, wie Sie sich vorstellen können, habe ich stattdessen den 1-Perioden-Fehler gewählt. Es schien möglicherweise darauf zurückzuführen zu sein, dass die Impulsbreite im selben Zeitraum mehr als einmal aktualisiert wurde, aber ich war mir nicht sicher.

Ein befohlener Servowinkel muss mindestens 20 ms betragen, um am Ausgang als geänderte Impulsbreite sichtbar zu sein.
Um die neue Impulsbreite für das Gerät / Servo erkennbar zu machen, müssen wahrscheinlich mehrere Impulse bleiben.
Das Ändern des Winkels innerhalb von mindestens 20 ms muss daher verboten werden.
Nach dem , was https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment -657406598 besser über 60 ms herausgestellt hat.

Eine häufigere Aktualisierung des Schattenregisters ist nicht sinnvoll. Das Register sollte nicht öfter geschrieben werden, als sich der Winkelwert ändert. (Schattenvariable für das Schattenregister?)
Wahrscheinlich benötigt es einen zusätzlichen Patch auf einer höheren Ebene der Servobibliothek, um zu häufige Änderungen zu verhindern. Wir haben bereits etwas Ähnliches mit SERVO_DELAY , das ursprünglich dazu gedacht war, das Abschalten des Servosignals zu verhindern, bevor das Servo (mechanisch) sein Ziel erreicht.

@AnHardt Ich weiß, dass das mehrmalige Ändern der Schattenregister pro Periode sinnlos ist, aber ich verstehe nicht, warum das mehrfache Ändern der Schattenregister, bevor die Werte am Ende der Periode in die realen Register verschoben werden, ein Problem verursachen würde. Ich bin mir nicht sicher, was Die Lösung, um zu verhindern, dass die Clientanwendung die Hardware-PWM zu oft aktualisiert, wäre (wenn dies wirklich das Problem ist), ohne dass auf die eine oder andere Weise ein signifikanter Leistungseinbruch auftritt.

@AnHardt Ich weiß, dass das mehrmalige Ändern der Schattenregister pro Periode sinnlos ist, aber ich verstehe nicht, warum das mehrfache Ändern der Schattenregister, bevor die Werte am Periodenende in die realen Register verschoben werden, ein Problem verursachen würde.

Ich weiß auch nicht warum oder ob es ein Problem gibt. Aber wenn Sie uns sagen, dass es Probleme verursacht, sollten wir versuchen, dies zu vermeiden.
Ein Konstrukt wie:

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

würde zumindest verhindern, dass mehrmals mit demselben Wert in das Schattenregister geschrieben wird.

Wenn ich mich richtig erinnere, habe ich beim letzten Berühren des SERVO_PROBE-Codes vor dem Erscheinen des BL-Touch sorgfältig vermieden, das Servo und die Stepper gleichzeitig mit Synchronisierungen zu bewegen - aber ich habe immer mit DEACTIVATE_SERVOS_AFTER_MOVE getestet, weil Meine Servos zitterten, als sich der Stepper bewegte, und erzeugten nach dem Einstellen des servo_angle eine Pause von SERVO_DELAY (einige hundert ms). Im Vergleich dazu sind die viel kürzeren Verzögerungen, die ich jetzt vorschlage, ein Leistungsgewinn.

Wenn der BL-Touch-Code versucht, Servo und Stepper gleichzeitig zu bewegen, fühlt sich das für mich nicht wie der Ball an, den ich spielen muss.

Da die BL-Touches ein ständig eingeschaltetes Servosignal haben möchten, ist DEACTIVATE_SERVOS_AFTER_MOVE nicht möglich. Für die Interrupt-gesteuerten Servobibliotheken wurde ein verzögerter Interrupt katastrophal und brachte das Servosignal durcheinander. Eine hardwaregesteuerte PWM wäre immun. Normalerweise haben wir nur ein Servo.

Ich bin mir jedoch ziemlich sicher, dass ein set_servo(0); set_servo(180); set_servo(0); ohne Pausen absolut keine Reaktion hervorruft - weder bei einem echten Servo noch bei einem BL-Touch.

Es tut uns leid. Wahrscheinlich konzentrieren sich meine Gedanken im Moment zu sehr auf Hardware-PWM, wo das Timer-Vergleichsregister nur ab und zu aktualisiert werden muss.

Es tut uns leid. Wahrscheinlich konzentrieren sich meine Gedanken im Moment zu sehr auf Hardware-PWM, wo das Timer-Vergleichsregister nur ab und zu aktualisiert werden muss.

Dieses Problem tritt bei der Hardware-PWM auf, und ich stimme mit allem überein, was Sie gesagt haben. Ich habe nur über das Problem auf Framework-Ebene nachgedacht, wie die Hardware zuverlässig funktioniert, selbst wenn die Client-Anwendung eine verrückte Menge an Updates ausführt (Marlin) ) im gleichen Zeitraum. Der Client erwartet, dass das letzte Update anstelle des ersten wirksam wird, und ich kann nicht wissen, dass es vor Ablauf des Zeitraums keine nachfolgenden Updates geben wird.

Ich muss mir das Problem noch einmal ansehen, um zu sehen, ob mir eine neue Lösung einfällt und ob diese Diagnose tatsächlich richtig ist und ich nicht nur dumm war.

Ich würde es versuchen
Wann auf kurzfristige Positionen verzichtet werden kann:

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;
    }
  }
}

läuft etwa alle 20 ms.
Das sollte die Länge des Ausgangsimpulses für mindestens 3 * 20 ms konstant halten und dann nur den neuesten befohlenen Winkel einstellen. Es wird jedoch nicht wissen, welcher Winkel als nächstes kommt oder ob überhaupt ein Update folgen wird - das ist unmöglich zu wissen - einige, wann Sie beginnen müssen. Es garantiert, dass die Sendeimpulse gelesen werden können und das Schattenregister nicht sehr oft aktualisiert wird.

Um sicherzustellen, dass jedes Update mindestens für diese Zeit durchgeführt wird, muss die flüchtige Variable durch eine Warteschlange ersetzt werden.

Beim RC-Fliegen können die Zwischenpositionen wahrscheinlich weggelassen werden. Im Falle des Verstauens von BL-Touch ist das Bereitstellen, Zurücksetzen, Ändern von Modi, ... gleichermaßen wichtig. Dies kann weggelassen werden, jeder Befehl muss lange genug bleiben, um erkannt zu werden. Es gibt keine universelle richtige Lösung für eine universelle Servobibliothek.

Zusätzlich müssen für den BL-Touch alle Befehle mit den Schrittbewegungen synchronisiert sein. Das Zurückziehen der Sonde beim Herunterfahren der Sonde sollte besser weggelassen werden. :-)
Aus meiner Sicht muss Marlin dafür verantwortlich sein, dass der Winkel nicht zu häufig aktualisiert wird.

Bearbeiten:
Wahrscheinlich ist der Vergleichsinterrupt der richtige, um das Schattenvergleichsregister zu aktualisieren. Der Interrupt könnte dann durch Interrupts mit höherer Priorität um etwa 17 ms verzögert werden und wäre immer noch rechtzeitig, um das Aktualisierungsregister für die Kopie in das Vergleichsregister bereit zu haben, wenn der Überlauf auftritt.
Sollte möglich sein, den Interrupt zu stoppen, wenn der Zähler über 3 liegt. Könnte der Interrupt neu gestartet werden, wenn inter_angle aktualisiert wird.

Ich habe das gleiche Problem mit dem SKR mini 1.1.
Egal welche Position ich einstelle, das Servo fährt immer zum gleichen Punkt.

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

@Matheusschmitz der SKR mini verwendet eine andere Plattform und wäre von dieser Ausgabe einzigartig. Vor etwas mehr als einer Woche wurden einige Änderungen vorgenommen, um die BLTouch-Zuverlässigkeit für STM32F1-Karten (wie Ihre) zu verbessern. Bitte versuchen Sie, den Bugfix-2.0.x-Zweig zu verwenden, um festzustellen, ob Ihr Problem dadurch behoben wird.

Wenn Sie immer noch Probleme haben, besprechen Sie dies bitte an einem der Support-Standorte wie Discord. Dieses spezielle Problem sollte sich weiterhin auf LPC176x-Karten konzentrieren.

Dieses Problem tritt auch bei meinem SKR1.3- und BLTouch-Klon auf.
Ich habe es geschafft, es auf Video festzuhalten, ungefähr um die 1:54 Marke:
https://www.youtube.com/watch?v=wF0Mia49ECI&t=114s
(Video ist 1080p YouTube muss es verarbeiten)

Hier ist auch ein Bild, das zeigt, was es tut, wenn es während der UBL passiert

Ich habe, wie andere auch, die verschiedenen Einstellungen ausprobiert, die helfen könnten, sie haben nicht geholfen.
Ich bin auf dem neuesten Bugfix-2.0.x-Zweig

Gleiches Problem auf meiner Seite.
Ich werde auch die Problemumgehung testen

Dieses Problem war in den letzten 30 Tagen nicht aktiv. Bitte fügen Sie eine Antwort hinzu, wenn Sie dieses Problem aktiv halten möchten. Andernfalls wird es automatisch innerhalb von 7 Tagen geschlossen.

Ich denke, das ist es wert, offen zu bleiben, bis eine dauerhafte Lösung gefunden werden kann.

Ich stimme diesem Gefühl zu

Dieses Problem war in den letzten 30 Tagen nicht aktiv. Bitte fügen Sie eine Antwort hinzu, wenn Sie dieses Problem aktiv halten möchten. Andernfalls wird es automatisch innerhalb von 7 Tagen geschlossen.

Ich denke, dieses Thema sollte offen bleiben.