Marlin: [ERROR] SKR v1.3 (o cualquier otro LPC1768): problema con las señales de servo que causan problemas con bltouch

¿Puedes probar un BLTouch genuino?

¿Puedes probar un BLTouch genuino?

Además, ¿ha intentado ajustar la configuración de BLTouch en Configuration_adv.h ?: Puede ajustar configuraciones como BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE , BLTOUCH_FORCE_MODE_SET , etc.

Oh, lo siento, olvidé mencionarlo. Por supuesto, probé diferentes combinaciones de BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE e incluso DELAY_BEFORE_PROBING antes. Sin éxito.
Ahora que descubrí cuál es el problema, está claro que los retrasos más largos no ayudan. Porque el pulso incorrecto de 20 ms que lleva al bltouch a este estado de error ocurre ya un par de segundos antes de que se toque la placa de construcción.
BLTOUCH_FORCE_MODE_SET no es compatible con esta versión antigua de bltouch clone. No es "inteligente".

Y no, no tengo acceso a un BLTouch genuino. Para mí y mi antiguo clon, el truco mencionado anteriormente funciona bien, así que personalmente no necesito una solución adecuada para este problema. Pero creo que este problema debería solucionarse de todos modos, porque creo que incluso un servo real podría reaccionar en este pulso con una sacudida corta o cualquier otro comportamiento extraño.

Wow, @mlehnhoff , tu parche alivia mi dolor. SKR v1.3 + (no estoy seguro de una versión anterior o no) triaglelab 3d touch - mismos problemas. Mi propia condición de trabajo 8/10: BLTOUCH_FORCE_SW_MODE + BLTOUCH_DELAY 1000. Pero su parche funciona 10/10 sin SW_MODE y DELAY. Tnx!

Probé una sonda táctil basada en servo en un rearme (mismo MCU) y no tuve problemas, pero usé la función de desactivar después del movimiento.

No lo he intentado sin él, tenía sentido lógico desactivar el servo cuando no era necesario

Tengo un puñado de BLTouches genuinos y todos funcionan bien en un SKR 1.3 que también es LPC1768 .

Entonces, saltando el arma aquí, ¿es más probable que sea un problema de hardware (cable, conexión de ruido) o un problema de configuración del usuario?

La misma razón para la mayoría de las opciones adicionales de código / configuración de BLTouch, es un problema de clonación de BLTouch.

Tenga en cuenta que 3DTouch! = BLTouch. Hay muchos problemas cerrados relacionados con estas copias.

entonces lo llamaría un problema de hardware,

sí, ahora 3dtouch (y otros) no son un BLtouch

¿La gran Q para mí es cualquier marlin que admita los clones o si solo nos preocupan los productos genuinos?

dando un poco de pensamiento personal, no creo que sea justo que marlin deba apoyar a los clones

pero podría estar equivocado, ¿pensamientos?

Mis dos centavos, sin importar el nombre de XXtouch. Cualquiera de ellos se conecta al pin SERVOS (no al pin especial BLtouch). Los SERVOS deberían funcionar como servos.

Pero creo que este problema debería solucionarse de todos modos, porque creo que incluso un servo real podría reaccionar en este pulso con una sacudida corta o cualquier otro comportamiento extraño.
(del comentario de @mlehnhoff )

Esto no debe atribuirse al hardware de la sonda. La señal que se produce desde la placa es incorrecta y se verificó con un osciloscopio. Eso debería arreglarse.

También puedo confirmar que el comportamiento informado es muy similar al hardware BLTouch genuino cuando estaba depurando todos esos conflictos de temporizador que causaban problemas similares en las placas SKR Mini E3. Las longitudes de pulso no válidas parecían hacer que el BLTouch simplemente olvidara lo que estaba haciendo y causaba fallas.

@mlehnhoff , ¿capturó alguna imagen de su osciloscopio que demuestre el problema que pueda adjuntar a este problema?

No creo que me guste la solución actual como una solución completa, pero realmente aprecio el nivel de detalle que mlehnhoff proporcionó al describir el problema y la solución que demuestra que el pulso aparentemente es la causa raíz del problema.

Lo siento, no proporcioné la captura de pantalla del alcance de inmediato. Pensé que había hecho algunos, pero algo salió mal. Pero no me di cuenta hasta que devolví el visor (no es mío).
Pero ahora hice uno nuevo:

En la imagen se ve la transición de 1472 µs a 544 µ, pero la primera

el pulso es 20544 µs.

Además, probé un servo real y aquí está la prueba de que este problema no solo se limita a 3dtouch u otros clones.

IMG_4677.zip

El Servo debe girar de 90 ° (palanca en el medio) a 0 ° (palanca hacia abajo), pero cuando ocurre el pulso defectuoso, en realidad sube al principio, antes de bajar.

Por cierto, hay al menos ocho versiones diferentes de bltouch genuino (classic v1.0, v1.2, v1.3, smart v1.0, v2.0, v2.2, v3.0, v3.1) y no uno sabe, si todos funcionarán correctamente ;-)

Aquí hay otra pista: cuando envía el comando M280 manualmente, es muy poco probable que ocurra el problema. Escribí un guión para alternar el servo (usado en el video) lo que aumenta mucho la probabilidad:
servo_toggle.gcode.txt

Me pregunto si esto está relacionado con un problema que estoy viendo con mi BLTouch.
Enciendo mi Re-ARM a través de USB y uso M80 para encender la fuente de alimentación de 12V. Hay un convertidor reductor de 5V conectado a la fuente de alimentación de 12V que alimenta el BLTouch, por lo que el BLTouch no recibe energía hasta que se activa la fuente de 12V.
Cuando la placa se enciende, el BLTouch parpadea en rojo; esto aparentemente es algo normal si el BLTouch recibe una señal antes de encenderse, así que no me preocupa eso.
Sin embargo, cualquier intento de restablecerlo con M280 P0 S160 tiene ningún efecto. Tampoco retrae el pasador si está desplegado.
Sin embargo, M280 P0 S60 cambia correctamente al modo SW y también detiene el parpadeo.
Aparte del parpadeo y S160 aparentemente ignorados, el BLTouch parece funcionar perfectamente. Incluso cuando parpadea, se despliega, almacena y sondea correctamente: he realizado sondas de lecho completo y nunca he visto una falla de sonda y la repetibilidad es excelente.
Este es un BLTouch V3.1 genuino, no un clon.

Olvidé mencionar que verifiqué los pulsos tanto con mi mini DSO barato como con mi osciloscopio CRT grande y las longitudes de pulso parecen estar bien. También probé diferentes valores de S (de 155 a 165) sin encontrar uno que active el reinicio.

No he buscado cómo funciona la biblioteca de servos para el LPC, pero:
Una señal de servo es un PWM. Si esto se lograra con un temporizador de hardware STM32, este error probablemente se produciría al actualizar el registro de comparación de los contadores directamente, en lugar de actualizar el nuevo valor al registro de precarga del registro de comparación. Si se cambia el registro de comparación de un valor alto a un valor bajo mientras el contador se encuentra entre el valor bajo y el alto, se omite la comparación (igual), el pin no se cambia hasta que el contador rebase y luego alcanza el nuevo valor . Si se utiliza el registro de precarga, el registro de comparación se actualiza cuando el contador se sobrepasa o cuando el valor de comparación (antiguo) coincide. Esto no tiene riesgo de un pulso muy largo, solo un posible retraso de un máximo de aproximadamente un período de PWM (20 ms).
EDITAR: La posibilidad de error sería del 5% por saltar 1 ms hacia atrás.
Supongo que aquí tenemos algo parecido.

Esto se debe a que el marco lpc no está ejecutando el hardware pwm en modo de enclavamiento, (donde el registro de ancho de pulso está sombreado y bloqueado en cada período), debería ser posible hacer eso con un bit de modo simple ... pero desafortunadamente no puedo hacer que funcione de manera confiable, es una elección entre un posible error de duración de 1 período, o el ancho de pulso al azar (pero con bastante frecuencia dependiendo de la frecuencia con la que se actualiza) que no cambia en absoluto.

Se podrían hacer más investigaciones sobre el tema, pero en realidad no es un periférico complicado, perdí mucho tiempo en ese error y al final otras cosas necesitaban atención.

@mlehnhoff @kockockockoc ¿Cómo dp aplica el parche por favor?

@mlehnhoff @kockockockoc ¿Cómo dp aplica el parche por favor?

Para ser honesto, soy bastante nuevo en git y estoy contento de haber podido crear este parche a través de "git diff". Estoy seguro de que debe haber un comando git diferente para volver a aplicar este parche. Quizás @kockockockoc pueda ayudar ...
Pero para este fragmento de código muy pequeño, incluso puede hacerlo a mano. Es tan fácil como agregar las cuatro líneas que comienzan con un "+" al archivo "Marlin / src / HAL / HAL_LPC1768 / Servo.h" (por supuesto sin el "+") en la posición mostrada ...

Hola, tengo la misma placa Bigtreetech SKR v1.3 y 3D Touch pero el 3D Touch no funciona. Probé el 3dTouch usando algún código en un Arduino Mega y funciona perfectamente. Entonces, probé cualquier sugerencia que encontré y también el parche @mlehnhoff pero sigo teniendo el mismo problema = 3D Touch está congelado. Cuando Marlin inicia, el 3D Touch realiza una autocomprobación y luego el pasador se guarda y permanece en este estado para siempre sin ningún cambio (a través de M43 S o desde el menú Marlin)
Estoy realmente preocupado por eso porque no sé qué tengo que hacer para resolver este problema. Cualquier sugerencia es bienvenida.

Sospecho que este error es el mismo que informé aquí: https://github.com/MarlinFirmware/Marlin/issues/15370

Todavía estoy ejecutando una confirmación de corrección de errores del 22/6/19 sin problemas. Probé la última confirmación de corrección de errores hoy y el problema del servo sigue presente.

@ Reywas62 y todo, encontré este artículo http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html que podría resolver el problema. Aparentemente, algunas placas SKR podrían tener una señal de salida que tenga una impedancia baja (alrededor de 200 ohmios) que requeriría una cantidad significativa de corriente para funcionar correctamente (y no sucede en las placas Arduino, esa es la razón por la que mi sonda táctil 3D funciona correctamente. en el Arduino) Entonces, aparentemente no está relacionado con el firmware.

Bueno, compraría esa explicación excepto que mi placa funciona bien con una confirmación anterior de Marlin bugfix 2.0.x (22/6/19).

Puedo confirmar que la solución "rápida y sucia" de mlehnhoff está funcionando. Estoy probando una malla UBL de 9x9 con un clon BLTouch. Normalmente, 1 o 2 puntos de la malla de 81 puntos fallan cuando ejecuto la generación de malla. Pero con el "arreglo" todo funciona bien. Así que seguiré usando esta solución. Y en mi caso, creo que es un problema con el pulso largo del servo porque mi pin de empuje está desplegado y el sensor no se dispara.

Me gustaría confirmar que mi problema con 3D Touch se ha resuelto. El problema es la baja corriente de los pines SKR 1.3 Servo. Hice el circuito y lo probé con éxito. Ahora he recibido esta información después de ejecutar M43:
ENVIANDO: M43 S
Prueba de sonda servo
. usando índice: 0, ángulo de despliegue: 10, ángulo de almacenamiento: 90
. Sonda Z_MIN_PIN: 57
. Z_MIN_ENDSTOP_INVERTING: falso
. Compruebe BLTOUCH
= BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1 detectado.
* Active la sonda en 30 segundos *
. Ancho de pulso (+/- 4ms): 10
= BLTouch pre V3.1 (o compatible) detectado

Voy a experimentar con mi configuración aquí, pero tengo un servomotor SG90 y MG90 que se mueve intermitentemente hacia atrás cuando se desactiva. Mientras sostiene el interruptor Z-Probe, esto mata un poco la máquina cuando se estrella contra la cama. El último choque totalizó los soportes de las ruedas de la Creality CR10 S5. > _

Cuando tenga la oportunidad, probaré el circuito y veré si funciona. pero también voy a probar el truco del firmware. :)

Después de probar el truco del firmware, no hubo ningún cambio para mí (como sospechaba, ya que el truco corrige los clones bl-touch, no necesariamente el movimiento del servo). El Servo ocasionalmente aún retrocede aún más después de completar un movimiento.

Teniendo en cuenta eso, deshice el truco y le dije a marlin que NO desactive el servo y parece que el problema del retroceso ha desaparecido. Parece que deshabilitar el servo desencadena mi problema. Afortunadamente, el MG90 que estoy usando no muestra ninguna vibración / temblor en los ángulos que he seleccionado. :)

Definitivamente me gustaría agradecer a mlehnhoff por su gcode para probar. Cada vez que lo ejecutaba, el servo se reproducía 3 o 4 veces, y cuando le decía a marlin que mantuviera el servo habilitado, el guión funcionaba bien 3 veces seguidas. Teniendo en cuenta los informes de baja corriente, también realicé la prueba con los calentadores encendidos para cargar la fuente de alimentación. :)

No sé si importa, pero mis ángulos de servo son 172 (desplegado) y 35 (guardado) y parecía que movería el servo hacia atrás, en la misma cantidad cada vez. El servo nunca avanzó.

El hack de firmware no solucionó mi problema, pero dejar el servo habilitado evita que el servo se comporte mal, como lo hizo con DarkAlaranth. No es realmente una solución, pero una solución aceptable.

Un poco de experiencia adicional He probado esto en varias plataformas durante los últimos días y pensé que podría haber roto mis dos AntLab BLtouch, así que pedí una tercera.

Esto es lo que he observado para las siguientes plataformas.
SKR Pro V1.1 no funciona
SKR v1.3 no funciona
RAMPS 1.4 no funciona
SKR v1.4 no funciona
RAMPS 1.6 no funciona

El síntoma antes del sondeo leído en un M119
Informar el estado del final de carrera
x_min: ACTIVADO
y_min: ACTIVADO
z_min: ACTIVADO

También he ajustado el archivo de pines con los mismos resultados.

Aquí está el proceso que utilicé en varios videos de varios marlin vintage
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

Podría publicar más videos, pero lo que quiero decir es que no funciona en ninguno de ellos con 3 toques BL genuinos.

¿Ha cambiado algo en la configuración? Configuration_adv.h ahora tiene un montón de configuraciones de energía BL touch.

¿Debería haber un informe de temperatura cuando se localiza el eje Z?
Aquí está la depuración:
ENVIADO: G28 Z0
ENVIADO: M114
ENVIADO: M105
RECV: Error: !! STOP llamado debido a un error BLTouch - reiniciar con M999
[ERROR] Error: !! STOP llamado debido a un error BLTouch - reiniciar con M999

M119 en RAMPS 1.6 / MEGA2560
Lee correctamente para abrir en z-min
El sondeo parece no funcionar.

Tiene este problema.
Ender 3, SKR Mini E3 v1.2, BLTouch genuino v3.1

Funciona bien para mí con el V2
El cableado para el skr1.3 es diferente de la orientación de stock. Estoy usando la versión de lanzamiento de Marlin 2.0.1

¿Puedes probar otro BLTouch? ¿Para verificar que no es una sonda dañada?

No lo siento. Solo tengo un BLTouch normal. La falla ocurre solo una en ~ 200 aproximadamente.

@mlehnhoff cuando tenga tiempo, vuelva a probar

y como la corrección de errores 2.0.x se actualiza diariamente, vuelva a realizar la prueba, digamos cada 14 días aproximadamente

Se ha recompilado la última versión de corrección de errores [2020.01.24.]
Hice dos pruebas de repetibilidad de la sonda, 150 cada una.

1. Calefacción de la cama apagada, terminada correctamente, desviación estándar: 0,003928.
2. Calefacción de la cama encendida, sonda fallida, falla en 137.

He observado un comportamiento similar al usar bugfix 2.0.x en una placa SKR1.1 (LPC1768) con un clon BLTouch (3DTouch).
He intentado diferentes soluciones, pero de los 25 puntos de prueba, al menos para un punto de prueba, el pin se libera demasiado pronto (como una implementación seguida inmediatamente de almacenamiento).

@mlehnhoff cuando tenga tiempo, vuelva a probar

@boelle : no es necesario volver a probar, porque como @ p3p mencionó anteriormente, el problema no se encuentra en Marlin en sí, sino en el marco LPC. Dijo que tenía que descomentar el modo de bloqueo PWM porque no funcionaba correctamente. Entonces, mientras esto no se solucione, todos los que quieran tener un bltouch que funcione de manera confiable deben usar mi fea pero funcional solución.
Por el momento, lamentablemente, no tengo acceso a un osciloscopio; de lo contrario, me gustaría ayudar a P3P a depurar este problema. Si alguien más desea profundizar en esto, no dude en: https://github.com/p3p/pio-framework-arduino-lpc176x/blob/master/system/lpc176x/HardwarePWM.h

Tiene este problema.
Ender 3, SKR Mini E3 v1.2, BLTouch genuino v3.1

SKR Mini E3 v1.2 utiliza un microcontrolador STM32, no un LPC1768.

Me pregunto si el problema con el bloqueo de PWM está relacionado con las siguientes erratas LPC176x:

3.13 PWM.1: Al actualizar el ciclo de trabajo para PWM1.1 desde 100%, en
En algunos casos, la salida puede permanecer baja durante un período completo de PWM antes de
la actualización entra en vigor
Introducción:
En el periférico LPC176x PWM, se pueden utilizar dos registros de coincidencia para proporcionar un único
Salida PWM controlada por borde. Un registro de coincidencia (PWM1MR0) controla el ciclo PWM
tasa, restableciendo el recuento tras la coincidencia. El otro registro de coincidencia controla el borde PWM
posición. Como ejemplo, el registro de coincidencia PWM1MR1 controla la posición del borde de PWM1.
Múltiples salidas PWM controladas por un solo borde tendrán todas un borde ascendente al comienzo de
cada ciclo de PWM, cuando se produce una coincidencia de PWM1MR0.
Problema:
Solo en el modo de un solo borde, si el ciclo de trabajo para PWM1.1 (Modulador de ancho de pulso 1, canal
1 salida) se actualiza desde el 100% (PWM1MR1 = PWM1MR0), luego la salida para PWM1.1
inesperadamente podría permanecer bajo durante un período completo de PWM antes del nuevo ciclo de trabajo deseado
Toma efecto. Este problema solo afecta a la salida de PWM1.1. Otros canales PWM
(PWM1.2 a PWM1.6) no se ven afectados por este problema.
Solución alterna:
Se puede implementar una solución de software donde el usuario puede cargar PWM1MR1 con
PWM1MR0 + 1 (al menos 1) para evitar retrasos en la actualización de salida del PWM1.1.

Espero que no sea así, ya que no creo que alguna vez pongamos un pin de servo en modo 100% PWM.

Por otra parte, en el PWM 1.1 se usa para P2_0, que es el pin del servo en el SKR 1.3 ...

He estado investigando un problema similar (con un BL Touch 3.1 genuino y un SKR PRO 1.1).
He documentado lo que encontré en # 16986 pero básicamente encontré que el mío estaba relacionado con XY_PROBE_SPEED. Una cifra de 10000 hace que la señal BL Touch cambie de un pulso a un nivel de CC en el punto de sondeo 15 (que también es el primero después del primer movimiento Y), una cifra de 6000 para mí no mostró ningún problema.

He probado esta solución durante más de un mes en dos Ender 3 con SKR v1.3 y 3D Touch v2 (y Pi 3B). Anteriormente, siempre había tenido fallas regulares al realizar ABL (al menos 1 en 3-5 impresiones) donde la sonda no se disparaba (pero parpadeaba en rojo inmediatamente) y la boquilla se estrellaba contra la cama, si no fuera por el extremo Z mecánico -Para que salí a propósito. Y he probado la mayoría, si no todas, las permutaciones de las configuraciones de sondeo / BL Touch en Marlin 2.0.x.
Dado que no he tenido fallas durante innumerables pruebas durante estas semanas (tanto M48 como muchas impresiones reales), debo considerar que esta solución fue un éxito claro en mi caso. Por supuesto, actualizaré mis hallazgos si cambian los resultados.
También he probado que funciona independientemente de la velocidad de la sonda XY (probé 6-8-10000 mm / s), la velocidad de la sonda Z y sin desactivar los calentadores / steppers durante la prueba. Básicamente, la configuración del sondeo en Marlin ya no parece un factor para evitar fallas (pero aún puede afectar la precisión, al menos la velocidad Z lo es).
El único problema es que la luz de fondo de la pantalla LCD (5 V) parpadea temporalmente durante la prueba si sus 5 V se extraen del SKR, lo que probablemente indica una caída de voltaje debido al consumo de corriente de la sonda (pero no quería aislar y sondear todo con mi alcance) . Por lo tanto, conecté 5V al Pi en su lugar (pero podría ser cualquier fuente externa de 5V) con dos cables GND empalmados cerca de la sonda, uno corriendo hacia el SKR y el otro hacia el Pi (para la tierra de estrella de un hombre pobre) .

@mlehnhoff
Pruebe la rama bugfix-2.0.x para ver dónde se encuentra.

Lo probaré en breve en mi BLTouch genuino, creo que tengo el mismo problema.

Editar: ¡No es la misma placa (STM32F103RC) pero problemas idénticos! ¡Tratando de averiguar si es un problema de tiempo o algo más! Pero al hacer una malla 91 UBL obtengo tal vez 1 o 2 sondas fallidas de la misma manera que se describe aquí.

Bueno, me di cuenta de que mi placa parece estar usando el código de servo 'compartido'. He agregado lo siguiente después de algunas pruebas y errores y parece safe_delay de 6ms / us. ¡está trabajando! El sensor parece activarse más rápido si eso tiene algún sentido. ¿Y ahora he logrado obtener mi primera malla sin que falle ningún sensor? Lo vigilaré y ejecutará más pruebas, ¡pero al principio parece prometedor! Esto es con un BLTouch genuino, ¡había pedido un segundo pensando que estaba defectuoso! No creo que su otro hardware ya que esta configuración funcionaba bien en el tablero original, solo que desde que se mudó a BTT V2.0 y Marlin ha ocurrido este problema. Anteriormente, estaba ejecutando Klipper sin problemas.

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

@ aslater3 ¿Cómo puedo saber si mi placa (SKR Mini E3 v1.2) tiene un código de servo 'compartido'?

@boelle lo siento, estaba bastante ocupado con cosas diferentes. Acabo de probar el último bugfix-2.0.x (que parece ser 2.0.5.4). El problema sigue presente. Eso se debe a que todavía no está arreglado en pio-framework-arduino-lpc176x.
Pero ahora tengo acceso a un osciloscopio y estoy dispuesto a investigarlo más (y eventualmente arreglarlo) ...

2.0.5.4 ( 2.0.x ) y bugfix-2.0.x son dos ramas diferentes. Pruebe el último bugfix-2.0.x y avísenos si todavía tiene este problema.

2.0.5.4 ( 2.0.x ) y bugfix-2.0.x son dos ramas diferentes. Pruebe el último bugfix-2.0.x y avísenos si todavía tiene este problema.

Sí, lo sé y utilicé el último bugfix-2.0.x. 2.0.5.4 es solo lo que me dice el menú LCD

Pero esto no importa de todos modos, porque el error no está dentro del Código MarlinFw, está dentro del pio-framework-arduino-lpc176x

Incluso es bien conocido qué parte del código está causando el problema: el bloqueo desactivado del HW-PWM.

El problema es encontrar una manera de volver a habilitar el enganche sin tener otros problemas. Por eso se ha desactivado el enclavamiento.

Estaba charlando con @ p3p sobre esto, ya que he estado investigando problemas similares en otras plataformas. No creo que haya ninguna posibilidad de que este comportamiento haya cambiado, y realmente no vale la pena volver a probarlo ahora, a menos que sea como parte de la implementación de una solución más permanente.

2.0.5.4 es solo lo que me dice el menú LCD

Entonces no está utilizando la última corrección de errores. Su pantalla LCD dirá bugfix-2.0.x .

Soy consciente de la falla de 1 período al establecer un ciclo de trabajo más corto después de pasar el nuevo valor de coincidencia, actualmente no estoy seguro de cómo mitigar el problema. El hardware no parece hacer lo que se supone que debe hacer cuando los registros de sombra pwm están habilitados.

2.0.5.4 es solo lo que me dice el menú LCD

Entonces no está utilizando la última corrección de errores. Su pantalla LCD dirá bugfix-2.0.x .

está bien, mi culpa, accidentalmente cloné la rama 2.0.x en lugar de bugfix-2.0.x ... ahora lo arreglé -> sin diferencia (por supuesto)

Soy consciente de la falla de 1 período al establecer un ciclo de trabajo más corto después de pasar el nuevo valor de coincidencia, actualmente no estoy seguro de cómo mitigar el problema. El hardware no parece hacer lo que se supone que debe hacer cuando los registros de sombra pwm están habilitados.

@ p3p ¿Puede decirme qué problemas experimentó cuando habilitó el bloqueo?

Por lo que recuerdo (ha pasado mucho tiempo desde que estaba depurando esto), con los registros de sombra habilitados, el ancho de pulso no se actualizaba esporádicamente en absoluto, como pueden imaginar, elegí el error de 1 período en lugar de eso. Posiblemente parecía deberse a la actualización del ancho de pulso más de una vez en el mismo período, pero no estaba seguro.

Un ángulo de servo comandado debe permanecer al menos 20 ms para ser visible en la salida como un ancho de pulso modificado.
Para que el dispositivo / servo reconozca el nuevo ancho de pulso, es probable que deba mantener varios pulsos.
Por lo tanto, se debe prohibir cambiar el ángulo en al menos 20 ms.
De lo que @sjasonsmith descubrió para BL_Touch y señaló en https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment -657406598 mejor alrededor de 60 ms.

Actualizar el registro de sombra con más frecuencia no tiene sentido. El registro no debe escribirse con más frecuencia que el valor del ángulo cambia. (¿Variable de sombra para el registro de sombra?)
Es probable que necesite un parche adicional en un nivel superior de la biblioteca de servos para evitar cambios demasiado frecuentes. Ya tenemos algo similar con SERVO_DELAY , originalmente debería evitarse el apagado de la señal del servo antes de que el servo (mecánicamente) llegue a su objetivo.

@AnHardt Sé que cambiar los registros de sombra varias veces por período no tiene sentido, pero no veo por qué cambiarlos varias veces antes de que los valores se envíen a los registros reales al final del período causaría un problema, no estoy seguro de qué la solución para detener la actualización de la aplicación cliente del hardware PWM con demasiada frecuencia sería (si ese es realmente el problema), sin un impacto significativo en el rendimiento de una forma u otra.

@AnHardt Sé que cambiar los registros de sombra varias veces por período no tiene sentido, pero no veo por qué cambiarlos varias veces antes de que los valores se envíen a los registros reales al final del período causaría un problema,

Tampoco sé por qué o si hay un problema. Pero si nos dice que causa problemas, debemos tratar de evitarlo.
Una construcción como:

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

al menos evitaría escribir varias veces en el registro de sombra con el mismo valor.

Si recuerdo correctamente, la última vez que toqué el código SERVO_PROBE, antes de que apareciera el BL-Touch, evité cuidadosamente mover el servo y los steppers al mismo tiempo con las sincronizaciones, pero siempre probé con DEACTIVATE_SERVOS_AFTER_MOVE , porque mis servos temblaron cuando el paso a paso se movía, produciendo una pausa de SERVO_DELAY (unos cientos de ms) después de configurar el servo_angle. En comparación con eso, los retrasos mucho más cortos que sugiero ahora son una victoria en el rendimiento.

Si el código BL-Touch intenta mover servo y steppers al mismo tiempo, no me siento como la pelota que tengo que jugar.

Debido a que los BL-Touches quieren tener una señal de servo constantemente activada, DEACTIVATE_SERVOS_AFTER_MOVE no es posible. Para las bibliotecas de servo controladas por interrupciones, una interrupción retrasada se volvió catastrófica, alterando la señal del servo. Un PWM impulsado por hardware sería inmune. Normalmente tenemos un solo servo.

Sin embargo, estoy bastante seguro de que un set_servo(0); set_servo(180); set_servo(0); sin pausas no provocará ninguna reacción, ni en un servo real ni en un BL-Touch.

Lo siento. Es probable que mis pensamientos estén demasiado centrados en el hardware PWM, en este momento, donde el registro de comparación de temporizadores solo tiene que actualizarse de vez en cuando.

Lo siento. Es probable que mis pensamientos estén demasiado centrados en el hardware PWM, en este momento, donde el registro de comparación de temporizadores solo tiene que actualizarse de vez en cuando.

Este problema es con el hardware PWM, y estoy de acuerdo con todo lo que dijo, solo estaba pensando en el problema a nivel de marco, como en cómo hacer que el hardware funcione de manera confiable incluso cuando la aplicación cliente está haciendo una gran cantidad de actualizaciones (Marlin ) en el mismo período. El cliente esperará que entre en vigor la última actualización, en lugar de la primera, y no tengo forma de saber que no habrá actualizaciones posteriores antes de que finalice el período.

Tendré que volver a mirar el problema para ver si se me ocurre una nueva solución, y si ese diagnóstico es realmente correcto y no solo estaba siendo estúpido.

Lo intentaría
cuándo se pueden omitir posiciones de corta duración:

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

corriendo aproximadamente cada 20 ms.
Eso debería mantener constante la longitud del pulso de salida durante al menos 3 * 20 ms y luego colocar solo el ángulo ordenado más nuevo. Sin embargo, no sabrá qué ángulo viene a continuación o si seguirá una actualización, eso es imposible de saber, y algunas de cuándo tendrá que comenzar. Solo garantiza que los pulsos de envío se pueden leer y que el registro de sombra no se actualiza con mucha frecuencia.

Para garantizar que todas y cada una de las actualizaciones se realicen durante al menos ese tiempo, la variable volátil debe ser reemplazada por una cola.

En el vuelo RC, las posiciones intermedias probablemente se pueden omitir. En caso de almacenamiento, despliegue, puesta a cero, cambio de modo de BL-Touch, ... es igualmente importante. Si se nota esto, se puede omitir, cada comando debe permanecer el tiempo suficiente para ser reconocido. No existe una solución universal correcta para una biblioteca de servos universal.

Además, para el BL-Touch, todos los comandos deben estar sincronizados con los movimientos de los pasos. Es mejor omitir la retracción de la sonda mientras se baja por la sonda. :-)
Entonces, desde mi punto de vista, Marlin debe ser responsable de no actualizar el ángulo a frecuentes.

Editar:
Es probable que la interrupción de comparación sea la correcta para actualizar el registro de comparación de sombra. Entonces, la interrupción podría retrasarse por interrupciones de mayor prioridad en aproximadamente 17 ms y aún estaría a tiempo de tener el registro de actualización listo para la copia en el registro de comparación cuando ocurra el desbordamiento.
Debería ser posible detener la interrupción si el contador está por encima de 3. Podría reiniciarse cuando se actualice inter_angle.

Tengo el mismo problema con el SKR mini 1.1.
No importa la posición que coloque, el servo siempre va al mismo punto.

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

@Matheusschmitz, el SKR mini usa una plataforma diferente y sería único en este tema. Se realizaron algunos cambios hace poco más de una semana para mejorar la confiabilidad de BLTouch para las placas STM32F1 (como la suya). Intente usar la rama bugfix-2.0.x para ver si resuelve su problema.

Si aún tienes problemas, ve a discutir en uno de los lugares de apoyo como Discord. Este problema en particular debería permanecer centrado en las placas LPC176x.

También me encuentro con este problema con mi clon SKR1.3 y BLTouch.
Logré capturarlo en video, alrededor de la marca 1:54:
https://www.youtube.com/watch?v=wF0Mia49ECI&t=114s
(el video es 1080p YouTube tiene que procesarlo)

Aquí también hay una imagen que muestra lo que hace cuando sucede durante UBL

He probado, como otros, las distintas configuraciones que podrían ayudar, pero no ayudaron.
Estoy en la última rama bugfix-2.0.x

El mismo problema de mi parte.
También probaré la solución alternativa

Este problema no ha tenido actividad en los últimos 30 días. Agregue una respuesta si desea mantener activo este problema; de lo contrario, se cerrará automáticamente dentro de los 7 días.

Creo que vale la pena mantenerlo abierto hasta que se pueda encontrar una solución permanente.

Estoy de acuerdo con ese sentimiento

Este problema no ha tenido actividad en los últimos 30 días. Agregue una respuesta si desea mantener activo este problema; de lo contrario, se cerrará automáticamente dentro de los 7 días.

Creo que este tema debería mantenerse abierto.