Marlin: [BUG] SKR v1.3 (atau LPC1768 lainnya): masalah dengan sinyal servo yang menyebabkan masalah dengan bltouch

Apakah Anda dapat mencoba BLTouch asli?

Apakah Anda dapat mencoba BLTouch asli?

Selain itu, sudahkah Anda mencoba menyesuaikan pengaturan BLTouch di Configuration_adv.h ?: Anda dapat menyesuaikan pengaturan seperti BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE , BLTOUCH_FORCE_MODE_SET , dll.

Oh, maaf, saya lupa menyebutkannya. Tentu saja saya pernah mencoba kombinasi yang berbeda dari BLTOUCH_DELAY , BLTOUCH_FORCE_SW_MODE dan bahkan DELAY_BEFORE_PROBING sebelumnya. Tidak berhasil.
Sekarang, setelah saya menemukan, apa masalahnya, jelas, bahwa penundaan yang lebih lama tidak membantu. Karena pulsa 20ms salah yang membawa bltouch ke status kesalahan ini terjadi beberapa detik sebelum pelat pembuat disentuh.
BLTOUCH_FORCE_MODE_SET tidak didukung oleh versi lama bltouch clone. Ini bukan orang yang "pintar".

Dan tidak, saya tidak memiliki akses ke BLTouch asli. Bagi saya dan klon lama saya, peretasan yang disebutkan di atas berfungsi dengan baik, jadi secara pribadi saya tidak memerlukan perbaikan yang tepat untuk masalah ini. Tetapi saya pikir, bahwa masalah ini harus diperbaiki bagaimanapun juga, karena saya pikir bahkan servo yang sebenarnya mungkin dapat bereaksi pada denyut nadi ini dengan goyangan singkat atau perilaku aneh lainnya.

Wow, @mlehnhoff , tambalanmu meringankan rasa sakitku. SKR v1.3 + (tidak yakin tentang versi yang lebih lama atau tidak) triaglelab 3d touch - masalah yang sama. 8/10 saya sendiri kondisi kerja: BLTOUCH_FORCE_SW_MODE + BLTOUCH_DELAY 1000. Tapi patch Anda bekerja 10/10 tanpa SW_MODE dan DELAY. Tnx!

Saya menguji probe sentuh berbasis servo pada lengan ulang (MCU yang sama) dan saya tidak memiliki masalah, tetapi saya menggunakan fitur nonaktifkan setelah gerakan.

saya belum mencoba tanpanya, juse masuk akal untuk menonaktifkan servo bila tidak diperlukan

Saya memiliki beberapa BLTouch asli dan semuanya bekerja dengan baik pada SKR 1.3 yang juga LPC1768 .

jadi melompat ke sini, apakah kemungkinan besar masalah perangkat keras (kabel, sambungan suara) atau masalah konfigurasi pengguna?

Alasan yang sama untuk sebagian besar opsi kode / konfigurasi BLTouch tambahan, ini adalah masalah klon BLTouch.

Ingatlah bahwa 3DTouch! = BLTouch. Ada banyak masalah tertutup terkait dengan salinan ini.

saya akan menyebutnya masalah perangkat keras,

ya saya sekarang 3dtouch (dan lainnya) bukan BLtouch

Pertanyaan besar bagi saya adalah apakah marlin mendukung klon atau apakah kita hanya peduli dengan produk asli?

memberikan sedikit pemikiran pribadi saya rasa tidak adil bahwa marlin harus mendukung klon

tapi saya bisa saja salah, pikiran?

Dua sen saya, tidak peduli apa nama XXtouch. Salah satunya terhubung ke pin SERVOS (bukan pin khusus BLtouch). SERVOS harus bekerja seperti servos.

Tetapi saya pikir, bahwa masalah ini harus diperbaiki bagaimanapun juga, karena saya pikir bahkan servo yang sebenarnya mungkin dapat bereaksi pada denyut nadi ini dengan goyangan singkat atau perilaku aneh lainnya.
(dari komentar @mlehnhoff )

Ini seharusnya tidak disalahkan pada perangkat keras probe. Sinyal yang dihasilkan dari papan tidak benar, dan diverifikasi menggunakan osiloskop. Itu harus diperbaiki.

Saya juga dapat mengonfirmasi bahwa perilaku yang dilaporkan sangat mirip dengan perangkat keras BLTouch asli ketika saya men-debug semua konflik pengatur waktu yang menyebabkan masalah serupa pada papan SKR Mini E3. Panjang pulsa yang tidak valid tampaknya menyebabkan BLTouch lupa apa yang dilakukannya dan menyebabkan kegagalan.

@mlehnhoff , apakah Anda menangkap gambar dari osiloskop Anda yang menunjukkan masalah tersebut, yang dapat Anda lampirkan ke masalah ini?

Saya rasa saya tidak menyukai solusi saat ini sebagai solusi lengkap, tetapi saya sangat menghargai tingkat detail mlehnhoff yang diberikan untuk menjelaskan masalah dan solusi yang menunjukkan bahwa denyut nadi tampaknya adalah akar penyebab masalah.

Maaf, saya tidak segera memberikan tangkapan layar cakupan. Saya pikir saya telah membuat beberapa, tetapi ada yang tidak beres. Tetapi saya tidak menyadarinya sampai saya telah mengembalikan ruang lingkup (itu bukan milik saya).
Tapi sekarang saya telah membuat yang baru:

Pada gambar Anda melihat transisi dari 1472µs ke 544µ, tapi baru pertama

pulsa adalah 20544µs.

Ditambah saya mencoba servo yang sebenarnya dan inilah buktinya, bahwa masalah ini tidak hanya terbatas pada 3dtouch atau klon lainnya.

IMG_4677.zip

Servo harus berubah dari 90 ° (tuas di tengah) menjadi 0 ° (tuas ke bawah), tetapi ketika denyut nadi yang salah terjadi, itu benar-benar muncul pada awalnya, sebelum turun.

Ngomong-ngomong, setidaknya ada delapan versi berbeda dari bltouch asli (klasik v1.0, v1.2, v1.3, smart v1.0, v2.0, v2.2, v3.0, v3.1) dan tidak satu tahu, jika semuanya akan bekerja dengan benar ;-)

Berikut adalah petunjuk lain: Ketika Anda mengirim perintah M280 secara manual, kemungkinan besar masalahnya tidak terjadi. Saya menulis skrip untuk mengaktifkan servo (digunakan dalam video) yang sangat meningkatkan kemungkinan:
servo_toggle.gcode.txt

Saya ingin tahu apakah ini terkait dengan masalah yang saya lihat dengan BLTouch saya.
Saya menyalakan Re-ARM saya melalui USB dan menggunakan M80 untuk menyalakan catu daya 12V. Ada konverter buck 5V yang terhubung ke catu daya 12V yang memberi daya pada BLTouch, sehingga BLTouch tidak mendapatkan daya hingga suplai 12V masuk.
Saat papan menyala, BLTouch berkedip merah - ini tampaknya agak normal jika BLTouch mendapat sinyal sebelum menyala, jadi saya tidak khawatir tentang itu.
Namun, upaya apa pun untuk menyetel ulang dengan M280 P0 S160 sama sekali tidak berpengaruh. Itu juga tidak mencabut pin jika di-deploy.
Namun, M280 P0 S60 berhasil beralih ke mode SW dan juga menghentikan kedipan.
Selain berkedip dan S160 tampaknya diabaikan, BLTouch tampaknya bekerja dengan sempurna. Bahkan ketika mengedipkannya dengan benar menyebarkan, menyimpan dan memeriksa - Saya telah melakukan probe tempat tidur penuh dan tidak pernah melihat kegagalan probe dan pengulangan sangat baik.
Ini adalah BLTouch V3.1 asli - bukan tiruan.

Saya lupa menyebutkan bahwa saya memeriksa pulsa dengan DSO mini murah saya dan osiloskop CRT besar saya dan panjang pulsa tampak baik-baik saja. Saya juga mencoba nilai S yang berbeda (dari 155 hingga 165) tanpa menemukan satu pun yang akan memicu reset.

Saya belum mencari cara kerja perpustakaan servo untuk LPC - tetapi:
Sinyal servo adalah PWM. Jika ini akan direalisasikan dengan pengatur waktu perangkat keras STM32, kesalahan ini kemungkinan besar akan disebabkan oleh memperbarui pencacah membandingkan register secara langsung, daripada memperbarui nilai baru ke preload register dari register pembanding. Jika mengubah register pembanding dari nilai tinggi ke nilai rendah sementara penghitung berada di antara nilai rendah dan tinggi, perbandingan (sama) dilewati, pin tidak berubah sampai penghitung dibanjiri dan dari mencapai nilai baru . Jika register pramuat digunakan, register pembanding diperbarui baik ketika counter overruns, atau ketika nilai perbandingan (lama) memiliki kecocokan. Ini tidak memiliki risiko loooong puls, hanya kemungkinan penundaan maksimal sekitar satu periode PWM (20ms).
EDIT: Kemungkinan kesalahan adalah 5% per lompatan 1 md ke belakang.
Saya kira, di sini kita memiliki sesuatu yang serupa.

Ini karena kerangka lpc tidak menjalankan perangkat keras pwm dalam mode latching, (di mana register pulsewidth dibayangi dan di-latch pada setiap periode), seharusnya dapat dilakukan dengan mode sederhana sedikit .. tapi sayangnya saya tidak bisa membuatnya bekerja dengan andal, itu adalah pilihan antara kemungkinan kesalahan durasi 1 periode, atau lebar pulsa secara acak (tetapi cukup sering tergantung pada seberapa sering diperbarui) tidak berubah sama sekali.

Penelitian lebih lanjut tentang masalah ini dapat dilakukan, tetapi ini sebenarnya bukan periferal yang rumit, saya membuang waktu lama untuk kesalahan itu dan pada akhirnya hal-hal lain perlu diperhatikan.

@mlehnhoff @kockockockoc Bagaimana dp Anda menerapkan tambalan?

@mlehnhoff @kockockockoc Bagaimana dp Anda menerapkan tambalan?

Sejujurnya, saya cukup baru mengenal git dan saya senang bisa membuat patch ini melalui "git diff". Saya yakin, harus ada perintah git yang berbeda untuk menerapkan patch ini kembali. Mungkin @kockockockoc dapat membantu ...
Tetapi untuk fragmen kode yang sangat kecil ini, Anda bahkan dapat melakukannya dengan tangan. Ini semudah menambahkan empat baris yang dimulai dengan "+" ke file "Marlin / src / HAL / HAL_LPC1768 / Servo.h" (tentu saja tanpa "+") pada posisi yang ditunjukkan ...

Hai, Saya memiliki papan yang sama Bigtreetech SKR v1.3 dan 3D Touch tetapi 3D Touch tidak berfungsi. Saya telah menguji 3dTouch menggunakan beberapa kode di Arduino Mega dan berfungsi dengan sempurna. Jadi, saya sudah mencoba saran yang saya temukan dan juga patch @mlehnhoff tetapi saya masih mengalami masalah yang sama = 3D Touch macet. Ketika Marlin memulai 3D Touch melakukan tes mandiri dan kemudian pin disimpan dan tetap dalam keadaan ini selamanya tanpa perubahan apa pun (melalui M43 S atau dari menu Marlin)
Saya sangat prihatin tentang itu karena saya tidak tahu apa yang harus saya lakukan untuk menyelesaikan masalah ini. Setiap saran diterima dengan baik.

Saya menduga bahwa bug ini sama dengan yang saya laporkan di sini: https://github.com/MarlinFirmware/Marlin/issues/15370

Saya masih menjalankan perbaikan bug dari tanggal 6/22/19 tanpa masalah. Saya mencoba perbaikan bug terbaru hari ini dan masalah servo masih ada.

@ Reywas62 dan semuanya, saya menemukan artikel ini http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html yang dapat menyelesaikan masalah. Rupanya beberapa papan SKR dapat memiliki sinyal keluaran yang memiliki impedansi rendah (sekitar 200 ohm) yang membutuhkan sejumlah besar arus untuk bekerja dengan baik (dan itu tidak terjadi pada papan Arduino, itulah alasan mengapa probe sentuh 3D saya bekerja dengan baik di Arduino) Jadi, ternyata itu tidak terkait dengan firmware.

Saya akan membeli penjelasan itu kecuali bahwa papan saya berfungsi dengan baik dengan komit sebelumnya dari perbaikan bug Marlin 2.0.x (6/22/19).

Saya dapat mengonfirmasi bahwa solusi "cepat dan kotor" dari mlehnhoff berfungsi. Saya memeriksa UBL-Mesh 9x9 dengan BLTouch Clone. Biasanya 1 atau 2 poin dari mesh 81 poin gagal saat saya menjalankan meshgeneration. Tetapi dengan "memperbaiki" semuanya bekerja dengan baik. Jadi saya akan terus menggunakan solusi ini. Dan saya kasus saya, saya pikir itu adalah masalah dengan pulsa servo yang panjang karena push-pin saya dipasang dan sensor tidak memicu.

Saya ingin memastikan bahwa masalah saya dengan 3D Touch telah teratasi. Masalahnya adalah arus rendah dari pin Servo SKR 1.3. Saya membuat sirkuit dan mengujinya dengan sukses. Sekarang saya telah menerima informasi ini setelah menjalankan M43:
MENGIRIM: M43 S
Tes probe servo
. menggunakan indeks: 0, menerapkan sudut: 10, sudut penyimpanan: 90
. Selidiki Z_MIN_PIN: 57
. Z_MIN_ENDSTOP_INVERTING: salah
. Periksa BLTOUCH
= BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1 terdeteksi.
* Harap picu penyelidikan dalam 30 detik *
. Lebar pulsa (+/- 4ms): 10
= BLTouch pra V3.1 (atau kompatibel) terdeteksi

Akan bereksperimen dengan pengaturan saya di sini, tetapi saya memiliki motor servo SG90 dan MG90 yang kadang-kadang bergerak kembali saat dinonaktifkan. Karena menahan sakelar Z-Probe, ini agak mematikan mesin saat menabrak tempat tidur. Tabrakan terakhir mencapai tunggangan roda Creality CR10 S5. > _

Ketika saya mendapat kesempatan, saya akan mencoba sirkuit dan melihat apakah itu menyelesaikannya. tetapi juga akan mencoba peretasan firmware. :)

Setelah mencoba hack firmware, tidak ada perubahan untuk saya (seperti yang saya duga, karena hack memperbaiki klon bl-touch, tidak harus gerakan servo). Servo terkadang masih bergerak mundur lebih jauh setelah menyelesaikan sebuah gerakan.

Mempertimbangkan itu, saya membatalkan peretasan dan memberi tahu marlin untuk TIDAK menonaktifkan servo dan tampaknya masalah pemindahan telah hilang. Sepertinya menonaktifkan servo memicu masalah saya. Untungnya MG90 yang saya gunakan tidak menunjukkan getaran / guncangan pada sudut yang saya pilih. :)

Saya pasti ingin berterima kasih kepada mlehnhoff untuk gcode mereka untuk diuji. Setiap kali saya menjalankannya servo akan diputar 3 atau 4 kali, dan ketika saya memberi tahu marlin untuk tetap mengaktifkan servo, skrip berjalan dengan baik 3 kali berturut-turut. Mempertimbangkan laporan arus rendah, saya juga menjalankan pengujian dengan pemanas untuk meletakkan PSU di bawah beban. :)

Tidak tahu apakah itu penting, tetapi sudut Servo saya adalah 172 (digunakan) dan 35 (Tersimpan) dan sepertinya itu akan menggerakkan servo mundur, dengan jumlah yang sama setiap saat. Servo tidak pernah bergerak maju.

Peretasan firmware tidak memperbaiki masalah saya, tetapi membiarkan servo diaktifkan menghentikan servo dari kesalahan fungsi, seperti yang terjadi pada DarkAlaranth. Bukan perbaikan, tapi solusi yang dapat diterima.

Sedikit latar belakang ekstra Saya sudah mencoba ini di beberapa platform selama beberapa hari terakhir dan berpikir saya mungkin telah merusak kedua BLtouch AntLab saya, jadi saya memesan yang ketiga.

Inilah yang saya amati untuk platform berikut
SKR Pro V1.1 Gagal bekerja
SKR v1.3 Gagal bekerja
RAMPS 1.4 Gagal bekerja
SKR v1.4 Gagal bekerja
RAMPS 1.6 Gagal bekerja

Gejala sebelum probing baca di M119
Melaporkan status endstop
x_min: DIPICU
y_min: TRIGGERED
z_min: DIPERBAIKI

Saya telah menyesuaikan file pin juga dengan hasil yang sama.

Berikut adalah proses yang saya gunakan dalam beberapa video dari berbagai macam 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

Saya dapat memposting lebih banyak video, tetapi poin saya adalah itu tidak berfungsi pada salah satu dari mereka dengan 3 sentuhan BL asli.

Apakah ada yang berubah dalam konfigurasi? Configuration_adv.h sekarang memiliki banyak pengaturan daya sentuh BL.

Haruskah ada suhu laporan saat mengarahkan sumbu Z?
Inilah debugnya:
DIKIRIM: G28 Z0
DIKIRIM: M114
DIKIRIM: M105
RECV: Kesalahan: !! STOP dipanggil karena kesalahan BLTouch - mulai ulang dengan M999
[ERROR] Kesalahan: !! STOP dipanggil karena kesalahan BLTouch - mulai ulang dengan M999

M119 pada RAMPS 1.6 / MEGA2560
Bacaan benar untuk buka pada z-min
Probing tampaknya tidak berfungsi.

Punya masalah ini.
Ender 3, SKR Mini E3 v1.2, BLTouch v3.1 asli

Bekerja dengan baik untuk saya dengan V2
Pengkabelan untuk skr1.3 berbeda dari orientasi stok. Saya menggunakan versi rilis Marlin 2.0.1

Apakah Anda dapat mencoba BLTouch lain? Untuk memverifikasi bahwa itu bukan probe yang rusak?

Tidak, maaf. Saya hanya memiliki BLTouch normal. Kegagalan hanya terjadi satu dalam ~ 200 atau lebih.

@mlehnhoff jika ada waktu, silakan tes ulang

dan karena perbaikan bug 2.0.x diperbarui setiap hari, harap uji ulang, katakanlah setiap 14 hari atau lebih

Mengompilasi ulang versi perbaikan bug terbaru [2020.01.24.]
Melakukan dua tes pengulangan probe, masing-masing 150.

1. Pemanas tempat tidur MATI, Selesai Berhasil, Standar Deviasi: 0,003928.
2. Pemanasan tempat tidur ON, Probing Gagal, gagal di 137.

Saya telah mengamati perilaku serupa saat menggunakan perbaikan bug 2.0.x pada papan SKR1.1 (LPC1768) dengan klon BLTouch (3DTouch).
Saya telah mencoba solusi yang berbeda, tetapi dari 25 titik probe, setidaknya untuk satu titik probing pin dilepaskan terlalu dini (seperti penerapan yang segera diikuti oleh penyimpanan).

@mlehnhoff jika ada waktu, silakan tes ulang

@boelle : pengujian ulang tidak diperlukan, karena seperti yang disebutkan @ p3p sebelumnya, masalah sebenarnya tidak terletak di Marlin itu sendiri, tetapi dalam kerangka kerja LPC. Ia mengatakan, ia harus menghapus tanda komentar pada Mode Latching PWM, karena tidak berfungsi dengan baik. Jadi, selama ini tidak diperbaiki, semua orang yang ingin memiliki bltouch yang berfungsi dengan andal harus menggunakan solusi jelek saya, tetapi berhasil.
Saat ini saya sayangnya tidak memiliki akses ke Osiloskop, jika tidak, saya ingin mendukung P3P dalam men-debug masalah ini. Jika ada orang lain yang ingin menggali lebih dalam tentang ini, silakan: https://github.com/p3p/pio-framework-arduino-lpc176x/blob/master/system/lpc176x/HardwarePWM.h

Punya masalah ini.
Ender 3, SKR Mini E3 v1.2, BLTouch v3.1 asli

SKR Mini E3 v1.2 menggunakan mikrokontroler STM32, bukan LPC1768.

Saya ingin tahu apakah masalah dengan penguncian PWM terkait dengan errata LPC176x berikut:

3.13 PWM.1: Saat memperbarui duty cycle untuk PWM1.1 dari 100%, in
dalam beberapa kasus, keluaran dapat tetap rendah untuk periode PWM penuh sebelum
pembaruan mulai berlaku
Pengantar:
Pada periferal LPC176x PWM, dua register pertandingan dapat digunakan untuk menyediakan satu
keluaran PWM yang dikontrol tepi. Register satu pertandingan (PWM1MR0) mengontrol siklus PWM
rate, dengan mengatur ulang hitungan demi kecocokan. Register pertandingan lainnya mengontrol tepi PWM
posisi. Sebagai contoh, register pencocokan PWM1MR1 mengontrol posisi tepi PWM1.
Beberapa keluaran PWM terkontrol satu sisi akan memiliki tepi naik di awal
setiap siklus PWM, ketika terjadi kecocokan PWM1MR0.
Masalah:
Hanya dalam mode satu sisi, jika duty cycle untuk PWM1.1 (Pulse Width Modulator 1, channel
1 keluaran) diperbarui dari 100% (PWM1MR1 = PWM1MR0), kemudian keluaran untuk PWM1.1
dapat secara tidak terduga tetap rendah untuk periode PWM penuh sebelum siklus kerja baru yang diinginkan
mulai berlaku. Masalah ini hanya mempengaruhi keluaran untuk PWM1.1. Saluran PWM lainnya
(PWM1.2 hingga PWM1.6) tidak terpengaruh oleh masalah ini.
Bekerja di sekitar:
Perbaikan perangkat lunak dapat diterapkan di mana pengguna dapat memuat PWM1MR1 dengan
PWM1MR0 + 1 (setidaknya 1) untuk menghindari penundaan dalam pembaruan keluaran PWM1.1.

Saya berharap tidak, karena saya tidak akan berpikir bahwa kami pernah memasang pin servo dalam mode PWM 100%.

Kemudian lagi pada PWM 1.1 digunakan untuk P2_0 yang merupakan pin servo pada SKR 1.3 ...

Saya telah melihat masalah serupa (dengan BL Touch 3.1 asli dan SKR PRO 1.1).
Saya telah mendokumentasikan apa yang saya temukan di # 16986 tetapi pada dasarnya saya menemukan bahwa milik saya terkait dengan XY_PROBE_SPEED. Angka 10000 menyebabkan sinyal BL Touch berubah dari pulsa ke level DC pada 15 titik probing (yang juga merupakan yang pertama setelah gerakan Y pertama), angka 6000 bagi saya tidak menunjukkan masalah apa pun.

Saya telah menguji solusi ini selama lebih dari sebulan pada dua Ender 3 dengan SKR v1.3 dan 3D Touch v2 (dan Pi 3B). Sebelumnya, saya selalu mengalami kegagalan rutin saat melakukan ABL (setidaknya 1 dari 3-5 cetakan) di mana probe tidak akan memicu (tetapi berkedip merah segera) dan nosel akan menabrak tempat tidur, jika bukan karena ujung mekanis Z -stop Aku sengaja pergi. Dan saya telah mencoba sebagian besar, jika tidak semua, permutasi dari konfigurasi probing / BL Touch di Marlin 2.0.x.
Karena saya mengalami 0 kegagalan selama pemeriksaan yang tak terhitung jumlahnya selama minggu-minggu ini (baik M48 dan banyak cetakan sebenarnya), saya harus menganggap solusi ini sukses dalam kasus saya. Saya akan, tentu saja, memperbarui temuan saya jika hasilnya berubah.
Saya juga telah menguji bahwa ia bekerja independen dari kecepatan probe XY (mencoba 6-8-10000 mm / s), kecepatan probe Z dan tanpa menonaktifkan pemanas / steppers selama probing. Pada dasarnya, pengaturan probing di Marlin tampaknya tidak lagi menjadi faktor untuk menghindari kegagalan (tetapi mungkin masih memengaruhi presisi, setidaknya kecepatan Z).
Satu-satunya masalah adalah bahwa lampu latar LCD (5V) berkedip sementara selama probing jika 5V-nya diambil dari SKR, kemungkinan menunjukkan penurunan tegangan karena konsumsi probe saat ini (tetapi tidak ingin mengisolasi dan menyelidiki semuanya dengan ruang lingkup saya) . Jadi, saya kabel 5V ke Pi sebagai gantinya (tetapi bisa juga menjadi sumber 5V eksternal) dengan dua kabel GND yang disambungkan di dekat probe, satu berjalan ke SKR dan yang lainnya berjalan ke Pi (untuk tanah bintang orang miskin) .

@bayu_joo
Silakan uji cabang bugfix-2.0.x untuk melihat tempatnya.

Saya akan segera mengujinya di BLTouch asli saya, saya yakin saya memiliki masalah yang sama.

Sunting: Bukan papan yang sama (STM32F103RC) tetapi masalah yang identik! Mencoba mencari tahu apakah ini masalah waktu atau sesuatu yang lain! Tetapi ketika melakukan mesh 91 UBL saya mungkin mendapatkan 1 atau 2 probe gagal dengan cara yang sama seperti yang dijelaskan di sini?

Yah saya menemukan papan saya tampaknya menggunakan kode servo 'bersama'. Saya telah menambahkan di bawah ini setelah beberapa trial and error dan tampaknya safe_delay dari 6ms / us? sedang bekerja! Sensor tampaknya memicu lebih cepat jika itu masuk akal? Dan sekarang saya berhasil mendapatkan mesh pertama saya tanpa sensor yang gagal? Akan mengawasinya dan menjalankan lebih banyak tes tetapi awalnya terlihat menjanjikan! Ini dengan BLTouch asli, saya telah memesan yang kedua karena mengira itu rusak! Saya tidak berpikir perangkat kerasnya yang lain karena pengaturan ini berfungsi dengan baik pada papan stok asli, hanya sejak pindah ke BTT V2.0 dan Marlin mengalami masalah ini. Sebelumnya saya menjalankan Klipper tanpa masalah.

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

@ aslater3 Bagaimana cara mengetahui apakah papan saya (SKR Mini E3 v1.2) memiliki kode servo 'berbagi'?

@ Boelle maaf saya cukup sibuk dengan hal-hal yang berbeda. Saya baru saja menguji perbaikan bug terbaru-2.0.x (yang tampaknya 2.0.5.4). Masalahnya masih ada. Itu karena masih belum diperbaiki di pio-framework-arduino-lpc176x.
Tetapi saya memiliki akses ke osiloskop sekarang dan saya ingin menyelidikinya lebih lanjut (dan akhirnya memperbaikinya) ...

2.0.5.4 ( 2.0.x ) dan bugfix-2.0.x adalah dua cabang yang berbeda. Coba bugfix-2.0.x dan beri tahu kami jika Anda masih mengalami masalah ini.

2.0.5.4 ( 2.0.x ) dan bugfix-2.0.x adalah dua cabang yang berbeda. Coba bugfix-2.0.x dan beri tahu kami jika Anda masih mengalami masalah ini.

Ya, saya tahu dan saya memang menggunakan bugfix-2.0.x terbaru! 2.0.5.4 hanyalah apa yang ditunjukkan oleh menu LCD

Tapi ini tidak masalah, karena bug tidak ada di dalam Kode MarlinFw itu ada di dalam pio-framework-arduino-lpc176x

Bahkan diketahui bagian mana dari kode yang menyebabkan masalah: penguncian HW-PWM yang dinonaktifkan.

Masalahnya adalah menemukan cara untuk mengaktifkan kembali penguncian tanpa mengalami masalah lain. Inilah mengapa penguncian telah dinonaktifkan.

Saya mengobrol dengan @ p3p tentang ini, karena saya telah menyelidiki masalah serupa di platform lain. Saya tidak berpikir ada kemungkinan perilaku ini telah diubah, dan upaya untuk menguji ulang saat ini tidak sepadan, kecuali sebagai bagian dari penerapan solusi yang lebih permanen.

2.0.5.4 hanyalah apa yang ditunjukkan oleh menu LCD

Maka Anda tidak menggunakan perbaikan bug terbaru. LCD Anda akan menampilkan bugfix-2.0.x .

Saya mengetahui kesalahan 1 periode saat menyetel siklus tugas yang lebih pendek setelah melewati nilai kecocokan baru, saat ini saya tidak yakin bagaimana cara mengurangi masalah. Perangkat keras tampaknya tidak melakukan apa yang seharusnya dilakukan ketika register bayangan pwm diaktifkan.

2.0.5.4 hanyalah apa yang ditunjukkan oleh menu LCD

Maka Anda tidak menggunakan perbaikan bug terbaru. LCD Anda akan menampilkan bugfix-2.0.x .

oke, saya buruk, saya secara tidak sengaja mengkloning cabang 2.0.x daripada bugfix-2.0.x ... sekarang saya memperbaikinya -> tidak ada perbedaan (tentu saja)

Saya mengetahui kesalahan 1 periode saat menyetel siklus tugas yang lebih pendek setelah melewati nilai kecocokan baru, saat ini saya tidak yakin bagaimana cara mengurangi masalah. Perangkat keras tampaknya tidak melakukan apa yang seharusnya dilakukan ketika register bayangan pwm diaktifkan.

@ p3p Bisakah Anda memberi tahu saya, masalah apa yang Anda alami, saat Anda mengaktifkan penguncian?

Dari apa yang saya ingat (sudah lama sejak saya men-debug ini), dengan register bayangan diaktifkan lebar pulsa akan secara sporadis tidak diperbarui sama sekali, seperti yang dapat Anda bayangkan saya memilih kesalahan 1 periode daripada itu. Sepertinya itu mungkin disebabkan oleh memperbarui lebar pulsa lebih dari sekali dalam periode yang sama tetapi saya tidak yakin.

Sudut servo yang diperintahkan harus tetap setidaknya 20 ms agar terlihat pada output sebagai lebar pulsa yang berubah.
Untuk membuat lebar pulsa baru dapat dikenali oleh perangkat / servo, kemungkinan perlu beberapa pulsa.
Jadi mengubah sudut dalam setidaknya 20 ms harus dilarang.
Dari apa yang ditemukan @sjasonsmith untuk BL_Touch dan tunjukkan di https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment -657406598 lebih baik sekitar 60 md.

Memperbarui register bayangan lebih sering tidak masuk akal. Register tidak boleh ditulis lebih sering dari perubahan nilai sudut. (Variabel bayangan untuk register bayangan?)
Kemungkinan diperlukan patch tambahan di tingkat yang lebih tinggi dari perpustakaan servo untuk mencegah perubahan yang terlalu sering. Kami sudah memiliki sesuatu yang serupa dengan SERVO_DELAY , awalnya seharusnya untuk mencegah sinyal servo shutdown sebelum servo (secara mekanis) mencapai targetnya.

@AnHardt Saya tahu bahwa mengubah register bayangan beberapa kali per periode tidak ada gunanya, tetapi saya tidak mengerti mengapa mengubahnya beberapa kali sebelum nilai didorong ke register sebenarnya pada akhir periode akan menyebabkan masalah, saya tidak yakin apa solusi untuk menghentikan aplikasi klien yang memperbarui perangkat keras PWM terlalu sering (jika itu masalahnya), tanpa kinerja yang signifikan memukul dalam satu atau lain cara.

@AnHardt Saya tahu bahwa mengubah register bayangan beberapa kali per periode tidak ada gunanya, tetapi saya tidak mengerti mengapa mengubahnya beberapa kali sebelum nilai didorong ke register sebenarnya pada akhir periode akan menyebabkan masalah,

Saya juga tidak tahu mengapa atau apakah ada masalah. Tetapi jika Anda memberi tahu kami bahwa itu menyebabkan masalah, kami harus mencoba menghindarinya.
Sebuah konstruksi seperti:

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

setidaknya akan mencegah penulisan berulang kali ke register bayangan dengan nilai yang sama.

Jika saya ingat dengan benar, terakhir kali saya menyentuh kode SERVO_PROBE, sebelum BL-Touch muncul, saya dengan hati-hati menghindari memindahkan servo dan steppers pada saat yang sama dengan sinkronisasi - tetapi saya selalu menguji dengan DEACTIVATE_SERVOS_AFTER_MOVE , karena servos saya bergetar ketika stepper bergerak, menghasilkan jeda SERVO_DELAY (beberapa ratus md) setelah menyetel servo_angle. Dibandingkan dengan penundaan yang jauh lebih singkat yang saya sarankan sekarang adalah kemenangan dalam kinerja.

Jika kode BL-Touch mencoba untuk memindahkan servo dan steppers pada saat yang sama, itu tidak terasa seperti bola yang harus saya mainkan.

Karena BL-Touches ingin memiliki sinyal servo yang terus menyala DEACTIVATE_SERVOS_AFTER_MOVE tidak mungkin. Untuk pustaka servo yang digerakkan interupsi, interupsi yang tertunda menjadi bencana besar, mengacaukan sinyal servo. PWM yang digerakkan oleh perangkat keras akan kebal. Biasanya kami hanya memiliki satu servo.

Namun, saya yakin set_servo(0); set_servo(180); set_servo(0); tanpa jeda sama sekali tidak akan menyebabkan reaksi - baik pada servo sungguhan, maupun pada BL-Touch.

Maaf. Mungkin pemikiran saya terlalu terfokus pada perangkat keras PWM, pada saat ini, di mana pengatur waktu membandingkan mendaftar hanya perlu diupdate sesekali.

Maaf. Mungkin pemikiran saya terlalu terfokus pada perangkat keras PWM, pada saat ini, di mana pengatur waktu membandingkan mendaftar hanya perlu diupdate sesekali.

Masalah ini ada pada PWM Perangkat Keras, dan saya setuju dengan semua yang Anda katakan, saya baru saja memikirkan masalah di tingkat kerangka kerja, seperti bagaimana membuat perangkat keras bekerja dengan andal bahkan ketika aplikasi klien melakukan banyak pembaruan (Marlin ) dalam periode yang sama. Klien akan mengharapkan pembaruan terakhir berlaku, daripada yang pertama, dan saya tidak tahu bahwa tidak akan ada pembaruan berikutnya sebelum akhir periode.

Saya harus melihat kembali masalah tersebut untuk melihat apakah solusi baru muncul di benak saya, dan apakah diagnosis itu benar-benar benar dan saya tidak hanya menjadi bodoh.

Saya akan mencoba
kapan posisi jangka pendek dapat dihilangkan:

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

berjalan setiap 20 ms.
Itu harus menahan panjang pulsa output konstan setidaknya 3 * 20 ms dan kemudian diletakkan di sudut perintah terbaru saja. Namun itu tidak akan tahu sudut mana yang akan datang berikutnya atau apakah pembaruan akan mengikuti sama sekali - itu tidak mungkin untuk diketahui - beberapa saat Anda harus memulai. Anda hanya perlu menjamin pengiriman pulsa dapat dibaca dan register bayangan tidak sering diperbarui.

Untuk menjamin setiap pembaruan dilakukan setidaknya untuk waktu itu, variabel volatil harus diganti dengan antrian.

Dalam RC-flying posisi perantara kemungkinan dapat dihilangkan. Jika BL-Touch menyimpan, menerapkan, mengatur ulang, mengubah mode, ... semuanya sama pentingnya. Memperhatikan ini dapat dihilangkan, setiap perintah harus tinggal cukup lama untuk dikenali. Tidak ada solusi universal yang tepat untuk perpustakaan servo universal.

Selain itu untuk BL-Touch semua perintah harus sinkron dengan gerakan steppers. Menarik kembali probe saat turun untuk probe sebaiknya dihilangkan. :-)
Jadi dari sudut pandang saya Marlin harus bertanggung jawab untuk tidak memperbarui sudut terlalu sering.

Edit:
Kemungkinan interupsi pembanding adalah yang tepat untuk memperbarui register perbandingan bayangan. Interupsi kemudian dapat ditunda oleh interupsi prioritas yang lebih tinggi sekitar 17 ms dan masih akan tepat waktu untuk menyiapkan register-pembaruan untuk disalin ke register-pembanding ketika luapan terjadi.
Harus dimungkinkan untuk menghentikan interupsi jika penghitung berada di atas 3. Mungkinkah dimulai ulang ketika inter_angle diperbarui.

Saya mengalami masalah yang sama dengan SKR mini 1.1.
Tidak peduli posisi apa yang saya letakkan, servo selalu menuju ke titik yang sama.

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

@Matheusschmitz mini SKR menggunakan platform yang berbeda dan akan menjadi unik dari edisi ini. Beberapa perubahan terjadi lebih dari seminggu yang lalu untuk meningkatkan keandalan BLTouch untuk papan STM32F1 (seperti milik Anda). Silakan coba gunakan cabang bugfix-2.0.x untuk melihat apakah itu menyelesaikan masalah Anda.

Jika Anda masih memiliki masalah, silakan berdiskusi di salah satu tempat dukungan seperti Discord. Masalah khusus ini harus tetap fokus pada papan LPC176x.

Saya juga mengalami masalah ini dengan klon SKR1.3 dan BLTouch saya.
Saya berhasil menangkapnya di video, tepat di sekitar tanda 1:54:
https://www.youtube.com/watch?v=wF0Mia49ECI&t=114s
(video 1080p YouTube harus memprosesnya)

Ini juga gambar yang menunjukkan apa yang dilakukannya ketika itu terjadi selama UBL

Saya telah mencoba, seperti yang lain, berbagai pengaturan yang dapat membantu, mereka tidak membantu.
Saya menggunakan cabang bugfix-2.0.x terbaru

Masalah yang sama di pihak saya.
Saya akan menguji solusinya juga

Masalah ini tidak ada aktivitas dalam 30 hari terakhir. Harap tambahkan balasan jika Anda ingin masalah ini tetap aktif, jika tidak maka akan ditutup secara otomatis dalam 7 hari.

Saya pikir ini layak untuk dibuka sampai solusi permanen dapat ditemukan.

Saya setuju dengan sentimen itu

Masalah ini tidak ada aktivitas dalam 30 hari terakhir. Harap tambahkan balasan jika Anda ingin masalah ini tetap aktif, jika tidak maka akan ditutup secara otomatis dalam 7 hari.

Saya pikir masalah ini harus tetap terbuka.