Marlin: [BUG] SKR v1.3 (또는 기타 LPC1768) : bltouch에 문제를 일으키는 서보 신호 문제

정품 BLTouch를 사용해 볼 수 있습니까?

정품 BLTouch를 사용해 볼 수 있습니까?

또한 Configuration_adv.h 에서 BLTouch 설정을 조정 해 보았습니까? : BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE , BLTOUCH_FORCE_MODE_SET 등과 같은 설정을 조정할 수 있습니다.

아, 죄송합니다. 언급하는 것을 잊었습니다. 물론 이전에 BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE 및 심지어 DELAY_BEFORE_PROBING 다른 조합을 시도했습니다. 성공하지 않고.
이제 문제가 무엇인지 알게 되었으니 더 긴 지연이 도움이되지 않는다는 것이 분명합니다. bltouch를이 오류 상태로 만드는 잘못된 20ms 펄스는 빌드 플레이트를 터치하기 몇 초 전에 이미 발생하기 때문입니다.
BLTOUCH_FORCE_MODE_SET 은이 이전 버전의 bltouch clone에서 지원되지 않습니다. "스마트 한"것이 아닙니다.

그리고 아니요, 정품 BLTouch에 액세스 할 수 없습니다. 나와 내 이전 클론에게는 위에서 언급 한 해킹이 잘 작동하므로 개인적으로이 문제에 대한 적절한 수정이 필요하지 않습니다. 그러나 나는 실제 서보조차도 짧은 흔들림이나 다른 이상한 행동 으로이 펄스에 반응 할 수 있다고 생각하기 때문에이 문제는 어쨌든 수정되어야한다고 생각합니다.

와, @mlehnhoff , 패치가 내 고통을 덜어줍니다. SKR v1.3 + (이전 버전에 대해 확실하지 않음) triaglelab 3d touch-동일한 문제. 내 자신의 8/10 작업 조건 : BLTOUCH_FORCE_SW_MODE + BLTOUCH_DELAY 1000.하지만 패치는 SW_MODE 및 DELAY없이 10/10 작동합니다. Tnx!

리암 (동일한 MCU)에서 서보 기반 터치 프로브를 테스트했는데 문제가 없었지만 이동 후 비활성화 기능을 사용했습니다.

나는 그것없이 시도하지 않았고, juse는 필요하지 않을 때 서보를 비활성화하는 논리를 이해했습니다.

나는 소수의 정품 BLTouches를 가지고 있으며 모두 LPC1768 인 SKR 1.3에서 잘 작동합니다.

그래서 여기에서 총을 뛰어 넘으면 하드웨어 문제 (와이어, 노이즈 연결) 또는 사용자 구성 문제 일 가능성이 가장 높습니까?

대부분의 추가 BLTouch 코드 / 구성 옵션에 대한 동일한 이유는 BLTouch 복제 문제입니다.

3DTouch! = BLTouch를 명심하십시오. 이 사본과 관련된 많은 닫힌 문제가 있습니다.

나는 그것을 하드웨어 문제라고 부를 것입니다.

네, 이제 3dtouch (및 기타)는 BLtouch가 아닙니다.

저에게 가장 큰 질문은 말린이 클론을 지원하는 것이 무엇이든 아니면 정품에만 관심이 있는지 여부입니다.

약간의 개인적인 생각을하면서 나는 청새치가 클론을 지원해야한다고 생각하지 않는다

하지만 내가 틀렸을 수도 있어요, 생각?

XXtouch의 이름이 무엇이든 내 2 센트. 이들 중 하나는 SERVOS 핀 (BLtouch 특수 핀이 아님)에 연결됩니다. SERVOS는 서보처럼 작동해야합니다.

그러나 나는 실제 서보조차도 짧은 흔들림이나 다른 이상한 행동 으로이 펄스에 반응 할 수 있다고 생각하기 때문에이 문제는 어쨌든 수정되어야한다고 생각합니다.
( @mlehnhoff 댓글에서)

이것은 프로브 하드웨어의 책임이 아닙니다. 보드에서 생성되는 신호가 올바르지 않으며 오실로스코프를 사용하여 확인되었습니다. 그것은 수정되어야합니다.

또한 SKR Mini E3 보드에서 유사한 문제를 일으키는 모든 타이머 충돌을 디버깅 할 때보고 된 동작이 정품 BLTouch 하드웨어와 매우 유사하다는 것을 확인할 수 있습니다. 잘못된 펄스 길이로 인해 BLTouch는 단순히 자신이하고있는 일을 잊어 버리고 오류를 일으켰습니다.

@mlehnhoff , 문제를 보여주는 오실로스코프에서이 문제에 첨부 할 수있는 이미지를 캡처 했습니까?

현재 해결 방법이 완전한 솔루션으로 마음에 들지 않는다고 생각하지만 mlehnhoff가 제공 한 문제를 설명하는 세부 수준과 펄스가 문제의 근본 원인임을 입증하는 해결 방법에 대해 정말 감사드립니다.

죄송합니다. 스코프 스크린 샷을 즉시 제공하지 않았습니다. 내가 몇 가지를 만들었지 만 뭔가 잘못되었습니다. 그러나 나는 스코프를 돌려 줄 때까지 깨닫지 못했습니다 (내 것이 아닙니다).
그러나 이제 나는 새로운 것을 만들었습니다.

그림에서 1472µs에서 544µ 로의 전환을 볼 수 있지만

펄스는 20544µs입니다.

또한 실제 서보를 사용해 보았고 여기 에이 문제가 3dtouch 또는 다른 복제품에만 국한되지 않는다는 증거가 있습니다.

IMG_4677.zip

서보는 90 ° (가운데 레버)에서 0 ° (레버 아래로)로 회전해야하지만, 잘못된 펄스가 발생하면 실제로는 처음에 턴 다운되기 전에 턴 다운됩니다.

그건 그렇고, 정품 bltouch (클래식 v1.0, v1.2, v1.3, 스마트 v1.0, v2.0, v2.2, v3.0, v3.1)에는 최소 8 가지 버전이 있으며 모두가 올바르게 작동하는지 알고 있습니다 ;-)

다음은 또 다른 힌트입니다. M280 명령을 수동으로 보낼 때 문제가 발생할 가능성은 거의 없습니다. 나는 (비디오에 사용 된) 서보를 토글하는 스크립트를 작성하여 가능성을 크게 높였습니다.
servo_toggle.gcode.txt

이것이 내 BLTouch에서보고있는 문제와 관련이 있는지 궁금합니다.
USB를 통해 Re-ARM에 전원을 공급하고 M80 를 사용하여 12V 전원 공급 장치를 켭니다. BLTouch에 전원을 공급하는 12V 전원 공급 장치에 5V 벅 컨버터가 연결되어 있으므로 12V 전원 공급이 시작될 때까지 BLTouch에 전원이 공급되지 않습니다.
보드의 전원이 켜지면 BLTouch가 빨간색으로 깜박입니다. BLTouch가 전원이 켜지 기 전에 신호를 받으면 이는 분명히 다소 정상이므로 걱정하지 않습니다.
그러나 M280 P0 S160 로 재설정하려는 시도는 전혀 효과가 없습니다. 핀이 배치 된 경우에도 핀을 후퇴시키지 않습니다.
그러나 M280 P0 S60 성공적으로 SW 모드로 전환되고 깜박임을 중지합니다.
깜박이는 것과 S160 가 무시되는 것 외에는 BLTouch가 완벽하게 작동하는 것 같습니다. 깜박이는 경우에도 제대로 배포, 보관 및 프로브-풀 베드 프로브를 수행 한 적이 있으며 프로브 오류를 본 적이 없으며 반복성이 뛰어납니다.
이것은 클론이 아닌 정품 V3.1 BLTouch입니다.

저렴한 미니 DSO와 큰 CRT 오실로스코프로 펄스를 확인했는데 펄스 길이가 괜찮아 보인다는 것을 잊었습니다. 또한 재설정을 트리거하는 값을 찾지 않고 다른 S 값 (155에서 165까지)을 시도했습니다.

LPC 용 서보 라이브러리가 작동하는 방식을 찾지는 않았지만 :
서보 신호는 PWM입니다. 이것이 STM32 하드웨어 타이머로 실현 될 경우이 오류는 비교 레지스터의 사전로드 레지스터에 새 값을 업데이트하는 대신 카운터 비교 레지스터를 직접 업데이트함으로써 발생할 수 있습니다. 카운터가 낮은 값과 높은 값 사이에있는 동안 비교 레지스터를 높은 값에서 낮은 값으로 변경하면 (동일) 비교를 건너 뛰고 카운터 오버런이 발생하여 새 값에 도달 할 때까지 핀이 변경되지 않습니다. . 사전로드 레지스터를 사용하는 경우 카운터가 오버런되거나 (이전) 비교 값이 일치 할 때 비교 레지스터가 업데이트됩니다. 이것은 큰 펄스의 위험이 없으며 최대 약 1 PWM주기 (20ms)의 지연 만 가능합니다.
편집 : 오류 가능성은 1ms 뒤로 건너 뛰는 당 5 %입니다.
여기에 비슷한 것이 있다고 생각합니다.

이는 lpc 프레임 워크가 하드웨어 pwm을 래칭 모드 (펄스 폭 레지스터가 각 기간에 섀도 잉되고 래칭되는 경우)에서 실행하지 않기 때문입니다. 단순 모드 비트로이를 수행 할 수 있어야합니다. 안정적으로 작동하도록하려면 가능한 1주기 글리치 또는 전혀 변경되지 않는 임의의 펄스 폭 (그러나 업데이트 빈도에 따라 매우 자주) 중에서 선택합니다.

이 문제에 대한 더 많은 연구를 할 수는 있지만, 정말 복잡한 주변 장치는 아닙니다. 저는 그 결함에 오랜 시간을 낭비했고 결국 다른 것들은주의가 필요했습니다.

@mlehnhoff @kockockockoc 패치를 어떻게 적용 하시겠습니까?

@mlehnhoff @kockockockoc 패치를 어떻게 적용 하시겠습니까?

솔직히 말해서, 저는 git을 처음 접했고 "git diff"를 통해이 패치를 만들 수있어서 기쁩니다. 이 패치를 다시 적용하려면 다른 git 명령이 있어야합니다. @kockockockoc 이 도움이 될 수 있습니다 ...
그러나이 아주 작은 코드 조각의 경우 손으로도 할 수 있습니다. 표시된 위치의 "Marlin / src / HAL / HAL_LPC1768 / Servo.h"파일 (물론 "+"제외)에 "+"로 시작하는 네 줄을 추가하는 것만 큼 쉽습니다.

안녕하세요, 저는 Bigtreetech SKR v1.3과 3D Touch와 같은 보드를 가지고 있지만 3D Touch가 작동하지 않습니다. Arduino Mega에서 일부 코드를 사용하여 3dTouch를 테스트했으며 완벽하게 작동합니다. 그래서 내가 찾은 제안과 @mlehnhoff 패치를 시도했지만 여전히 같은 문제가 있습니다 = 3D 터치가 멈
이 문제를 해결하기 위해 무엇을해야하는지 모르기 때문에 정말 걱정됩니다. 어떤 제안이라도 좋습니다.

이 버그가 내가 여기에보고 한 것과 동일한 것으로 의심됩니다 : https://github.com/MarlinFirmware/Marlin/issues/15370

나는 여전히 문제없이 6/22/19부터 bugfix 커밋을 실행하고 있습니다. 오늘 최신 버그 수정 커밋을 시도했지만 서보 문제가 여전히 존재합니다.

@ Reywas62 및 모든 문제를 해결할 수있는 http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html 기사를 찾았습니다. 분명히 일부 SKR 보드는 제대로 작동하는 데 상당한 양의 전류가 필요한 낮은 임피던스 (약 200 옴)의 출력 신호를 가질 수 있습니다 (아두 이노 보드에서는 발생하지 않으므로 3D 터치 프로브가 제대로 작동하는 이유입니다.) Arduino에서) 따라서 분명히 펌웨어와 관련이 없습니다.

내 보드가 Marlin bugfix 2.0.x (6/22/19)의 이전 커밋으로 잘 작동한다는 점을 제외하고는 그 설명을 사겠습니다.

mlehnhoff 의 "quick an dirty"솔루션이 작동하고 있음을 확인할 수 있습니다. BLTouch 클론으로 9x9 UBL-Mesh를 프로빙합니다. 메쉬 생성을 실행할 때 일반적으로 81 포인트 메쉬의 1 또는 2 포인트가 실패합니다. 그러나 "수정"으로 모든 것이 잘 작동합니다. 그래서이 솔루션을 계속 사용할 것입니다. 그리고 내 경우에는 푸시 핀이 배치되어 센서가 트리거되지 않기 때문에 긴 서보 펄스에 문제가 있다고 생각합니다.

3D Touch 관련 문제가 해결되었는지 확인하고 싶습니다. 문제는 SKR 1.3 서보 핀의 낮은 전류입니다. 나는 회로를 만들고 성공적으로 테스트했습니다. 이제 M43을 실행 한 후이 정보를 받았습니다.
보내기 : M43 S
서보 프로브 테스트
. 인덱스 사용 : 0, 전개 각도 : 10, 적재 각도 : 90
. 프로브 Z_MIN_PIN : 57
. Z_MIN_ENDSTOP_INVERTING : false
. BLTOUCH 확인
= BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1 감지 됨.
* 30 초 이내에 프로브를 트리거하십시오 *
. 펄스 폭 (+/- 4ms) : 10
= BLTouch pre V3.1 (또는 호환 가능) 감지 됨

여기에서 설정을 실험 해 보겠습니다.하지만 SG90과 MG90 서보 모터가 모두 비활성화 상태에서 간헐적으로 다시 이동합니다. Z-Probe 스위치를 잡고 있기 때문에 침대에 충돌 할 때 기계가 죽습니다. 마지막 충돌은 Creality CR10 S5의 휠 마운트를 합친 것입니다. > _

기회가 생기면 회로를 시도해보고 분류되는지 확인합니다. 또한 펌웨어 해킹을 시도합니다. :)

펌웨어 해킹을 시도한 후, 나에게는 아무런 변화가 없었습니다 (핵이 반드시 서보 이동이 아니라 bl-touch 클론을 수정했기 때문에 내가 생각했듯이). 서보는 이동을 완료 한 후에도 때때로 더 뒤로 이동합니다.

그것을 고려하여 나는 해킹을 풀고 말린에게 서보를 비활성화하지 말라고 말했고 뒤로 이동 문제가 사라진 것 같습니다. 서보를 비활성화하면 내 문제가 발생하는 것 같습니다. 다행히 내가 사용하는 MG90은 내가 선택한 각도에서 진동 / 흔들림을 표시하지 않습니다. :)

테스트 할 gcode에 대해 mlehnhoff에게 감사드립니다. 매번 실행할 때마다 서보가 3 ~ 4 번 재생되고, Marlin에게 서보를 계속 활성화하라고 말했을 때 스크립트가 3 번 연속으로 잘 실행되었습니다. 저 전류보고를 고려하여 히터를 켜고 PSU를 부하 상태로 만드는 테스트도 실행했습니다. :)

중요한지 모르겠지만 내 Servo 각도는 172 (배치), 35 (Stowed)이고 서보를 매번 같은 양만큼 뒤로 이동시키는 것처럼 보였습니다. 서보가 앞으로 움직이지 않았습니다.

펌웨어 해킹은 내 문제를 해결하지 못했지만 서보를 활성화 상태로두면 DarkAlaranth와 마찬가지로 서보가 오작동하지 않습니다. 실제로 수정은 아니지만 수용 가능한 해결 방법입니다.

약간의 추가 배경 지식은 지난 며칠 동안 여러 플랫폼에서 시도해 보았고 AntLab BLtouch를 모두 망칠 수 있다고 생각했기 때문에 1/3을 주문했습니다.

다음 플랫폼에서 관찰 한 내용은 다음과 같습니다.
SKR Pro V1.1이 작동하지 않습니다.
SKR v1.3이 작동하지 않습니다.
RAMPS 1.4 작동하지 않음
SKR v1.4가 작동하지 않습니다.
RAMPS 1.6 작동하지 않음

M119에서 읽기 전의 증상
endstop 상태보고
x_min : 트리거 됨
y_min : 트리거 됨
z_min : 트리거 됨

동일한 결과로 핀 파일도 조정했습니다.

다양한 청새치 빈티지의 여러 비디오에서 사용한 프로세스는 다음과 같습니다.
https://www.youtube.com/watch?v=5cSzFCv7K4Q&t=14s
https://www.youtube.com/watch?v=R0HeFV9nKCM
https://www.youtube.com/watch?v=HR-zn4dv1fY&t=2s
https://www.youtube.com/watch?v=-4o6-8TgpNM

더 많은 동영상을 게시 할 수 있지만 내 요점은 3 개의 정품 BL 터치로 어떤 동영상에서도 작동하지 않는다는 것입니다.

구성이 변경 되었습니까? configuration_adv.h에는 이제 BL 터치 전원 설정이 많이 있습니다.

Z 축 원점 복귀시보고 온도가 있어야합니까?
다음은 디버그입니다.
전송 : G28 Z0
전송 : M114
전송 : M105
RECV : 오류 : !! BLTouch 오류로 인해 STOP이 호출 됨-M999로 다시 시작
[오류] 오류 : !! BLTouch 오류로 인해 STOP이 호출 됨-M999로 다시 시작

RAMPS 1.6 / MEGA2560의 M119
z-min에 대해 올바른 읽기
프로빙이 작동하지 않는 것 같습니다.

이 문제가 있습니다.
Ender 3, SKR Mini E3 v1.2, 정품 BLTouch v3.1

V2에서 잘 작동합니다.
skr1.3의 배선은 스톡 방향과 다릅니다. Marlin 2.0.1의 릴리스 버전을 사용하고 있습니다.

다른 BLTouch를 사용해 볼 수 있습니까? 손상된 프로브가 아닌지 확인하려면?

아뇨, 죄송합니다. 나는 정상적인 BLTouch 만 가지고 있습니다. 실패는 약 200 개 중 하나만 발생합니다.

@mlehnhoff 시간이되면 다시 테스트하십시오

버그 수정 2.0.x가 매일 업데이트되므로 14 일 정도마다 다시 테스트 해주세요.

최신 버그 수정 빌드 재 컴파일 [2020.01.24.]
각각 150 개의 프로브 반복성 테스트를 두 번 수행했습니다.

1. 베드 가열 OFF, 성공적으로 완료 됨, 표준 편차 : 0.003928.
2. 베드 히팅 ON, 프로빙 실패, 137에서 실패.

클론 BLTouch (3DTouch)와 함께 SKR1.1 보드 (LPC1768)에서 bugfix 2.0.x를 사용할 때 유사한 동작을 관찰했습니다.
다른 해결 방법을 시도했지만 25 개의 프로브 포인트 중 적어도 하나의 프로빙 포인트에 대해 핀이 너무 일찍 해제됩니다 (예 : 즉시 배치 후 보관).

@mlehnhoff 시간이되면 다시 테스트하십시오

@boelle : 앞서 언급했듯이 @ p3p 문제는 실제로 Marlin 자체가 아니라 LPC 프레임 워크에 있기 때문에 다시 테스트 할 필요가 없습니다. 그는 PWM 래칭 모드가 제대로 작동하지 않았기 때문에 주석을 제거해야한다고 말했습니다. 따라서 이것이 수정되지 않는 한 안정적으로 작동하는 bltouch를 원하는 모든 사람은 추악하지만 작동하는 해결 방법을 사용해야합니다.
현재로서는 안타깝게도 오실로스코프에 액세스 할 수 없습니다. 그렇지 않으면이 문제를 디버깅 할 때 P3P를 지원하고 싶습니다. 다른 사람이 이에 대해 더 자세히 알고 싶다면 https://github.com/p3p/pio-framework-arduino-lpc176x/blob/master/system/lpc176x/HardwarePWM.h

이 문제가 있습니다.
Ender 3, SKR Mini E3 v1.2, 정품 BLTouch v3.1

SKR Mini E3 v1.2는 LPC1768이 아닌 STM32 마이크로 컨트롤러를 사용합니다.

PWM 래칭 문제가 다음 LPC176x 정오표와 관련이 있는지 궁금합니다.

3.13 PWM.1 : PWM1.1의 듀티 사이클을 100 %에서 업데이트 할 때
어떤 경우에는 출력이 전체 PWM 기간 동안 낮게 유지 될 수 있습니다.
업데이트가 적용됩니다
소개:
LPC176x PWM 주변 장치에서 두 개의 일치 레지스터를 사용하여 단일
에지 제어 PWM 출력. 하나의 일치 레지스터 (PWM1MR0)가 PWM주기를 제어합니다.
속도, 일치시 카운트를 재설정합니다. 다른 일치 레지스터는 PWM 에지를 제어합니다.
위치. 예를 들어, 일치 레지스터 PWM1MR1은 PWM1의 에지 위치를 제어합니다.
다중 단일 에지 제어 PWM 출력은 모두 시작시 상승 에지를 갖습니다.
PWM1MR0 일치가 발생할 때 각 PWM 사이클.
문제:
단일 에지 모드에서만 PWM1.1 (Pulse Width Modulator 1, 채널
1 출력)이 100 % (PWM1MR1 = PWM1MR0)에서 업데이트 된 다음 PWM1.1에 대한 출력
원하는 새로운 듀티 사이클 이전에 전체 PWM 기간 동안 예기치 않게 낮게 유지 될 수 있음
적용됩니다. 이 문제는 PWM1.1의 출력에만 영향을줍니다. 기타 PWM 채널
(PWM1.2 ~ PWM1.6)은이 문제의 영향을받지 않습니다.
해결 방법 :
사용자가 PWM1MR1을 다음과 같이로드 할 수있는 소프트웨어 수정을 구현할 수 있습니다.
PWM1MR0 + 1 (최소 1)은 PWM1.1의 출력 업데이트에서 지연을 방지합니다.

100 % PWM 모드에 서보 핀을 넣지 않았다고 생각하기 때문에 그렇지 않을 것으로 예상합니다.

그런 다음 다시 PWM 1.1에서 SKR 1.3의 서보 핀인 P2_0에 사용됩니다.

유사한 문제 (정품 BL Touch 3.1 및 SKR PRO 1.1 사용)를 조사했습니다.
나는 # 16986에서 찾은 것을 문서화했지만 기본적으로 XY_PROBE_SPEED와 관련이 있음을 발견했습니다. 10000의 수치는 BL Touch 신호가 15 개의 프로빙 포인트 (첫 번째 Y 이동 후 첫 번째이기도 함)에서 펄스에서 DC 레벨로 변경되도록합니다. 6000이라는 수치는 문제를 보여주지 않았습니다.

SKR v1.3 및 3D Touch v2 (및 Pi 3B)를 사용하는 두 대의 Ender 3에서이 해결 방법을 한 달 이상 테스트했습니다. 이전에는 프로브가 트리거되지 않고 (그러나 즉시 빨간색으로 깜박임) ABL을 수행 할 때 (최소한 3 ~ 5 장의 인쇄 중 1 회) 노즐이 기계식 Z 끝이 아니라면 침대에 충돌하는 경우 항상 정기적 인 오류가 발생했습니다. -고의로 떠났어. 그리고 나는 Marlin 2.0.x에서 프로빙 / BL Touch 구성의 순열을 전부는 아니지만 대부분 시도했습니다.
이 주 동안 (M48 및 많은 실제 인쇄물 모두) 수많은 프로빙 중에 실패가 없었으므로이 해결 방법은 제 경우에 분명한 성공이라고 간주해야합니다. 물론 결과가 변경되면 내 결과를 업데이트 할 것입니다.
또한 XY 프로브 속도 (6-8-10000 mm / s 시도), Z 프로브 속도와 독립적으로 작동하며 프로빙 중에 히터 / 스테퍼를 비활성화하지 않는지 테스트했습니다. 기본적으로 Marlin의 프로빙 설정은 더 이상 실패를 피하는 요소가 아닌 것 같습니다 (하지만 여전히 정밀도에 영향을 미칠 수 있지만 적어도 Z 속도는 그렇습니다).
유일한 문제는 LCD의 백라이트 (5V)가 SKR에서 5V를 끌어온 경우 프로빙 중에 일시적으로 깜박이며 프로브의 전류 소비로 인한 전압 강하를 나타낼 수 있다는 것입니다 (하지만 내 스코프로 모든 것을 격리하고 프로빙하고 싶지 않음). . 따라서 프로브 근처에 두 개의 GND 와이어를 연결하여 5V를 Pi에 연결했습니다 (외부 5V 소스 일 수도 있음). 하나는 SKR에 연결하고 다른 하나는 Pi에 연결했습니다 (가난한 사람의 별 접지 용). .

뿡뿡
bugfix-2.0.x 브랜치 를 테스트하여 그것이 어디에 있는지 확인하십시오.

내 정품 BLTouch에서 곧 이것을 테스트 할 것이며 동일한 문제가 있다고 생각합니다.

편집 : 동일한 보드 (STM32F103RC)가 아니지만 동일한 문제! 타이밍 문제인지 다른 것인지 알아 내려고합니다! 그러나 91 UBL 메시를 수행 할 때 여기에 설명 된 것과 같은 방식으로 1 개 또는 2 개의 실패한 프로브가 표시됩니까?

글쎄, 내 보드가 '공유'서보 코드를 사용하는 것 같다는 것을 알았습니다. 시행 착오 끝에 아래를 추가했는데 safe_delay 6ms / us? 작동 중입니다! 그것이 의미가 있다면 센서가 더 빨리 트리거되는 것 같습니까? 그리고 이제 센서 고장없이 첫 번째 메시를 얻을 수 있었습니까? 주시하고 더 많은 테스트를 실행하지만 처음에는 유망 해 보입니다! 이것은 정품 BLTouch로, 결함이 있다고 생각하여 두 번째를 주문했습니다! BTT V2.0으로 이동하고 Marlin이이 문제가 발생했기 때문에이 설정이 원래 스톡 보드에서 잘 작동했기 때문에 다른 하드웨어는 생각하지 않습니다. 이전에는 문제없이 Klipper를 실행했습니다.

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

@ aslater3 내 보드 (SKR Mini E3 v1.2)에 '공유'서보 코드가 있는지 어떻게 알 수 있습니까?

@boelle 죄송합니다 다른 일로 꽤 바빴습니다. 방금 최신 bugfix-2.0.x (2.0.5.4 인 것 같음)를 테스트했습니다. 문제는 여전히 존재합니다. 그것은 여전히 ​​pio-framework-arduino-lpc176x에서 수정되지 않았기 때문입니다.
하지만 이제 오실로스코프에 액세스 할 수 있으며 더 자세히 조사하고 결국 고칠 의향이 있습니다 ...

2.0.5.4 ( 2.0.x ) 및 bugfix-2.0.x 는 서로 다른 두 가지 지점입니다. 최신 bugfix-2.0.x 시도하고이 문제가 계속 발생하면 알려주십시오.

2.0.5.4 ( 2.0.x ) 및 bugfix-2.0.x 는 서로 다른 두 가지 지점입니다. 최신 bugfix-2.0.x 시도하고이 문제가 계속 발생하면 알려주십시오.

예, 알고 있으며 최신 bugfix-2.0.x를 사용했습니다! 2.0.5.4는 LCD 메뉴가 알려주는 것뿐입니다.

그러나 이것은 어쨌든 중요하지 않습니다. 왜냐하면 버그는 MarlinFw 코드 내부가 아니기 때문에 pio-framework-arduino-lpc176x 내부에 있습니다.

코드의 어떤 부분이 문제를 일으키는지는 잘 알려져 있습니다 : HW-PWM의 비활성화 된 래칭.

문제는 다른 문제없이 래칭을 다시 활성화하는 방법을 찾는 것입니다. 이것이 래칭이 비활성화 된 이유입니다.

나는 다른 플랫폼에서 비슷한 문제를 조사하고 있었기 때문에 @ p3p 와 이야기를

2.0.5.4는 LCD 메뉴가 알려주는 것뿐입니다.

그렇다면 최신 버그 수정을 사용하고 있지 않습니다. LCD에 bugfix-2.0.x 됩니다.

새 일치 값을 이미 전달한 후 더 짧은 듀티 사이클을 설정할 때 1주기 결함을 알고 있지만 현재 문제를 완화하는 방법을 잘 모르겠습니다. 하드웨어는 pwm 섀도우 레지스터가 활성화 된 경우 수행해야하는 작업을 수행하지 않는 것으로 보입니다.

2.0.5.4는 LCD 메뉴가 알려주는 것뿐입니다.

그렇다면 최신 버그 수정을 사용하고 있지 않습니다. LCD에 bugfix-2.0.x 됩니다.

좋아, 내 잘못이야, 실수로 bugfix-2.0.x 대신 2.0.x 지점을 복제했습니다 ... 이제 수정했습니다-> 차이 없음 (물론)

새 일치 값을 이미 전달한 후 더 짧은 듀티 사이클을 설정할 때 1주기 결함을 알고 있지만 현재 문제를 완화하는 방법을 잘 모르겠습니다. 하드웨어는 pwm 섀도우 레지스터가 활성화 된 경우 수행해야하는 작업을 수행하지 않는 것으로 보입니다.

@ p3p 래칭을 활성화했을 때 어떤 문제가 발생했는지 말씀해 주시겠습니까?

내가 기억하는 것 (이것을 디버깅 한 지 오래되었습니다), 섀도우 레지스터를 활성화하면 펄스 폭이 산발적으로 전혀 업데이트되지 않을 것입니다. 같은 기간에 펄스 폭을 두 번 이상 업데이트하여 발생한 것 같았지만 확실하지 않았습니다.

명령 된 서보 각도가 변경된 펄스 폭으로 출력에 표시 되려면 최소 20ms를 유지해야합니다.
장치 / 서보에서 새 펄스 폭을 인식 할 수 있도록하려면 여러 펄스를 유지해야합니다.
따라서 최소 20ms 이내의 각도 변경은 금지되어야합니다.
@sjasonsmith가 BL_Touch에 대해 발견하고 https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment -657406598에서 지적한 것에서 약 60ms가 더 좋습니다.

섀도우 레지스터를 더 자주 업데이트하는 것은 의미가 없습니다. 레지스터는 각도 값이 변경되는 것보다 더 자주 기록되지 않아야합니다. (섀도우 레지스터의 그림자 변수?)
너무 빈번한 변경을 방지하기 위해 더 높은 수준의 서보 라이브러리에 추가 패치가 필요할 수 있습니다. 우리는 이미 SERVO_DELAY 와 비슷한 것을 가지고 있는데, 원래는 서보가 (기계적으로) 목표에 도달하기 전에 서보 신호 종료를 방지해야했습니다.

@AnHardt 기간마다 섀도우 레지스터를 여러 번 변경하는 것은 무의미

@AnHardt 기간마다 섀도우 레지스터를 여러 번 변경하는 것은 무의미

나는 또한 이유나 문제가 있는지도 모릅니다. 당신이 우리를 말한다면 그러나 우리가 그것을 피하기 위해 시도해야 문제가 발생합니다.
다음과 같은 구조 :

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

최소한 동일한 값으로 섀도우 레지스터에 여러 번 쓰는 것을 방지합니다.

정확히 기억한다면 BL-Touch가 나타나기 전에 SERVO_PROBE 코드를 마지막으로 터치했을 때 동기화를 사용하여 서보와 스테퍼를 동시에 움직이는 것을 조심스럽게 피했습니다.하지만 저는 항상 DEACTIVATE_SERVOS_AFTER_MOVE 테스트했습니다. 스테퍼가 움직일 때 내 서보가 흔들려서 servo_angle을 설정 한 후 SERVO_DELAY (수백 ms) 일시 중지를 생성했습니다. 이에 비해 지금 제가 제안하는 훨씬 짧은 지연은 성능면에서 승리입니다.

BL-Touch 코드가 서보와 스테퍼를 동시에 움직이려고하면 공처럼 느껴지지 않습니다.

BL-Touches가 지속적으로 서보 신호를 유지하기를 원하기 때문에 DEACTIVATE_SERVOS_AFTER_MOVE 는 불가능합니다. 인터럽트 구동 서보 라이브러리의 경우 지연된 인터럽트가 치명적이되어 서보 신호를 망칠 수 있습니다. 하드웨어 구동 PWM은 내성이 있습니다. 보통 우리는 하나의 서보 만 가지고 있습니다.

그러나 일시 정지가없는 set_servo(0); set_servo(180); set_servo(0); 는 실제 서 보나 BL- 터치에서 전혀 반응을 일으키지 않을 것이라고 확신합니다.

죄송합니다. 내 생각은 하드웨어 PWM에 초점을 맞추는 것 같습니다. 현재로서는 타이머 비교 레지스터가 가끔씩 업데이트되어야합니다.

죄송합니다. 내 생각은 하드웨어 PWM에 초점을 맞추는 것 같습니다. 현재로서는 타이머 비교 레지스터가 가끔씩 업데이트되어야합니다.

이 문제는 하드웨어 PWM과 관련이 있습니다. 귀하가 말한 모든 것에 동의합니다. 클라이언트 응용 프로그램이 엄청난 양의 업데이트를 수행 할 때도 하드웨어가 안정적으로 작동하도록 만드는 방법과 같이 프레임 워크 수준에서 문제를 생각하고있었습니다 (Marlin ) 같은 기간에. 클라이언트는 첫 번째 업데이트가 아닌 마지막 업데이트가 적용될 것으로 예상하며 기간이 끝나기 전에 후속 업데이트가 없을 것임을 알 방법이 없습니다.

나는 새로운 해결책이 떠오르는 지 확인하기 위해 문제를 다시 살펴 봐야하고, 그 진단이 실제로 옳고 나는 단지 어리석은 것이 아니었다.

나는 시도 할 것이다
짧은 지속 위치를 생략 할 수있는 경우 :

servo_update(angle) only updates a volatile variable lets say inter_angle.

an interrupt, either overflow or compare could be:
{  
  static uint32_t counter = 0;
  static uint16_t last_inter_angle = 0;
  if (counter++ > 3) { // if counter should overflow there is a small risk of delaying another 3*20 ms. Every ~55min if 16 bit.
    if (inter_angle != last_inter_angle) { // if counter above 3 the update will be immediate when inter_angle changed.
      update_shadow_compare_register(inter_angle);
      counter = 0;
      last_inter_angle = inter_angle;
    }
  }
}

약 20ms마다 실행됩니다.
최소 3 * 20ms 동안 출력 펄스 길이를 일정하게 유지 한 다음 최신 명령 된 각도 만 입력해야합니다. 그러나 다음에 어떤 각도가 올지 또는 업데이트가 전혀 뒤따를 지 알 수 없습니다. 그것은 알 수 없습니다. 어떤 것은 시작해야 할 때도 있습니다. 송신 펄스를 읽을 수 있고 섀도우 레지스터가 자주 업데이트되지 않음을 보증합니다.

적어도 그 시간 동안 모든 업데이트가 수행되도록 보장하려면 휘발성 변수를 대기열로 교체해야합니다.

RC 비행에서는 중간 위치가 생략 될 수 있습니다. BL-Touch의 경우 보관, 배치, 재설정, 변경 _ 모드 등이 모두 똑같이 중요합니다. 생략 할 수 있으며 모든 명령은 인식 할 수있을만큼 오래 유지되어야합니다. 범용 서보 라이브러리에 대한 범용 솔루션은 없습니다.

또한 BL-Touch의 경우 모든 명령이 스테퍼 이동과 동기화되어야합니다. 프로브를 위해 내려가는 동안 프로브를 후퇴하는 것은 생략하는 것이 좋습니다. :-)
그래서 내 관점에서 Marlin은 각도를 자주 업데이트하지 않을 책임이 있습니다.

편집하다:
비교 인터럽트가 섀도우 비교 레지스터를 업데이트하는 데 적합한 것일 수 있습니다. 그런 다음 인터럽트는 더 높은 우선 순위의 인터럽트에 의해 약 17ms 지연 될 수 있으며 오버플로가 발생할 때 비교 레지스터에 대한 복사를 위해 업데이트 레지스터를 준비 할 수 있습니다.
카운터가 3 이상이면 인터럽트를 중지 할 수 있어야합니다. inter_angle이 업데이트되면 다시 시작할 수 있습니다.

SKR mini 1.1에서 같은 문제가 있습니다.
내가 어떤 위치에 두든 서보는 항상 같은 지점으로 이동합니다.

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

@Matheusschmitz the SKR mini는 다른 플랫폼을 사용

그래도 문제가 있으면 Discord와 같은 지원 장소 중 한곳에서상의하십시오. 이 특정 문제는 LPC176x 보드에 계속 초점을 맞춰야합니다.

SKR1.3 및 BLTouch 클론에서도이 문제가 발생합니다.
저는 1:54 마크 부근에 비디오로 캡처했습니다.
https://www.youtube.com/watch?v=wF0Mia49ECI&t=114s
(동영상은 1080p YouTube에서 처리해야합니다)

다음은 UBL 중에 발생하는 일을 보여주는 이미지입니다.

다른 사람들과 마찬가지로 도움이 될 수있는 다양한 설정을 시도했지만 도움이되지 않았습니다.
나는 최신 bugfix-2.0.x 브랜치에 있습니다.

내 쪽에서도 같은 문제입니다.
해결 방법도 테스트하겠습니다.

이 문제는 지난 30 일 동안 활동이 없었습니다. 이 문제를 활성 상태로 유지하려면 답장을 추가하세요. 그렇지 않으면 7 일 이내에 자동으로 종료됩니다.

나는 이것이 영구적 인 해결책을 찾을 수있을 때까지 열려있는 가치가 있다고 생각합니다.

그 감정에 동의합니다

이 문제는 지난 30 일 동안 활동이 없었습니다. 이 문제를 활성 상태로 유지하려면 답장을 추가하세요. 그렇지 않으면 7 일 이내에 자동으로 종료됩니다.

이 문제는 계속 열려 있어야한다고 생각합니다.