Marlin: [BUG] SKR v1.3 (ou tout autre LPC1768): problème avec les signaux d'asservissement qui causent des problèmes avec bltouch

Pouvez-vous essayer un véritable BLTouch?

Pouvez-vous essayer un véritable BLTouch?

De plus, avez-vous essayé d'ajuster les paramètres BLTouch dans Configuration_adv.h ?: Vous pouvez ajuster des paramètres tels que BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE , BLTOUCH_FORCE_MODE_SET , etc.

Oh, désolé, j'ai oublié de mentionner. Bien sûr, j'ai essayé différentes combinaisons de BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE et même DELAY_BEFORE_PROBING avant. Sans succès.
Maintenant que j'ai découvert quel est le problème, il est clair que des délais plus longs n'aident pas. Parce que la mauvaise impulsion de 20 ms qui amène le bltouch à cet état d'erreur se produit déjà quelques secondes avant que la plaque de construction ne soit touchée.
BLTOUCH_FORCE_MODE_SET n'est pas pris en charge par cette ancienne version du clone bltouch. Ce n'est pas un "intelligent".

Et non, je n'ai pas accès à un véritable BLTouch. Pour moi et mon ancien clone, le hack mentionné ci-dessus fonctionne très bien, donc personnellement, je n'ai pas besoin d'une solution appropriée pour ce problème. Mais je pense que ce problème devrait être résolu de toute façon, car je pense que même un servo réel pourrait éventuellement réagir à cette impulsion avec une courte secousse ou tout autre comportement étrange.

Wow, @mlehnhoff , votre patch

J'ai testé une sonde tactile servo sur un réarmement (même MCU) et je n'ai eu aucun problème, mais j'ai utilisé la fonction de désactivation après mouvement.

Je n'ai pas essayé sans cela, il était logique de désactiver le servo lorsqu'il n'est pas nécessaire

J'ai une poignée de BLTouches authentiques et ils fonctionnent tous très bien sur un SKR 1.3 qui est également LPC1768 .

donc sauter le pistolet ici, est-ce très probablement un problème matériel (fil, connexion de bruit) ou un problème de configuration utilisateur?

Même raison pour la plupart des options de code / configuration BLTouch supplémentaires, c'est un problème de clonage BLTouch.

Gardez à l'esprit que 3DTouch! = BLTouch. Il y a beaucoup de problèmes résolus liés à ces copies.

je l'appellerais alors un problème matériel,

oui, je suis maintenant 3dtouch (et d'autres) ne sont pas un BLtouch

le grand Q pour moi est quel marlin supporte les clones ou si nous ne nous soucions que des produits authentiques?

donner un peu de réflexion personnelle, je ne pense pas que ce soit juste que marlin devrait soutenir les clones

mais je peux me tromper, pensées?

Mes deux cents, quel que soit le nom de XXtouch. L'un d'eux se connecte à la broche SERVOS (pas à la broche spéciale BLtouch). Le SERVOS devrait fonctionner comme un servomoteur.

Mais je pense que ce problème devrait être résolu de toute façon, car je pense que même un servo réel pourrait éventuellement réagir à cette impulsion avec une courte secousse ou tout autre comportement étrange.
(du commentaire de @mlehnhoff )

Cela ne doit pas être imputé au matériel de la sonde. Le signal produit par la carte est incorrect et a été vérifié à l'aide d'un oscilloscope. Cela devrait être corrigé.

Je peux également confirmer que le comportement signalé est très similaire à celui du matériel BLTouch authentique lorsque je déboguais tous ces conflits de minuterie causant des problèmes similaires sur les cartes SKR Mini E3. Des longueurs d'impulsion incorrectes semblaient faire simplement oublier au BLTouch ce qu'il faisait et provoquer des échecs.

@mlehnhoff , avez-vous capturé des images de votre oscilloscope qui illustrent le problème, que vous pourriez attacher à ce problème?

Je ne pense pas que j'aime la solution de contournement actuelle en tant que solution complète, mais j'apprécie vraiment le niveau de détail fourni par mlehnhoff décrivant le problème et la solution de contournement démontrant que l'impulsion est apparemment la cause profonde du problème.

Désolé, je n'ai pas fourni de capture d'écran de la portée immédiatement. Je pensais que j'en avais fait, mais quelque chose s'est mal passé. Mais je ne m'en suis rendu compte qu'après avoir rendu la lunette (ce n'est pas la mienne).
Mais maintenant, j'en ai fait un nouveau:

Sur la photo, vous voyez la transition de 1472µs à 544µ, mais le premier nouveau

l'impulsion est de 20544µs.

De plus, j'ai essayé un servo réel et voici la preuve que ce problème n'est pas seulement limité à 3dtouch ou à d'autres clones.

IMG_4677.zip

Le servo doit tourner de 90 ° (levier au milieu) à 0 ° (levier vers le bas), mais lorsque l'impulsion défectueuse se produit, il monte en fait au début, avant de baisser.

À propos, il existe au moins huit versions différentes de bltouch authentique (classique v1.0, v1.2, v1.3, smart v1.0, v2.0, v2.2, v3.0, v3.1) et non on sait, si tous fonctionneront correctement ;-)

Voici un autre indice: lorsque vous envoyez la commande M280 manuellement, il est très peu probable que le problème se produise. J'ai écrit un script pour basculer le servo (utilisé dans la vidéo) ce qui augmente beaucoup la probabilité:
servo_toggle.gcode.txt

Je me demande si cela est lié à un problème que je vois avec mon BLTouch.
J'alimente mon Re-ARM via USB et j'utilise M80 pour allumer l'alimentation 12V. Il y a un convertisseur abaisseur 5V connecté à l'alimentation 12V qui alimente le BLTouch, de sorte que le BLTouch ne soit pas alimenté tant que l'alimentation 12V n'est pas activée.
Lorsque la carte s'allume, le BLTouch clignote en rouge - c'est apparemment un peu normal si le BLTouch reçoit un signal avant de s'allumer, donc je ne suis pas préoccupé par cela.
Cependant, toute tentative de le réinitialiser avec M280 P0 S160 n'a absolument aucun effet. Il ne rétracte pas non plus la broche s'il est déployé.
Cependant, M280 P0 S60 passe avec succès en mode SW et arrête également le clignotement.
À part le clignotement et S160 apparemment ignoré, le BLTouch semble fonctionner parfaitement. Même lorsqu'il clignote, il se déploie correctement, se range et sonde - j'ai fait des sondes à lit complet et je n'ai jamais vu de panne de sonde et la répétabilité est excellente.
Ceci est un véritable BLTouch V3.1 - pas un clone.

J'ai oublié de mentionner que j'ai vérifié les impulsions avec mon mini DSO bon marché et mon gros oscilloscope CRT et les longueurs d'impulsion semblent bonnes. J'ai également essayé différentes valeurs S (de 155 à 165) sans en trouver une qui déclenchera la réinitialisation.

Je n'ai pas regardé comment fonctionne la bibliothèque de servo pour le LPC - mais:
Un signal d'asservissement est un PWM. Si cela était réalisé avec un temporisateur matériel STM32, cette erreur serait probablement provoquée par la mise à jour directe du registre de comparaison des compteurs, au lieu de mettre à jour la nouvelle valeur dans le registre de précharge du registre de comparaison. Si vous changez le registre de comparaison d'une valeur haute à une valeur basse alors que le compteur est entre la valeur basse et la valeur haute, la comparaison (égale) est ignorée, la broche n'est pas changée jusqu'à ce que le compteur dépasse et atteigne la nouvelle valeur . Si le registre de précharge est utilisé, le registre de comparaison est mis à jour soit lorsque le compteur dépasse, soit lorsque la (ancienne) valeur de comparaison a une correspondance. Cela ne présente aucun risque d'une impulsion longue, seulement un retard possible de maximum environ une période PWM (20 ms).
EDIT: Le risque d'erreur serait de 5% par saut de 1 ms en arrière.
Je suppose que nous avons ici quelque chose de similaire.

En effet, le framework lpc n'exécute pas le pwm matériel en mode de verrouillage (où le registre de largeur d'impulsion est masqué et verrouillé à chaque période), il devrait être possible de le faire avec un bit de mode simple .. mais malheureusement je ne peux pas le faire fonctionner de manière fiable, c'est un choix entre un possible problème de durée d'une période, ou la largeur d'impulsion au hasard (mais assez fréquemment en fonction de la fréquence de mise à jour) ne changeant pas du tout.

Des recherches supplémentaires sur le sujet pourraient être faites, mais ce n'est vraiment pas un périphérique compliqué, j'ai perdu beaucoup de temps sur ce problème et à la fin, d'autres choses nécessitaient de l'attention.

@mlehnhoff @kockockockoc Comment dp appliquez-vous le patch s'il vous plaît?

@mlehnhoff @kockockockoc Comment dp appliquez-vous le patch s'il vous plaît?

Pour être honnête, je suis assez nouveau dans git et je suis juste content d'avoir pu créer ce patch via "git diff". Je suis sûr qu'il doit y avoir une commande git différente pour appliquer ce correctif. Peut-être que @kockockockoc peut vous aider ...
Mais pour ce tout petit fragment de code, vous pouvez même le faire à la main. C'est aussi simple que d'ajouter les quatre lignes commençant par un "+" au fichier "Marlin / src / HAL / HAL_LPC1768 / Servo.h" (bien sûr sans le "+") à la position indiquée ...

Salut, j'ai la même carte Bigtreetech SKR v1.3 et 3D Touch mais le 3D Touch ne fonctionne pas. J'ai testé le 3dTouch en utilisant du code dans un Arduino Mega et fonctionne parfaitement. Donc, j'ai essayé toutes les suggestions que j'ai trouvées et aussi le patch @mlehnhoff mais j'ai toujours le même problème = 3D Touch est gelé. Lorsque Marlin démarre, le 3D Touch effectue un auto-test, puis la broche est rangée et reste dans cet état pour toujours sans aucun changement (via M43 S ou depuis le menu Marlin)
Cela m'inquiète vraiment car je ne sais pas ce que je dois faire pour résoudre ce problème. Toute suggestion est la bienvenue.

Je soupçonne que ce bug est le même que celui que j'ai signalé ici: https://github.com/MarlinFirmware/Marlin/issues/15370

Je suis toujours en train d'exécuter un commit de correction de bogue du 22/06/19 sans problème. J'ai essayé le dernier commit de bugfix aujourd'hui et le problème de servo est toujours présent.

@ Reywas62 et tout, j'ai trouvé cet article http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html qui pourrait résoudre le problème. Apparemment, certaines cartes SKR pourraient avoir un signal de sortie qui a une faible impédance (environ 200 ohms) qui nécessiterait une quantité importante de courant pour fonctionner correctement (et cela ne se produit pas sur les cartes Arduino, c'est la raison pour laquelle ma sonde tactile 3D fonctionne correctement. sur l'Arduino) Donc, apparemment, ce n'est pas lié au firmware.

Eh bien, j'achèterais cette explication, sauf que ma carte fonctionne bien avec un commit précédent de Marlin bugfix 2.0.x (22/06/19).

Je peux confirmer que la solution «rapide et sale» de mlehnhoff fonctionne. Je sonde un UBL-Mesh 9x9 avec un clone BLTouch. Normalement, 1 ou 2 points du maillage de 81 points échouent lorsque j'exécute la génération de maillage. Mais avec le «correctif», tout fonctionne bien. Je vais donc continuer à utiliser cette solution. Et dans mon cas, je pense que c'est un problème avec la longue impulsion de servo parce que ma punaise est déployée et le capteur ne se déclenche pas.

Je voudrais confirmer que mon problème avec le 3D Touch a été résolu. Le problème est le faible courant des broches du servo SKR 1.3. J'ai fait le circuit et l'ai testé avec succès. Maintenant, j'ai reçu ces informations après avoir exécuté M43:
ENVOI: M43 S
Test de la sonde servo
. en utilisant l'index: 0, angle de déploiement: 10, angle de rangement: 90
. Sonde Z_MIN_PIN: 57
. Z_MIN_ENDSTOP_INVERTING: faux
. Vérifier BLTOUCH
= BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1 détecté.
* Veuillez déclencher la sonde dans les 30 secondes *
. Largeur d'impulsion (+/- 4 ms): 10
= BLTouch pre V3.1 (ou compatible) détecté

Je vais expérimenter ma configuration ici, mais j'ai à la fois un servomoteur SG90 et un servomoteur MG90 qui reviennent par intermittence en cas de désactivation. Comme il tient l'interrupteur Z-Probe, cela tue un peu la machine lorsqu'elle s'écrase dans le lit. Le dernier crash a totalisé les supports de roue de la Creality CR10 S5. > _

Quand j'en aurai l'occasion, j'essaierai le circuit et je verrai s'il résout ça. mais va aussi essayer le hack du firmware. :)

Après avoir essayé le hack du firmware, il n'y a eu aucun changement pour moi (comme je le soupçonnais, car le hack corrige les clones bl-touch, pas nécessairement le mouvement des servos). Le servo se déplaçait parfois encore en arrière après avoir terminé un mouvement.

Compte tenu de cela, j'ai annulé le hack et j'ai dit à marlin de ne PAS désactiver le servo et il semble que le problème du retour en arrière ait disparu. Il semble que la désactivation du servo déclenche mon problème. Heureusement, le MG90 que j'utilise ne montre aucune vibration / secousse sur les angles que j'ai sélectionnés. :)

Je voudrais vraiment remercier mlehnhoff pour leur gcode à tester. Chaque fois que je l'exécutais, le servo jouait 3 ou 4 fois, et quand j'ai dit à Marlin de garder le servo activé, le script fonctionnait bien 3 fois de suite. Compte tenu des rapports de faible courant, j'ai également effectué le test avec les appareils de chauffage pour mettre le bloc d'alimentation sous charge. :)

Je ne sais pas si cela compte, mais mes angles de servo sont 172 (déployés) et 35 (rangés) et il semblait que cela déplacerait le servo vers l'arrière, de la même quantité à chaque fois. Le servo n'a jamais avancé.

Le piratage du micrologiciel n'a pas résolu mon problème, mais le fait de laisser le servo activé empêche le servo de se comporter mal, comme il l'a fait pour DarkAlaranth. Pas vraiment un correctif, mais une solution de contournement acceptable.

Un peu plus de fond J'ai essayé cela sur plusieurs plates-formes au cours des deux derniers jours et j'ai pensé que j'aurais peut-être cassé mes deux AntLab BLtouch, alors j'ai commandé un troisième.

Voici ce que j'ai observé pour les plateformes suivantes
SKR Pro V1.1 ne fonctionne pas
SKR v1.3 ne fonctionne pas
RAMPS 1.4 ne fonctionne pas
SKR v1.4 ne fonctionne pas
RAMPS 1.6 ne fonctionne pas

Le symptôme avant de sonder lu sur un M119
Signaler l'état de la butée
x_min: DÉCLENCHÉ
y_min: DÉCLENCHÉ
z_min: DÉCLENCHÉ

J'ai également ajusté le fichier pins avec les mêmes résultats.

Voici le processus que j'ai utilisé dans plusieurs vidéos de divers millésimes de marlin
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

Je pourrais publier plus de vidéos, mais mon point est que cela ne fonctionne sur aucune d'entre elles avec 3 véritables touches BL.

Quelque chose a-t-il changé dans la configuration? Le configuration_adv.h a maintenant un tas de paramètres d'alimentation BL touch.

Doit-il y avoir un rapport de température lors du référencement de l'axe Z?
Voici le débogage:
ENVOYÉ: G28 Z0
ENVOYÉ: M114
ENVOYÉ: M105
RECV: Erreur: !! STOP appelé en raison d'une erreur BLTouch - redémarrer avec M999
[ERROR] Erreur: !! STOP appelé en raison d'une erreur BLTouch - redémarrer avec M999

M119 sur RAMPS 1.6 / MEGA2560
Lit correct pour ouvrir sur z-min
Le sondage semble ne pas fonctionner.

J'ai ce problème.
Ender 3, SKR Mini E3 v1.2, véritable BLTouch v3.1

Fonctionne bien pour moi avec le V2
Le câblage du skr1.3 est différent de l'orientation du stock. J'utilise la version finale de Marlin 2.0.1

Pouvez-vous essayer un autre BLTouch? Pour vérifier qu'il ne s'agit pas d'une sonde endommagée?

Non désolé. Je n'ai qu'un BLTouch normal. L'échec se produit seulement un sur environ 200.

@mlehnhoff quand vous aurez le temps, veuillez faire un nouveau test

et comme le correctif 2.0.x est mis à jour quotidiennement, veuillez recommencer le test tous les 14 jours environ

Recompilation de la dernière version de correction de bogue [2020.01.24.]
A fait deux tests de répétabilité de sonde, 150 chacun.

1. Chauffage du lit désactivé, terminé avec succès, écart type: 0,003928.
2. Chauffage du lit activé, échec du sondage, échec à 137.

J'ai observé un comportement similaire lors de l'utilisation de bugfix 2.0.x sur une carte SKR1.1 (LPC1768) avec un clone BLTouch (3DTouch).
J'ai essayé différentes solutions de contournement, mais sur 25 points de sonde, au moins pour un point de sonde, la broche est libérée trop tôt (comme un déploiement immédiatement suivi d'un arrimage).

@mlehnhoff quand vous aurez le temps, veuillez faire un nouveau test

@boelle : un nouveau test n'est pas nécessaire, car comme @ p3p mentionné précédemment, le problème ne se situe pas en fait dans Marlin lui-même, mais dans le framework LPC. Il a dit qu'il devait décommenter le mode de verrouillage PWM, car il ne fonctionnait pas correctement. Donc, tant que cela n'est pas corrigé, tous ceux qui veulent avoir un bltouch fonctionnant de manière fiable doivent utiliser ma solution de contournement laide, mais qui fonctionne.
Pour le moment, je n'ai malheureusement pas accès à un oscilloscope, sinon je voudrais prendre en charge P3P dans le débogage de ce problème. Si quelqu'un d'autre souhaite approfondir cela, n'hésitez pas: https://github.com/p3p/pio-framework-arduino-lpc176x/blob/master/system/lpc176x/HardwarePWM.h

J'ai ce problème.
Ender 3, SKR Mini E3 v1.2, véritable BLTouch v3.1

SKR Mini E3 v1.2 utilise un microcontrôleur STM32, pas un LPC1768.

Je me demande si le problème du verrouillage PWM est lié à l'errata LPC176x suivant:

3.13 PWM.1: Lors de la mise à jour du cycle de service pour PWM1.1 à partir de 100%,
dans certains cas, la sortie peut rester faible pendant une période PWM complète avant le
la mise à jour prend effet
Introduction:
Sur le périphérique PWM LPC176x, deux registres de correspondance peuvent être utilisés pour fournir un
sortie PWM contrôlée par front. Un registre de correspondance (PWM1MR0) contrôle le cycle PWM
taux, en réinitialisant le décompte lors de la correspondance. L'autre registre de correspondance contrôle le bord PWM
position. Par exemple, le registre de correspondance PWM1MR1 contrôle la position du bord de PWM1.
Plusieurs sorties PWM contrôlées par front unique auront toutes un front montant au début de
chaque cycle PWM, lorsqu'une correspondance PWM1MR0 se produit.
Problème:
Uniquement en mode un seul front, si le rapport cyclique pour PWM1.1 (Modulateur de largeur d'impulsion 1, canal
1 sortie) est mis à jour à partir de 100% (PWM1MR1 = PWM1MR0), puis la sortie pour PWM1.1
pourrait de manière inattendue rester faible pendant une période PWM complète avant le nouveau cycle de service souhaité
Prend effet. Ce problème affecte uniquement la sortie pour PWM1.1. Autres canaux PWM
(PWM1.2 à PWM1.6) ne sont pas concernés par ce problème.
Solution de contournement:
Un correctif logiciel peut être implémenté où l'utilisateur peut charger PWM1MR1 avec
PWM1MR0 + 1 (au moins 1) pour éviter tout retard dans la mise à jour de la sortie du PWM1.1.

Je pense que ce n'est pas le cas, car je ne pense pas que nous ayons jamais mis une broche servo en mode 100% PWM.

Là encore, sur le PWM 1.1 est utilisé pour P2_0 qui est la broche servo sur le SKR 1.3 ...

J'ai étudié un problème similaire (avec un véritable BL Touch 3.1 et un SKR PRO 1.1).
J'ai documenté ce que j'ai trouvé dans # 16986, mais en gros, j'ai trouvé que le mien était lié à XY_PROBE_SPEED. Un chiffre de 10000 fait passer le signal BL Touch d'un niveau d'impulsion à un niveau CC sur le point de sonde 15 (qui est également le premier après le premier mouvement Y), un chiffre de 6000 pour moi n'a montré aucun problème.

J'ai testé cette solution de contournement pendant plus d'un mois sur deux Ender 3 avec SKR v1.3 et 3D Touch v2 (et Pi 3B). Auparavant, j'avais toujours eu des échecs réguliers lors de l'exécution d'ABL (au moins 1 sur 3-5 impressions) où la sonde ne se déclenchait pas (mais clignotait immédiatement en rouge) et la buse s'écraserait dans le lit, sans l'extrémité Z mécanique. -arrêter je suis parti exprès. Et j'ai essayé la plupart, sinon la totalité, des permutations des configurations palpage / BL Touch dans Marlin 2.0.x.
Étant donné que j'ai eu 0 échec au cours d'innombrables sondages au cours de ces semaines (à la fois M48 et de nombreuses impressions réelles), je dois considérer cette solution de contournement comme un succès clair dans mon cas. Je mettrai bien sûr à jour mes conclusions si les résultats changent.
J'ai également testé qu'il fonctionne indépendamment de la vitesse de la sonde XY (essayé 6-8-10000 mm / s), de la vitesse de la sonde Z et sans désactiver les éléments chauffants / pas à pas pendant le palpage. Fondamentalement, la configuration du sondage dans Marlin ne semble plus être un facteur pour éviter les échecs (mais peut toujours avoir un impact sur la précision, du moins la vitesse Z l'est).
Le seul problème est que le rétroéclairage de l'écran LCD (5V) clignote temporairement pendant le sondage si son 5V est tiré du SKR, indiquant probablement une chute de tension due à la consommation de courant de la sonde (mais je ne voulais pas isoler et sonder le tout avec mon oscilloscope) . Ainsi, j'ai câblé 5V au Pi à la place (mais pourrait tout aussi bien être n'importe quelle source externe 5V) avec deux fils GND épissés près de la sonde, l'un allant au SKR et l'autre au Pi (pour la masse d'étoile d'un pauvre homme) .

@mlehnhoff
Veuillez tester la branche bugfix-2.0.x pour voir où elle en est.

Je vais tester cela sous peu sur mon véritable BLTouch, je crois que j'ai le même problème.

Edit: Pas la même carte (STM32F103RC) mais des problèmes identiques! Essayer de savoir si c'est un problème de timing ou autre chose! Mais lorsque je fais un maillage 91 UBL, j'obtiens peut-être 1 ou 2 sondes défectueuses de la même manière que celle décrite ici?

Eh bien, j'ai compris que ma carte semble utiliser le code servo «partagé». J'ai ajouté ce qui suit après quelques essais et erreurs et il semble safe_delay de 6ms / us? travaille! Le capteur semble se déclencher plus rapidement si cela a du sens? Et j'ai maintenant réussi à obtenir mon premier maillage sans aucun capteur en panne? Je garderai un œil dessus et effectuera plus de tests, mais semble initialement prometteur! C'est avec un véritable BLTouch, j'en avais commandé un deuxième pensant qu'il était défectueux! Je ne pense pas que son autre matériel car cette configuration fonctionnait correctement sur le tableau de stock d'origine, ce n'est que depuis le passage à BTT V2.0 et Marlin que ce problème s'est produit. Auparavant, j'utilisais Klipper sans problème.

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

@ aslater3 Comment puis-je savoir si ma carte (SKR Mini E3 v1.2) a un code servo «partagé»?

@boelle désolé
Mais j'ai maintenant accès à un oscilloscope et je suis prêt à l'étudier plus avant (et éventuellement à le réparer) ...

2.0.5.4 ( 2.0.x ) et bugfix-2.0.x sont deux branches différentes. Veuillez essayer la dernière version de bugfix-2.0.x et faites-nous savoir si vous rencontrez toujours ce problème.

2.0.5.4 ( 2.0.x ) et bugfix-2.0.x sont deux branches différentes. Veuillez essayer la dernière version de bugfix-2.0.x et faites-nous savoir si vous rencontrez toujours ce problème.

Oui, je sais et j'ai utilisé le dernier bugfix-2.0.x! 2.0.5.4 n'est que ce que me dit le menu LCD

Mais cela n'a pas d'importance de toute façon, car le bogue n'est pas à l'intérieur du code MarlinFw, il est à l'intérieur du pio-framework-arduino-lpc176x

On sait même quelle partie du code est à l'origine du problème: le verrouillage désactivé du HW-PWM.

Le problème est de trouver un moyen de réactiver le verrouillage sans avoir d'autres problèmes. C'est pourquoi le verrouillage a été désactivé.

Je discutais avec @ p3p à ce sujet, car j'ai enquêté sur des problèmes similaires sur d'autres plates-formes. Je ne pense pas qu'il y ait une chance que ce comportement ait été changé, et cela ne vaut pas vraiment la peine de re-tester maintenant, sauf dans le cadre de la mise en œuvre d'une solution plus permanente.

2.0.5.4 n'est que ce que me dit le menu LCD

Ensuite, vous n'utilisez pas la dernière correction de bogue. Votre écran LCD indiquera bugfix-2.0.x .

Je suis conscient du problème d'une période lors de la définition d'un cycle d'utilisation plus court après avoir déjà passé la nouvelle valeur de correspondance, actuellement, je ne sais pas comment atténuer le problème. Le matériel ne semble pas faire ce qu'il est censé faire lorsque les registres fantômes pwm sont activés.

2.0.5.4 n'est que ce que me dit le menu LCD

Ensuite, vous n'utilisez pas la dernière correction de bogue. Votre écran LCD indiquera bugfix-2.0.x .

ok, mon mauvais, j'ai accidentellement cloné la branche 2.0.x au lieu de bugfix-2.0.x ... maintenant j'ai corrigé ça -> pas de différence (bien sûr)

Je suis conscient du problème d'une période lors de la définition d'un cycle d'utilisation plus court après avoir déjà passé la nouvelle valeur de correspondance, actuellement, je ne sais pas comment atténuer le problème. Le matériel ne semble pas faire ce qu'il est censé faire lorsque les registres fantômes pwm sont activés.

@ p3p Pouvez-vous me dire quels problèmes vous avez rencontrés lorsque le verrouillage est activé?

D'après ce dont je me souviens (cela faisait longtemps que je n'avais pas débogué cela), avec les registres d'ombre activés, la largeur d'impulsion ne se mettrait sporadiquement pas à jour, comme vous pouvez l'imaginer, j'ai choisi le pépin à 1 période plutôt que cela. Cela semblait être dû à la mise à jour de la largeur d'impulsion plus d'une fois au cours de la même période, mais je n'étais pas sûr.

Un angle d'asservissement commandé doit rester au moins 20 ms pour être visible sur la sortie en tant que largeur d'impulsion modifiée.
Pour rendre la nouvelle largeur d'impulsion reconnaissable par le dispositif / servo, il doit probablement rester plusieurs impulsions.
Il est donc interdit de modifier l'angle dans au moins 20 ms.
D'après ce que @sjasonsmith a découvert pour le BL_Touch et souligné dans https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment -657406598 mieux environ 60 ms.

La mise à jour du registre fantôme plus souvent n'a pas de sens. Le registre ne doit pas être écrit plus souvent que la valeur de l'angle change. (Variable d'ombre pour le registre d'ombre?)
Il a probablement besoin d'un correctif supplémentaire à un niveau supérieur de la bibliothèque d'asservissements pour éviter des changements trop fréquents. Nous avons déjà quelque chose de similaire avec SERVO_DELAY , qui devrait à l'origine empêcher l'arrêt du signal du servo avant que le servo n'atteigne (mécaniquement) sa cible.

@AnHardt Je sais que changer les registres d'ombres plusieurs fois par période est inutile mais je ne vois pas pourquoi les changer plusieurs fois avant que les valeurs ne soient poussées vers les registres réels à la fin de la période causerait un problème, je ne sais pas quoi la solution pour arrêter l'application cliente mettant à jour trop souvent le PWM matériel serait (si tel est vraiment le problème), sans que les performances ne soient de toute façon affectées d'une manière ou d'une autre.

@AnHardt Je sais que changer les registres d'ombres plusieurs fois par période est inutile mais je ne vois pas pourquoi les changer plusieurs fois avant que les valeurs ne soient poussées vers les registres réels à la fin de la période poserait un problème,

Je ne sais pas non plus pourquoi ni s'il y a un problème. Mais si vous nous dites que cela cause des problèmes, nous devrions essayer de les éviter.
Une construction comme:

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

empêcherait au moins d'écrire plusieurs fois dans le registre fantôme avec la même valeur.

Si je me souviens bien, la dernière fois que j'ai touché le code SERVO_PROBE, avant l'apparition du BL-Touch, j'ai soigneusement évité de déplacer le servo et les steppers en même temps avec les synchronisations - mais j'ai toujours testé avec DEACTIVATE_SERVOS_AFTER_MOVE , car mes servos tremblaient lorsque le stepper se déplaçait, produisant une pause SERVO_DELAY (quelques centaines de ms) après avoir défini le servo_angle. Par rapport à cela, les délais beaucoup plus courts que je suggère maintenant sont une victoire en performance.

Si le code BL-Touch essaie de déplacer le servo et les steppers en même temps, cela ne me semble pas comme la balle que je dois jouer.

Parce que les BL-Touches veulent avoir un signal servo constamment activé, DEACTIVATE_SERVOS_AFTER_MOVE n'est pas possible. Pour les bibliothèques d'asservissement pilotées par interruption, une interruption retardée est devenue catastrophique, perturbant le signal d'asservissement. Un PWM piloté par matériel serait immunisé. Habituellement, nous n'avons qu'un seul servo.

Cependant, je suis sûr qu'un set_servo(0); set_servo(180); set_servo(0); sans pause ne provoquera absolument aucune réaction - ni sur un vrai servo, ni sur un BL-Touch.

Désolé. Mes pensées sont probablement trop concentrées sur le PWM matériel, pour le moment, où les minuteries comparent le registre ne doivent être mises à jour que de temps en temps.

Désolé. Mes pensées sont probablement trop concentrées sur le PWM matériel, pour le moment, où les minuteries comparent le registre ne doivent être mises à jour que de temps en temps.

Ce problème concerne le PWM matériel, et je suis d'accord avec tout ce que vous avez dit, je pensais juste au problème au niveau du framework, comme dans la façon de faire fonctionner le matériel de manière fiable même lorsque l'application cliente effectue une quantité folle de mises à jour (Marlin ) dans la même période. Le client s'attendra à ce que la dernière mise à jour prenne effet, plutôt que la première, et je n'ai aucun moyen de savoir qu'il n'y aura pas de mises à jour ultérieures avant la fin de la période.

Je dois revoir le problème pour voir si une nouvelle solution me vient à l'esprit, si ce diagnostic est réellement correct et que je n'étais pas simplement stupide.

J'essaierais
quand les positions courtes durables peuvent être omises:

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

fonctionnant environ toutes les 20 ms.
Cela devrait maintenir la longueur d'impulsion de sortie constante pendant au moins 3 * 20 ms, puis mettre uniquement l'angle commandé le plus récent. Cependant, il ne saura pas quel angle viendra ensuite ou si une mise à jour suivra du tout - c'est impossible à savoir - certaines quand vous devrez commencer. Cela garantit que les impulsions d'émission peuvent être lues et le registre fantôme n'est pas mis à jour très souvent.

Pour garantir que chaque mise à jour est effectuée pendant au moins ce temps, la variable volatile doit être remplacée par une file d'attente.

En vol RC, les positions intermédiaires peuvent probablement être omises. En cas de BL-Touch, le rangement, le déploiement, la réinitialisation, le changement de modes, ... sont tous également importants. En notant que cela peut être omis, chaque commande doit rester assez longtemps pour être reconnue. Il n'y a pas de bonne solution universelle pour une bibliothèque d'asservissements universelle.

De plus, pour le BL-Touch, toutes les commandes doivent être synchronisées avec les mouvements des steppers. Il vaut mieux ne pas rentrer la sonde en descendant pour la sonde. :-)
Donc, de mon point de vue, Marlin doit être responsable de ne pas mettre à jour l'angle à fréquent.

Éditer:
L'interruption de comparaison est probablement la bonne pour mettre à jour le registre de comparaison d'ombre. L'interruption pourrait alors être retardée par des interruptions de priorité plus élevée d'environ 17 ms et serait toujours à temps pour que le registre de mise à jour soit prêt pour la copie vers le registre de comparaison lorsque le débordement se produit.
Doit être possible d'arrêter l'interruption si le compteur est au-dessus de 3. Pourrait-il être redémarré lorsque inter_angle est mis à jour.

J'ai le même problème avec le SKR mini 1.1.
Quelle que soit la position que je mets, le servo va toujours au même point.

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

@Matheusschmitz le SKR mini utilise une plate-forme différente et serait unique à cause de ce problème. Certains changements ont été apportés il y a un peu plus d'une semaine pour améliorer la fiabilité BLTouch des cartes STM32F1 (comme la vôtre). Veuillez essayer d'utiliser la branche bugfix-2.0.x pour voir si cela résout votre problème.

Si vous rencontrez toujours des problèmes, veuillez en discuter dans l'un des sites d'assistance tels que Discord. Ce problème particulier devrait rester concentré sur les cartes LPC176x.

Je rencontre également ce problème avec mon clone SKR1.3 et BLTouch.
J'ai réussi à le capturer en vidéo, juste autour de 1:54:
https://www.youtube.com/watch?v=wF0Mia49ECI&t=114s
(la vidéo est en 1080p, YouTube doit la traiter)

Voici également une image montrant ce que cela fait quand cela se produit pendant UBL

J'ai essayé, comme d'autres, les différents paramètres qui pourraient aider, ils n'ont pas aidé.
Je suis sur la dernière branche bugfix-2.0.x

Même problème de mon côté.
Je vais également tester la solution de contournement

Ce problème n'a eu aucune activité au cours des 30 derniers jours. Veuillez ajouter une réponse si vous souhaitez garder ce problème actif, sinon il sera automatiquement fermé dans les 7 jours.

Je pense que cela vaut la peine de rester ouvert jusqu'à ce qu'une solution permanente puisse être trouvée.

je suis d'accord avec ce sentiment

Ce problème n'a eu aucune activité au cours des 30 derniers jours. Veuillez ajouter une réponse si vous souhaitez garder ce problème actif, sinon il sera automatiquement fermé dans les 7 jours.

Je pense que cette question devrait rester ouverte.