Marlin: [BUG] SKR v1.3 (ou qualquer outro LPC1768): problema com sinais servo que causam problemas com bltouch

Você consegue experimentar um BLTouch genuíno?

Você consegue experimentar um BLTouch genuíno?

Além disso, você já tentou ajustar as configurações do BLTouch em Configuration_adv.h ?: Você pode ajustar configurações como BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE , BLTOUCH_FORCE_MODE_SET , etc.

Oh, desculpe, esqueci de mencionar. Claro que eu tentei diferentes combinações de BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE e até DELAY_BEFORE_PROBING antes. Sem sucesso.
Agora que descobri qual é o problema, é claro, que atrasos maiores não ajudam. Porque o pulso errado de 20ms que traz o bltouch a este estado de erro acontece alguns segundos antes de a placa de construção ser tocada.
BLTOUCH_FORCE_MODE_SET não é suportado por esta versão antiga do clone do bltouch. Não é um "inteligente".

E não, eu não tenho acesso a um BLTouch genuíno. Para mim e meu clone antigo, o hack mencionado acima funciona bem, então, pessoalmente, não preciso de uma correção adequada para este problema. Mas eu acho que esse problema deve ser corrigido de qualquer maneira, porque eu acho que até mesmo um servo real poderia reagir a este pulso com uma agitação curta ou qualquer outro comportamento estranho.

Uau, @mlehnhoff , seu patch alivia minha dor. SKR v1.3 + (não tenho certeza sobre uma versão mais antiga ou não) triaglelab 3d touch - mesmos problemas. Minha própria condição de trabalho 8/10: BLTOUCH_FORCE_SW_MODE + BLTOUCH_DELAY 1000. Mas seu patch funciona 10/10 sem SW_MODE e DELAY. Tnx!

Eu testei um apalpador de toque baseado em servo em um rearme (mesmo MCU) e não tive problemas, mas usei o recurso desativar após o movimento.

eu não tentei sem ele, juse faz sentido lógico desativar o servo quando não é necessário

Eu tenho um punhado de BLTouches genuínos e todos eles funcionam bem em um SKR 1.3 que também é LPC1768 .

Portanto, é mais provável que seja um problema de hardware (fio, conexão de ruído) ou um problema de configuração do usuário?

Mesmo motivo para a maioria das opções extras de código / configuração do BLTouch, é um problema de clone do BLTouch.

Lembre-se de que 3DTouch! = BLTouch. Existem muitos problemas fechados relacionados a essas cópias.

eu chamaria de problema de hardware então,

sim, agora 3dtouch (e outros) não são um BLtouch

o grande Q para mim é o que o marlin suporta os clones ou se apenas nos preocupamos com os produtos genuínos?

pensando um pouco, não acho justo que o marlin apóie os clones

mas eu posso estar errado, pensamentos?

Meus dois centavos, não importa qual seja o nome de XXtouch. Qualquer um deles se conecta ao pino SERVOS (não ao pino especial BLtouch). O SERVOS deve funcionar como um servo.

Mas eu acho que esse problema deve ser corrigido de qualquer maneira, porque eu acho que até mesmo um servo real poderia reagir a este pulso com uma agitação curta ou qualquer outro comportamento estranho.
(do comentário de @mlehnhoff )

Isso não deve ser atribuído ao hardware da sonda. O sinal produzido pela placa está incorreto e foi verificado por meio de um osciloscópio. Isso deve ser consertado.

Também posso confirmar que o comportamento relatado é muito semelhante ao hardware BLTouch genuíno quando estava depurando todos aqueles conflitos de temporizador causando problemas semelhantes em placas SKR Mini E3. Comprimentos de pulso inválidos pareciam fazer o BLTouch simplesmente esquecer o que estava fazendo e causar falhas.

@mlehnhoff , você capturou alguma imagem do seu osciloscópio que demonstra o problema, que você poderia anexar a este problema?

Não acho que goste da solução alternativa atual como uma solução completa, mas realmente aprecio o nível de detalhes que mlehnhoff forneceu descrevendo o problema e a solução alternativa demonstrando que o pulso aparentemente é a causa raiz do problema.

Desculpe, não forneci a captura de tela do escopo imediatamente. Achei que tinha feito, mas algo deu errado. Mas não percebi até ter devolvido a luneta (não é minha).
Mas agora eu fiz um novo:

Na foto você vê a transição de 1472µs para 544µs, mas o primeiro novo

pulso é de 20544 µs.

Além disso, experimentei um servo real e aqui está a prova de que esse problema não se limita apenas ao 3dtouch ou outros clones.

IMG_4677.zip

O Servo deve girar de 90 ° (alavanca no meio) a 0 ° (alavanca para baixo), mas quando ocorre o pulso defeituoso, ele realmente sobe primeiro, antes de descer.

A propósito, existem pelo menos oito versões diferentes do genuíno bltouch (clássico v1.0, v1.2, v1.3, smart v1.0, v2.0, v2.2, v3.0, v3.1) e não sabe-se, se todos eles funcionarão corretamente ;-)

Aqui está outra dica: Quando você envia o comando M280 manualmente, é muito improvável que o problema ocorra. Eu escrevi um script para alternar o servo (usado no vídeo) que aumenta muito a probabilidade:
servo_toggle.gcode.txt

Eu me pergunto se isso está relacionado a um problema que estou vendo com meu BLTouch.
Eu ligo meu Re-ARM via USB e uso M80 para ligar a fonte de alimentação de 12V. Há um conversor buck de 5 V conectado à fonte de alimentação de 12 V que alimenta o BLTouch, portanto, o BLTouch não recebe energia até que a fonte de 12 V seja ativada.
Quando a placa é ligada, o BLTouch pisca em vermelho - isso é aparentemente normal se o BLTouch receber um sinal antes de ligar, então não estou preocupado com isso.
No entanto, qualquer tentativa de redefini-lo com M280 P0 S160 tem absolutamente nenhum efeito. Nem retrai o pino se for implantado.
No entanto, M280 P0 S60 muda com sucesso para o modo SW e também pára de piscar.
Além de piscar e S160 aparentemente ser ignorado, o BLTouch parece funcionar perfeitamente. Mesmo quando está piscando, ele desdobra, retrai e sonda - eu fiz sondagens de leito completo e nunca vi uma falha de sonda e a repetibilidade é excelente.
Este é um BLTouch V3.1 genuíno - não um clone.

Esqueci de mencionar que verifiquei os pulsos com meu mini DSO barato e meu grande osciloscópio CRT e os comprimentos de pulso parecem bons. Também tentei diferentes valores de S (de 155 a 165) sem encontrar um que acione a reinicialização.

Eu não pesquisei como funciona a biblioteca servo para o LPC - mas:
Um sinal servo é um PWM. Se isso fosse realizado com um temporizador de hardware STM32, esse erro provavelmente seria causado pela atualização direta do registro de comparação dos contadores, em vez de atualizar o novo valor para o registro de pré-carga do registro de comparação. Se alterar o registro de comparação de um valor alto para um valor baixo enquanto o contador está entre os valores baixo e alto, a comparação (igual) é ignorada, o pino não é alterado até que o contador ultrapasse e alcance o novo valor . Se o registro de pré-carga for usado, o registro de comparação será atualizado quando o contador ultrapassar o limite ou quando o valor de comparação (antigo) corresponder. Não há risco de um pulso loooongo, apenas um possível atraso de no máximo cerca de um PWM-periodo (20 ms).
EDIT: A chance de erro seria de 5% por retrocesso de 1 ms.
Suponho que aqui temos algo semelhante.

Isso ocorre porque a estrutura lpc não está executando o pwm de hardware no modo de travamento (onde o registro de largura de pulso é sombreado e travado em cada período), deveria ser possível fazer isso com um bit de modo simples .. mas infelizmente não posso fazê-lo funcionar de forma confiável, é uma escolha entre um possível glitch de duração de 1 período ou a largura de pulso aleatoriamente (mas com bastante frequência, dependendo da frequência com que é atualizado) sem mudar.

Mais pesquisas sobre o assunto poderiam ser feitas, mas não é realmente um periférico complicado, perdi muito tempo naquele bug e no final outras coisas precisaram de atenção.

@mlehnhoff @kockockockoc Como você aplica o patch, por favor?

@mlehnhoff @kockockockoc Como você aplica o patch, por favor?

Para ser honesto, sou muito novo no git e estou feliz por poder criar esse patch via "git diff". Tenho certeza de que deve haver um comando git diferente para aplicar esse patch de volta. Talvez @kockockockoc possa ajudar ...
Mas, para este fragmento de código muito pequeno, você pode até fazer isso manualmente. É tão fácil quanto adicionar as quatro linhas que começam com um "+" ao arquivo "Marlin / src / HAL / HAL_LPC1768 / Servo.h" (claro, sem o "+") na posição mostrada ...

Oi, eu tenho a mesma placa Bigtreetech SKR v1.3 e 3D Touch, mas o 3D Touch não funciona. Testei o 3dTouch usando alguns códigos em um Arduino Mega e funciona perfeitamente. Então, tentei qualquer sugestão que encontrei e também o patch @mlehnhoff, mas ainda estou tendo o mesmo problema = 3D Touch está congelado. Quando o Marlin inicia, o 3D Touch faz um autoteste e, em seguida, o pino é guardado e permanece neste estado para sempre, sem qualquer alteração (através do M43 S ou do menu do Marlin)
Estou muito preocupado com isso porque não sei o que tenho que fazer para resolver este problema. Qualquer sugestão é bem-vinda.

Suspeito que esse bug seja o mesmo que relatei aqui: https://github.com/MarlinFirmware/Marlin/issues/15370

Ainda estou executando um commit de correção de bug de 22/06/19 sem problemas. Tentei o commit de correção de bug mais recente hoje e o problema do servo ainda está presente.

@ Reywas62 e todos, encontrei este artigo http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html que pode resolver o problema. Aparentemente, algumas placas SKR poderiam ter um sinal de saída de baixa impedância (em torno de 200 ohms) que exigiria uma quantidade significativa de corrente para funcionar corretamente (e isso não acontece nas placas Arduino, por isso meu apalpador 3D funciona corretamente no Arduino) Então, aparentemente não está relacionado a firmware.

Bem, eu compraria essa explicação, exceto que minha placa funciona bem com um commit anterior do Marlin bugfix 2.0.x (22/06/19).

Posso confirmar que a solução "rápida e suja" de mlehnhoff está funcionando. Estou testando uma malha UBL 9x9 com um clone BLTouch. Normalmente 1 ou 2 pontos da malha de 81 pontos estão falhando quando executo a geração da malha. Mas com o "conserto" tudo funciona bem. Portanto, continuarei a usar essa solução. E no meu caso, acho que é um problema com o pulso de servo longo porque meu pino está implantado e o sensor não dispara.

Gostaria de confirmar que meu problema com o 3D Touch foi resolvido. O problema é a baixa corrente dos pinos do servo SKR 1.3. Eu fiz o circuito e testei com sucesso. Agora recebi essas informações após executar o M43:
ENVIANDO: M43 S
Teste de sonda servo
. usando o índice: 0, ângulo de implantação: 10, ângulo de recolhimento: 90
. Sonda Z_MIN_PIN: 57
. Z_MIN_ENDSTOP_INVERTING: falso
. Verifique se há BLTOUCH
= BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1 detectado.
* Acione a sonda em 30 segundos *
. Largura de pulso (+/- 4ms): 10
= BLTouch pré V3.1 (ou compatível) detectado

Vou experimentar minha configuração aqui, mas tenho um servo motor SG90 e um MG90 que se move intermitentemente para trás quando desabilitado. Como está segurando o interruptor Z-Probe, isso meio que mata a máquina quando ela bate na cama. A última colisão totalizou os suportes de roda do Creality CR10 S5. > _

Quando tiver chance, vou tentar o circuito e ver se resolve isso. mas também vou tentar o hack do firmware. :)

Depois de tentar o hack do firmware, não houve nenhuma mudança para mim (como eu suspeitava, já que o hack corrige clones de bl-touch, não necessariamente o movimento do servo). O Servo ocasionalmente ainda se moveria para trás depois de completar um movimento.

Considerando isso, desfiz o hack e disse ao marlin para NÃO desabilitar o servo e parece que o problema de voltar foi embora. Parece que desativar o servo aciona meu problema. Felizmente, o MG90 que estou usando não mostra nenhuma vibração / tremor nos ângulos que selecionei. :)

Eu definitivamente gostaria de agradecer a mlehnhoff por seu gcode para testar. Toda vez que eu o executava, o servo tocava 3 ou 4 vezes, e quando eu dizia ao marlin para manter o servo ativado, o script rodava bem 3 vezes seguidas. Considerando os relatos de baixa corrente, também fiz o teste com os aquecedores ligados para colocar a PSU sob carga. :)

Não sei se isso importa, mas os ângulos do meu Servo são 172 (implantado) e 35 (retraído) e parecia que moveria o servo para trás, na mesma quantidade todas as vezes. O servo nunca avançou.

O hack do firmware não corrigiu meu problema, mas deixar o servo habilitado impede o servo de se comportar mal, como aconteceu com DarkAlaranth. Não é realmente uma correção, mas uma solução alternativa aceitável.

Um pouco mais de experiência Eu tentei isso em várias plataformas nos últimos dias e pensei que poderia ter quebrado meus dois AntLab BLtouch, então pedi um terceiro.

Aqui está o que observei para as seguintes plataformas
SKR Pro V1.1 não funciona
SKR v1.3 não funciona
RAMPS 1.4 não funciona
SKR v1.4 não funciona
RAMPS 1.6 não funciona

O sintoma antes da sondagem é lido em um M119
Relatório de status de parada final
x_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED

Eu ajustei o arquivo de pinos também com os mesmos resultados.

Aqui está o processo que usei em vários vídeos de várias safras 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

Eu poderia postar mais vídeos, mas meu ponto é que não está funcionando em nenhum deles com 3 toques BL genuínos.

Algo mudou na configuração? O configuration_adv.h agora tem um monte de configurações de energia de toque BL.

Deve haver um relatório de temperatura ao retornar ao eixo Z?
Aqui está a depuração:
ENVIADO: G28 Z0
ENVIADO: M114
ENVIADO: M105
RECV: Erro: !! STOP chamado devido ao erro BLTouch - reinicie com M999
[ERROR] Erro: !! STOP chamado devido ao erro BLTouch - reinicie com M999

M119 em RAMPS 1.6 / MEGA2560
Lê corretamente para abrir em z-min
A sondagem parece não funcionar.

Tem esse problema.
Ender 3, SKR Mini E3 v1.2, BLTouch v3.1 genuíno

Funciona bem para mim com o V2
A fiação para o skr1.3 é diferente da orientação do estoque. Estou usando a versão de lançamento do Marlin 2.0.1

Você consegue experimentar outro BLTouch? Para verificar se não é uma sonda danificada?

Não, desculpe. Eu só tenho um BLTouch normal. A falha ocorre apenas uma em cerca de 200.

@mlehnhoff quando você tiver tempo, faça um novo teste

e como bugfix 2.0.x é atualizado diariamente, por favor, teste novamente a cada 14 dias ou mais

Recompilou a versão de correção de bug mais recente [2020.01.24.]
Fiz teste de repetibilidade de duas sondas, 150 cada.

1. Aquecimento da cama desligado, concluído com sucesso, desvio padrão: 0,003928.
2. Aquecimento da cama LIGADO, falha na sondagem, falha em 137.

Eu observei um comportamento semelhante ao usar bugfix 2.0.x em uma placa SKR1.1 (LPC1768) com um clone BLTouch (3DTouch).
Eu tentei diferentes soluções alternativas, mas de 25 pontos de sondagem, pelo menos para um ponto de sondagem o pino é liberado muito cedo (como um lançamento seguido imediatamente por retração).

@mlehnhoff quando você tiver tempo, faça um novo teste

@boelle : o reteste não é necessário, porque como @ p3p mencionou anteriormente, o problema não está localizado no Marlin em si, mas na estrutura LPC. Ele disse que teve que remover o comentário do Modo de travamento PWM, porque ele não funcionou corretamente. Então, desde que isso não seja consertado, todo mundo que quiser ter um bltouch que funcione de maneira confiável terá que usar minha solução alternativa feia, mas funcional.
No momento, infelizmente, não tenho acesso a um osciloscópio, caso contrário, gostaria de oferecer suporte ao P3P na depuração deste problema. Se mais alguém quiser se aprofundar nisso, fique à vontade: https://github.com/p3p/pio-framework-arduino-lpc176x/blob/master/system/lpc176x/HardwarePWM.h

Tem esse problema.
Ender 3, SKR Mini E3 v1.2, BLTouch v3.1 genuíno

SKR Mini E3 v1.2 usa um microcontrolador STM32, não um LPC1768.

Gostaria de saber se o problema com travamento de PWM está relacionado à seguinte errata LPC176x:

3.13 PWM.1: Ao atualizar o ciclo de trabalho para PWM1.1 de 100%, em
alguns casos, a saída pode permanecer baixa por um período PWM completo antes do
atualização entra em vigor
Introdução:
No periférico PWM LPC176x, dois registros de correspondência podem ser usados ​​para fornecer um único
saída PWM controlada por borda. Um registro de correspondência (PWM1MR0) controla o ciclo PWM
taxa, redefinindo a contagem após a partida. O outro registro de correspondência controla a borda PWM
posição. Como exemplo, o registro de correspondência PWM1MR1 controla a posição da borda de PWM1.
Várias saídas PWM controladas por uma única borda terão uma borda ascendente no início de
a cada ciclo PWM, quando ocorre uma correspondência PWM1MR0.
Problema:
Apenas no modo de borda única, se o ciclo de trabalho para PWM1.1 (Modulador de largura de pulso 1, canal
1 saída) é atualizada de 100% (PWM1MR1 = PWM1MR0), então a saída para PWM1.1
pode permanecer inesperadamente baixo por um período PWM completo antes do novo ciclo de trabalho desejado
entra em vigor. Esse problema afeta apenas a saída para PWM1.1. Outros canais PWM
(PWM1.2 a PWM1.6) não são afetados por esse problema.
Gambiarra:
Uma correção de software pode ser implementada onde o usuário pode carregar PWM1MR1 com
PWM1MR0 + 1 (pelo menos 1) para evitar atrasos na atualização da saída do PWM1.1.

Imagino que não seja, já que não acho que jamais colocaríamos um pino servo no modo 100% PWM.

Então, novamente, no PWM 1.1 é usado para P2_0 que é o pino do servo no SKR 1.3 ...

Estive investigando um problema semelhante (com um BL Touch 3.1 genuíno e um SKR PRO 1.1).
Eu documentei o que encontrei em # 16986, mas basicamente descobri que o meu estava relacionado ao XY_PROBE_SPEED. Uma cifra de 10000 faz com que o sinal BL Touch mude de um pulso para um nível DC no ponto de sondagem 15 (que também é o primeiro após o primeiro movimento Y), uma cifra de 6.000 para mim não mostrou nenhum problema.

Eu testei essa solução alternativa por mais de um mês em dois Ender 3 com SKR v1.3 e 3D Touch v2 (e Pi 3B). Anteriormente, eu sempre tive falhas regulares ao realizar ABL (pelo menos 1 em 3-5 impressões) onde a sonda não disparava (mas piscava em vermelho imediatamente) e o bico colidia com a cama, não fosse pela extremidade Z mecânica -Pare eu deixei de propósito. E eu tentei a maioria, senão todas, as permutações das configurações de sondagem / toque BL no Marlin 2.0.x.
Como não tive nenhuma falha durante incontáveis ​​sondagens durante essas semanas (tanto M48 quanto muitas impressões reais), devo considerar esta solução alternativa um claro sucesso no meu caso. É claro que atualizarei minhas descobertas caso os resultados mudem.
Também testei que funciona independentemente da velocidade da sonda XY (tentei 6-8-10000 mm / s), da velocidade da sonda Z e sem desativar aquecedores / escalonadores durante a sondagem. Basicamente, a configuração de sondagem em Marlin não parece mais um fator para evitar falhas (mas ainda pode afetar a precisão, pelo menos a velocidade Z é).
O único problema é que a luz de fundo do LCD (5 V) pisca temporariamente durante a sondagem se seus 5 V forem retirados do SKR, provavelmente indicando uma queda de tensão devido ao consumo de corrente da sonda (mas não queria isolar e sondar tudo com meu osciloscópio) . Assim, conectei 5 V ao Pi em vez (mas poderia muito bem ser qualquer fonte externa de 5 V) com dois fios GND ligados perto da sonda, um indo para o SKR e o outro indo para o Pi (para o solo estelar de um homem pobre) .

@mlehnhoff
Teste o branch bugfix-2.0.x para ver onde ele está.

Estarei testando isso em breve no meu BLTouch genuíno, acredito que tenho o mesmo problema.

Edit: Não é a mesma placa (STM32F103RC), mas questões idênticas! Tentando descobrir se é um problema de tempo ou outra coisa! Mas ao fazer uma malha 91 UBL, recebo talvez 1 ou 2 pontas de prova com falha, da mesma forma que descrito aqui.

Bem, eu descobri que minha placa parece estar usando o código servo 'compartilhado'. Eu adicionei o seguinte após algumas tentativas e erros e parece safe_delay de 6ms / us? está funcionando! O sensor parece disparar mais rápido, se isso faz algum sentido? E agora consegui obter minha primeira malha sem que nenhum sensor falhe? Vou ficar de olho e fazer mais testes, mas inicialmente parece promissor! Este é um BLTouch genuíno, encomendei um segundo achando que estava com defeito! Eu não acho que seu outro hardware, já que esta configuração estava funcionando bem na placa original, somente depois que a mudança para BTT V2.0 e Marlin ocorreu esse problema. Anteriormente, eu estava executando o Klipper sem problemas.

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

@ aslater3 Como posso saber se minha placa (SKR Mini E3 v1.2) tem código servo 'compartilhado'?

@boelle desculpe, eu estava muito ocupada com coisas diferentes. Acabei de testar o bugfix-2.0.x mais recente (que parece ser 2.0.5.4). O problema ainda está presente. Isso ocorre porque ele ainda não foi corrigido no pio-framework-arduino-lpc176x.
Mas agora tenho acesso a um osciloscópio e estou disposto a investigá-lo mais a fundo (e eventualmente consertá-lo) ...

2.0.5.4 ( 2.0.x ) e bugfix-2.0.x são dois ramos diferentes. Experimente o bugfix-2.0.x mais recente e informe-nos se ainda estiver tendo esse problema.

2.0.5.4 ( 2.0.x ) e bugfix-2.0.x são dois ramos diferentes. Experimente o bugfix-2.0.x mais recente e informe-nos se ainda estiver tendo esse problema.

Sim, eu sei e usei o bugfix-2.0.x mais recente! 2.0.5.4 é apenas o que o menu LCD me diz

Mas isso não importa de qualquer maneira, porque o bug não está dentro do Código MarlinFw, está dentro do pio-framework-arduino-lpc176x

É até conhecido qual parte do código está causando o problema: o travamento desabilitado do HW-PWM.

O problema é encontrar uma maneira de reativar o travamento sem ter outros problemas. É por isso que o travamento foi desativado.

Eu estava conversando com @ p3p sobre isso, pois estive investigando problemas semelhantes em outras plataformas. Não acho que haja chance de que esse comportamento tenha sido alterado e não vale a pena tentar novamente agora, a menos que seja parte da implementação de uma solução mais permanente.

2.0.5.4 é apenas o que o menu LCD me diz

Então você não está usando a correção de bug mais recente. Seu LCD mostrará bugfix-2.0.x .

Estou ciente da falha de 1 período ao definir um ciclo de trabalho mais curto depois de já passar o novo valor de correspondência. Atualmente, não tenho certeza de como atenuar o problema. O hardware não parece fazer o que deveria fazer quando os registradores de sombra pwm estão habilitados.

2.0.5.4 é apenas o que o menu LCD me diz

Então você não está usando a correção de bug mais recente. Seu LCD mostrará bugfix-2.0.x .

ok, meu mal, eu acidentalmente clonado o branch 2.0.x em vez de bugfix-2.0.x ... agora eu consertei isso -> nenhuma diferença (é claro)

Estou ciente da falha de 1 período ao definir um ciclo de trabalho mais curto depois de já passar o novo valor de correspondência. Atualmente, não tenho certeza de como atenuar o problema. O hardware não parece fazer o que deveria fazer quando os registradores de sombra pwm estão habilitados.

@ p3p Você pode me dizer quais problemas você enfrentou quando o travamento estava ativado?

Pelo que eu me lembro (já faz muito tempo que eu estava depurando isso), com os registradores de sombra habilitados, a largura de pulso esporadicamente não atualizava, como você pode imaginar, eu escolhi o glitch de 1 período em vez disso. Parecia possivelmente ser causado pela atualização da largura de pulso mais de uma vez no mesmo período, mas eu não tinha certeza.

Um ângulo do servo comandado deve permanecer pelo menos 20 ms para ser visível na saída como uma largura de pulso alterada.
Para tornar a nova largura de pulso reconhecível pelo dispositivo / servo, ela provavelmente precisa permanecer vários pulsos.
Portanto, alterar o ângulo em pelo menos 20 ms deve ser proibido.
Pelo que @sjasonsmith descobriu para o BL_Touch e apontou em https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment -657406598 melhor cerca de 60 ms.

Atualizar o registro de sombra com mais freqüência não faz sentido. O registro não deve ser escrito com mais freqüência do que as alterações do valor do ângulo. (Variável sombra para o registrador sombra?)
Provavelmente, ele precisa de um patch adicional em um nível superior da biblioteca servo para evitar alterações muito frequentes. Já temos algo semelhante com SERVO_DELAY , originalmente destinado a evitar o desligamento do sinal do servo antes que o servo (mecanicamente) chegue ao seu destino.

@AnHardt Eu sei que alterar os registros de sombra várias vezes por período é inútil, mas não vejo por que alterá-los várias vezes antes que os valores sejam enviados para os registros reais no final do período causaria um problema, não tenho certeza do que a solução para parar o aplicativo cliente de atualizar o hardware PWM com muita frequência seria (se esse for realmente o problema), sem um impacto significativo no desempenho de uma forma ou de outra.

@AnHardt Eu sei que alterar os registros de sombra várias vezes por período é inútil, mas não vejo por que alterá-los várias vezes antes que os valores sejam enviados para os registros reais no final do período causaria um problema,

Também não sei por que ou se há um problema. Mas se você nos disser que isso causa problemas, devemos tentar evitá-lo.
Uma construção como:

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

evitaria, pelo menos, gravar várias vezes no registrador sombra com o mesmo valor.

Se bem me lembro, a última vez que toquei no código SERVO_PROBE, antes do BL-Touch aparecer, evitei cuidadosamente mover o servo e os steppers ao mesmo tempo com sincronizações - mas sempre testei com DEACTIVATE_SERVOS_AFTER_MOVE , porque meus servos tremiam quando o stepper estava se movendo, produzindo uma pausa de SERVO_DELAY (algumas centenas de ms) após definir o servo_angle. Em comparação com isso, os atrasos muito mais curtos que sugiro agora são uma vitória no desempenho.

Se o código BL-Touch tenta mover servo e steppers ao mesmo tempo, isso não me parece a bola que tenho que jogar.

Porque os BL-Touches querem ter um sinal servo constantemente ligado DEACTIVATE_SERVOS_AFTER_MOVE não é possível. Para as bibliotecas servo acionadas por interrupções, uma interrupção atrasada se tornou catastrófica, bagunçando o sinal do servo. Um PWM acionado por hardware seria imune. Normalmente, temos apenas um servo.

No entanto, tenho certeza de que set_servo(0); set_servo(180); set_servo(0); sem pausas não causará absolutamente nenhuma reação - nem em um servo real, nem em um BL-Touch.

Desculpa. Provavelmente meus pensamentos estão muito focados em hardware PWM, no momento, onde o registro de comparação de temporizadores só precisa ser atualizado de vez em quando.

Desculpa. Provavelmente meus pensamentos estão muito focados em hardware PWM, no momento, onde o registro de comparação de temporizadores só precisa ser atualizado de vez em quando.

Esse problema é com o Hardware PWM, e eu concordo com tudo que você disse, eu estava pensando no problema no nível do framework, como em como fazer o hardware funcionar de forma confiável mesmo quando o aplicativo cliente está fazendo uma quantidade absurda de atualizações (Marlin ) no mesmo período. O cliente espera que a última atualização entre em vigor, em vez da primeira, e não tenho como saber que não haverá atualizações subsequentes antes do final do período.

Vou ter que olhar novamente para o problema para ver se uma nova solução vem à mente e se o diagnóstico está realmente correto e eu não estava apenas sendo estúpido.

Eu tentaria
quando as posições de curta duração podem ser omitidas:

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

correndo a cada 20 ms.
Isso deve manter o comprimento do pulso de saída constante por pelo menos 3 * 20 ms e então colocar apenas no ângulo comandado mais recente. No entanto, ele não saberá que ângulo virá a seguir ou se uma atualização ocorrerá - isso é impossível saber - alguns quando você terá que começar. Se você garante, os pulsos de envio podem ser lidos e o registro de sombra não é atualizado com muita frequência.

Para garantir que cada atualização é feita pelo menos durante esse tempo, a variável volátil deve ser substituída por uma fila.

No vôo RC, as posições intermediárias podem provavelmente ser omitidas. No caso do BL-Touch, retrair, desdobrar, reiniciar, mudar_modos, ... é tudo igualmente importante. Observando isso pode ser omitido, todo comando deve permanecer o tempo suficiente para ser reconhecido. Não existe uma solução universal certa para uma biblioteca servo universal.

Além disso, para o BL-Touch, todos os comandos devem estar sincronizados com os movimentos do stepper. Retrair a sonda enquanto desce para a sonda deve ser melhor omitido. :-)
Portanto, do meu ponto de vista, Marlin deve ser responsável por não atualizar o ângulo para frequentar.

Editar:
Provavelmente, a interrupção de comparação é a certa para atualizar o registro de comparação de sombra. A interrupção poderia então ser atrasada por interrupções de prioridade mais alta em cerca de 17 ms e ainda estaria a tempo de ter o registro de atualização pronto para a cópia para o registrador de comparação quando o estouro ocorrer.
Deve ser possível parar a interrupção se o contador estiver acima de 3. O pode ser reiniciado quando o inter_angle for atualizado.

Estou tendo o mesmo problema com o SKR mini 1.1.
Não importa a posição que eu coloque, o servo sempre vai para o mesmo ponto.

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

@Matheusschmitz, o SKR mini usa uma plataforma diferente e seria único nesta edição. Algumas mudanças ocorreram há pouco mais de uma semana para melhorar a confiabilidade do BLTouch para placas STM32F1 (como a sua). Tente usar o branch bugfix-2.0.x para ver se isso resolve o seu problema.

Se você ainda tiver problemas, vá discutir em um dos locais de apoio, como o Discord. Este problema específico deve permanecer focado nas placas LPC176x.

Eu também tive esse problema com meu clone SKR1.3 e BLTouch.
Consegui capturá-lo em vídeo, por volta da marca de 1:54:
https://www.youtube.com/watch?v=wF0Mia49ECI&t=114s
(o vídeo é 1080p, o YouTube precisa processá-lo)

Aqui está também uma imagem mostrando o que acontece quando acontece durante a UBL

Tentei, como outros, as várias configurações que poderiam ajudar, mas não ajudaram.
Estou no último branch bugfix-2.0.x

O mesmo problema do meu lado.
Vou testar a solução alternativa também

Este problema não teve atividade nos últimos 30 dias. Adicione uma resposta se quiser manter este problema ativo, caso contrário, ele será encerrado automaticamente em 7 dias.

Acho que vale a pena manter isso aberto até que uma solução permanente seja encontrada.

Eu concordo com esse sentimento

Este problema não teve atividade nos últimos 30 dias. Adicione uma resposta se quiser manter este problema ativo, caso contrário, ele será encerrado automaticamente em 7 dias.

Acho que esse problema deve ser mantido em aberto.