Marlin: [bugfix-2.0.x] G28 atau G28 X crash sumbu X jika end-stop dalam status triggerd saat homing

Apakah Anda dapat mempersempit letak kesalahan dalam kode?

Saya berharap saya bisa @thinkyhead Saya sama sekali bukan pembuat kode, saya sangat menyukai Marlin. Saya dapat memberitahu Anda itu terjadi Setelah 17 September karena itu adalah Penarikan saya sebelumnya. Saya mencoba untuk maju dengan perbaikan bug setiap beberapa minggu sehingga saya dapat tetap terkini jika saya harus melaporkan bug.

Harap ZIP konfigurasi Anda dan lampirkan ke balasan, seperti yang diminta dalam template terbitan.

Marlin_config.zip
Ini dia.

Sementara itu, coba versi ini (17 Oktober) dan lihat apakah masalahnya masih ada: https://github.com/MarlinFirmware/Marlin/archive/c36773bffba9f5300764238a06a7cb9e04c315da.zip

@bayu_joo

void Endstops::enable(const bool onoff) {
  enabled = onoff;

  #if ENABLED(ENDSTOP_INTERRUPTS_FEATURE)
    update();
  #endif
}

Saya pikir ini harus dilakukan juga ketika tidak ada interupsi diaktifkan karena modifikasi terakhir saya menghapus status endstop setelah rumah dan mereka tidak diperbarui disegarkan lagi ketika diaktifkan kembali (saya menggunakan interupsi dan berfungsi dengan baik)

@GhostlyCrowd mencoba menghapus #if #endif baris di endstops.cpp fuction enable

Edit: tetapi pertahankan baris update

@thinkyhead meskipun kode ini:

      // At this point, we must ensure the movement about to execute isn't
      // trying to force the head against a limit switch. If using interrupt-
      // driven change detection, and already against a limit then no call to
      // the endstop_triggered method will be done and the movement will be
      // done against the endstop. So, check the limits here: If the movement
      // is against the limits, the block will be marked as to be killed, and
      // on the next call to this ISR, will be discarded.
      endstops.update();

harus bertindak sama ...

Sunting: ini mungkin bekerja tertunda karena filter tiga kali lipat ...

@bayu_joo

build itu memang bertindak dengan benar dengan akhir saya berhenti

Ya, saya harus menonaktifkan inttrup endstop karena saya memiliki TMC2130 dan untuk beberapa alasan dengan pustaka TMC terbaru memiliki konflik dengan inturrup endstop. Ada masalah yang diposting tentang itu, tetapi hanya menyarankan menonaktifkan inturrup endstop adalah solusinya.

Sunting, saya mencoba modifikasi kode ke endstops.cpp sekarang

@GMagician mungkin ide yang tepat. Coba yang ini: https://github.com/thinkyhead/Marlin/archive/f96be3c3dd36a13d9de3aae0f831bc604a1c2b73.zip

Jika berhasil, saya akan segera mengirimkan tambalan.

@ Thinkyhead Saya mencoba apa yang Anda sarankan, itu tidak berhasil.

Saya mengunduh dan mengumpulkan apa yang telah diberikan @GMagician untuk Anda berikan kepada saya, itu juga tidak berhasil.

Masih masalah yang sama.

Penarikan 17 Oktober yang Anda kirimkan kepada saya DID berfungsi dengan baik.

Oke, karena versi dari 17 Oktober berfungsi, perubahannya pasti setelah itu. Silakan coba yang ini, mulai 28 Oktober: https://github.com/MarlinFirmware/Marlin/archive/5ead0269676b80292a360e5b132204ebecdc40a5.zip

@thinkyhead 28 Oktober rusak, Jadi sesuatu antara 17 Oktober dan 28 Oktober

@GhostlyCrowd dan @thinkyhead Saya pikir solusi saya tidak berhasil karena ENDSTOP_NOISE_THRESHOLD . Update harus dipanggil Saya pikir ENDSTOP_NOISE_THRESHOLD + 1 kali sebelum benar-benar memperbarui status penghentian

@GhostlyCrowd Anda dapat mencoba ini untuk mengkonfirmasi kecurigaan saya.
Di dalam Enable fungsi tulis:

update();
endstop_poll_count=1;
update();

ini bukan solusi tetapi jika berhasil maka itulah caranya ...

@GMagician Saya tidak bisa mendapatkannya untuk kompilasi menambahkan

kode yang Anda sarankan untuk endstop.cpp

Marlin\src\module\endstops.cpp: In static member function 'static void Endstops::enable(bool)':
Marlin\src\module\endstops.cpp:273:8: error: 'Update' was not declared in this scope
Update();
^

@GhostlyCrowd maaf saya salah mengetik semua huruf kecil

@GMagician Itu memang memperbaiki masalah

Apakah ini pekerjaan kotor atau perbaikannya?

Itu hanya membuktikan keraguan saya dan hanya berfungsi untuk konfigurasi dengan ENDSTOP_NOISE_THRESHOLD diaktifkan, ini tidak pernah bisa disebut 'pekerjaan kotor' itu lebih buruk dari itu ;-)

@GMagician Ahhh saya mengerti, jadi apa masalah mendasar yang Anda curigai?

Masalahnya adalah untuk membiarkan mesin bekerja setelah sebuah rumah, status penghentian dihapus. Dalam kode ketika gerakan baru dimasukkan ke dalam perencana ada panggilan untuk memperbarui status penghentian tetapi hanya berfungsi untuk mode "interupsi", ketika Anda memiliki ENDSTOP_NOISE_THRESHOLD , pembaruan harus dipanggil ENDSTOP_NOISE_THRESHOLD + 1 kali untuk benar-benar memperbarui penghentian tetapi panggilan ini dilakukan dalam rutinitas polling suhu (1KHz) tetapi terlalu lambat dan akan memperbarui status endstop terlalu terlambat.

Kode 'kotor' saya mempercepat tetapi saya pikir beberapa solusi berbeda harus ditemukan.

Karena "penundaan" ini dilakukan untuk memfilter suara yang tidak benar untuk memperbarui status seperti yang saya lakukan ... mungkin panggilan enable harus menunggu semua waktu pantulan sebelum pindah (tetapi di perencana tidak dapat dilakukan) tetapi juga benar bahwa jika pembaruan selalu dipanggil ketika endstop diaktifkan mungkin tidak diperlukan lagi di perencana.

masuk akal mengapa saya tidak memperhatikan ini sampai saya harus menonaktifkan interupsi endstop karena perpustakaan TMC bertentangan dengan itu karena beberapa alasan aneh.

@thinkyhead apakah "legal" untuk mengganti update dengan sesuatu seperti forceupdate yang menunggu sampai endstop_poll_count adalah 0?
misalnya:

FORCE_INLINE void forceupdate() {
  #if ENDSTOP_NOISE_THRESHOLD
    do { update(); } while (endstop_poll_count);
  #else
    update();
  #endif
}

dan hapus update call inside planner? Menurut saya panggilan terakhir ini tidak diperlukan karena status penghentian terbaru "selalu" saat diaktifkan (bahkan dengan interupsi)

Ok jadi @GMagician, pekerjaan Anda di sekitar tampaknya berfungsi untuk homing sementara penghentian akhir dipicu tetapi memiliki efek buruk pada lemak yang sekarang ketika pencetakan saya selesai dan mencoba untuk memarkir sumbu X dengan G28 X itu tidak melihat pemicu endstop dan sekarang rusak setelah dicetak.

Sunting: Saya melakukan pencetakan cepat lagi sekarang untuk memverifikasi ini.

@GhostlyCrowd yang seharusnya tidak memengaruhi G28.

@GMagician Anda benar Saya lupa untuk meningkatkan arus stepper saya setelah melakukan semua tes ini dan itu terdengar seperti kehilangan langkah saat menabrak. Baru saja mencetak lagi untuk memverifikasi.

@GhostlyCrowd coba ganti update panggilan di enable dengan kode yang diusulkan untuk forceupdate . Saya tidak yakin kode pemblokiran seperti itu dapat dilakukan tanpa safedelay ? panggilan

@GMagician Saya bisa melakukan ini besok pagi untuk Anda uji. Saya telah meninggalkan bengkel saya untuk hari itu.

apakah "legal" untuk mengganti pembaruan dengan sesuatu seperti forceupdate yang menunggu sampai endstop_poll_count adalah 0?

Saya pikir ini mulai terlihat seperti peretasan untuk mengatasi sesuatu yang secara fundamental rusak oleh pembaruan sebelumnya. @ejtagle bekerja keras untuk memeriksa endstop dengan benar, dan perubahan terbaru tidak memperhitungkan teori mekanismenya. Saya akan merekomendasikan Anda kembali ke sebelum perubahan dibuat dan mempertimbangkan kembali apa yang Anda coba capai dengan perubahan baru-baru ini.

@ Thinkyhead ... kamu benar. Kami selalu (terkadang saya juga!) Gagal mendapatkan gambaran keseluruhan di sini. Masalah yang dinyatakan ada, tetapi perbaikan harus dilakukan pada level yang lebih tinggi - Stepper dan kelas endstops bukanlah masalahnya.

Bagaimana cara kerjanya?
1) Jika ENDSTOPS_INTERRUPTs dinonaktifkan:
-Anda baru saja mendapatkan endstop yang disurvei setiap 1khz - Jika ada NOISE FILTER yang diaktifkan, maka Anda bisa mendapatkan penundaan variabel antara tekan sakelar dan benar-benar memperhitungkannya, jika tidak, tindakan akan segera diambil
2) Jika ENDSTOPS_INTERRUPTs diaktifkan, dan tidak ada pemfilteran, maka sakelar dibaca dan tindakan segera diambil
3) Jika ENDSTOPS_INTERRUPTs diaktifkan, dan memfilter ,, maka setiap interupsi akan memicu polling periodik (1khz) sampai nilai-nilai menjadi tenang. Kemudian pemungutan suara berakhir.

Apa yang membuat segalanya lebih kompleks adalah polling atau status pembaruan hanya dilakukan ketika penghentian diaktifkan .... Itulah yang biasanya menyebabkan masalah, karena penghentian, kecuali SELALU_ENABLED, tidak akan diperbarui jika ada perubahan

Benar, jadi… Alih-alih status aktif yang sederhana, haruskah kita membuatnya memiliki status 2… di mana endstop sedang disiapkan, dan status 1… di mana endstop sekarang sedang dibaca untuk penggunaan sebenarnya?

Kami dapat mencoba untuk menjaga agar status selalu diperbarui, tetapi tidak tindakannya.
Itu seharusnya mudah

Begitulah cara saya sebelumnya mencoba menerapkannya. Jadi jika tidak seperti itu sekarang, itu regresi.

@ Ejtagle apakah legal untuk mengganggu dan menyaring? Jika saya ingin interupsi karena saya ingin respon yang cepat jika saya memiliki suara tidak ada interupsi adalah logika bagi saya ...

@thinkyhead dan @ejtagle kami juga dapat menjaga endstop selalu berfungsi saat ENDSTOP_NOISE_THRESHOLD diaktifkan (ini adalah satu-satunya situasi di mana status tertunda) tetapi tidak menyalin live_state ke validated_live_state hingga penghentian diaktifkan

@GMagician : Ya, gangguan dengan pemfilteran noise diperbolehkan. Anda bisa menganggapnya sebagai pengatur waktu. Interupsi digunakan untuk memulai pengatur waktu yang mengumpulkan penghentian. Dan penghentian otomatis pengatur waktu saat penghentian stabil

@ Thinkyhead : Sebagian besar masalah dengan endstop disebabkan, oleh, sebut saja, tindakan yang dipicu oleh tepi.
Jadi, jika pembaruan dinonaktifkan (abort_enabled () mengembalikan false), maka update () tidak mengeksekusi- Ada risiko kehilangan edge (transisi dari non-triggered-triggered-non triggered) saat dinonaktifkan. (biasanya ini sama sekali bukan masalah)

Hal lain yang terkadang menimbulkan masalah adalah adanya penundaan antara pemicuan endstop dan Marlin menganggapnya sebagai pemicu. Penundaan kecil ini dapat menyebabkan kondisi balapan jika pergerakannya terlalu cepat, atau terlalu pendek.

Ini secara khusus berlaku saat mengaktifkan penghentian, karena harus ada beberapa waktu sebelum penghentian stabil ke nilai yang benar!

Apa kemungkinan perbaikan untuk perintah G28? - Nah, saya pikir pendekatan terbaik adalah dengan sedikit memodifikasi aliran:

Ketika perintah G28 dijalankan, langkah pertama yang harus dilakukan adalah mengaktifkan penghentian, kemudian melakukan tunggu sebentar (100mS) untuk memungkinkan filter kebisingan menjadi stabil, dan KEMUDIAN memulai proses pengalihan. Atau, lakukan penundaan 10mS, lalu tunggu hingga endstop_poll_count sama dengan 0.

Itu mungkin pendekatan terbaik. Dan 100mS penundaan ekstra saat homing tidak terlalu mencolok! : +1:

Jadi, jika pembaruan dinonaktifkan ( abort_enabled() mengembalikan false ), maka update() tidak dijalankan

Ini tidak benar, setidaknya sebelum perubahan baru-baru ini. Temperature::isr menelepon poll() dan (bila ENDSTOP_INTERRUPTS_FEATURE dinonaktifkan) poll() selalu memanggil update() . Dan jika ENDSTOP_NOISE_THRESHOLD diset maka update() terus maju… Setelah validated_live_state diuji, maka update() akan kembali tanpa memicu apapun kecuali abort_enabled() benar.

Menurut saya, pengujian abort_enabled() pada awal update() seharusnya tidak ada. Pengumpulan status endstop harus diizinkan untuk dilanjutkan apa pun yang terjadi. Dan kemudian di bawah, di mana saat ini hanya melakukan logika untuk ENDSTOP_NOISE_THRESHOLD itu juga harus memiliki blok untuk melakukan logika ketika ENDSTOP_NOISE_THRESHOLD tidak disetel. Khususnya, hanya memperbarui live_state .

@ Thinkyhead : Saya pikir Anda benar. Keadaan harus selalu dijaga. Tindakan inilah yang kami nonaktifkan

Itu harus menghilangkan penundaan pemrosesan

Kelemahannya adalah itu berarti Suhu ISR akan selalu memiliki overhead tambahan untuk memeriksa semua pin endstop.

Jika Anda menggunakan fitur interupsi pada perubahan, pembaruan harus HANYA dipanggil ketika ada perubahan.
Jika Anda tidak menggunakan fitur itu, Anda mendapatkan polling terus menerus, jadi Anda benar ...

Saya mengerti maksud Anda. Pilihan lain adalah menyimpannya seperti sekarang, tetapi tambahkan penundaan yang saya sarankan setiap kali penghentian diaktifkan

Penundaan ini dapat ditambahkan ke endstops :: enable () dan endstops :: enable_locally () dan mendokumentasikannya sebagai "penundaan stabilisasi"

Pendekatan forceupdate juga masuk akal… Terus panggil update() hingga jumlah polling (jika ada) turun ke 0. Kemudian kita tahu status endstop dikonfirmasi dan dicatat.

jika Anda tidak menggunakan fitur itu, Anda mendapatkan polling terus menerus,

Saat ini Anda hanya akan mendapatkan polling berkelanjutan saat menggunakan ambang batas.

Pada dasarnya ya. Ada yang aneh di sini ... panggilan update () seharusnya membatalkan gerakan apa pun yang melawan endstop ...

Mungkin forceupdate hanya perlu dipanggil saat mematikan endstops / probe.
… Dan saat ambang batas digunakan.

Mungkin saya tahu apa yang terjadi di sini ...
update () hanya dipanggil ketika terjadi perubahan penghentian (jika ENDSTOPS_INTERRUPTS) diaktifkan.
Dan, jika gerakan baru masuk antrean, update () akan dipanggil SEKALI dari stepper ISR (karena endstop sudah ditekan dan tidak ada yang menyetel ulang endstop_poll_count) - Ini tidak cukup karena FILTER_THRESHOLD, yang memerlukan lebih banyak panggilan agar berurutan untuk mengenali penghentian sebagai tidak dipicu.
...
Tapi sekali lagi, pergerakan tidak boleh melawan endstop ... kecuali .. Mari kita asumsikan endstop dinonaktifkan ... dalam hal ini, panggilan update () dari stepper tidak cukup untuk membatalkan gerakan ...

Benar! Jadi, apakah kita sudah memastikan bahwa masalah hanya terjadi dengan ENDSTOP_INTERRUPTS ?

Oh iya. Saya melihat bahwa panggilan update dari stepper hanya dilakukan saat pertama kali mengambil blok.

Jadi, apakah kita membuat pengecualian untuk panggilan dari stepper? yaitu, Setel jumlah polling ke 1 sebelum panggilan sehingga hanya satu sampel yang diperlukan sebelum dianggap dikonfirmasi?

Tentu saja, tanpa ENDSTOP_INTERRUPT, akan ada panggilan ke update () dari ISR ​​suhu, jadi pergerakan harus dibatalkan.

Satu-satunya kombinasi yang "berbahaya" adalah ENDSTOP_INTERRUPT dan FILTER_THRESHOLD, karena diperlukan untuk memanggil beberapa kali update () untuk mengubah status yang terdeteksi ... Tapi tetap ada sesuatu yang tidak masuk akal ...

Satu-satunya cara ini dapat terjadi adalah jika filter harus dijalankan untuk semua FILTER_THRESHOLD untuk mengenali bahwa penghentian telah ditekan, TETAPI itu harus dilakukan ...

Juga, interupsi tidak akan pernah dihasilkan jika sakelar sudah ditekan ketika gerakan dimulai. (Bukan masalah untuk homing tanpa sensor.)

Tepat, tetapi keadaan seharusnya sudah mencerminkan pada saat itu bahwa penghentian ditekan

Saya telah mengaudit prosedur yang saat ini kami ikuti. Mungkin jika saya melanjutkan proses itu akan lebih masuk akal. Apakah Anda memeriksa perubahan terbaru untuk melihat bagaimana hal itu menyebabkan masalah ini sekarang terwujud, padahal sebelumnya tidak?

Biarkan saya melihat apakah saya dapat menemukan perubahan ...
Jika tidak ada yang menyentuh status endstop, maka endstop harus dideteksi sebagai ditekan hanya dengan satu panggilan ke update () dari stepper ISR

aa92022 (# 12158)

Ini tidak benar, tetapi kode sebelumnya juga salah.
Jika kita menghapus live_state, dan kita telah mengaktifkan FILTER_THRESHOLD, maka panggilan ke update () dari ISR ​​stepper tidak akan pernah membatalkan pemindahan.

Alasannya, seperti yang Anda nyatakan (dan Anda benar) adalah bahwa tidak akan pernah ada interupsi perubahan endstop, jadi tidak ada cukup panggilan untuk diperbarui untuk mencerminkan perubahan status endstop, dan gerakan tidak akan pernah dibatalkan

Haruskah itu hanya menghapus hit_state , atau tidak menghapus salah satu negara bagian itu?

Alasan membersihkan keduanya, saya kira adalah untuk memungkinkan "jendela waktu" dengan hit_state = 0
Karena, jika Anda tidak membersihkan valid_state, segera setelah Anda memanggil update (), hit_state akan disetel ke endstop yang dipicu

Saya melihat. Yah kita sebut hit_on_purpose ketika kita benar-benar peduli tentang membersihkan hit_state . Jadi saya kira urutan yang kita sebut not_homing dan hit_on_purpose itu penting.

Namun yang pasti ini tidak benar. valid_state dan endstop_poll_count tidak boleh disentuh, karena itu mengganggu penundaan filter

Saya setuju dengan bagian itu. Jadi, satu-satunya pertanyaan, apakah kita harus "memalsukan" interupsi dan memulai penghitungan polling setiap kali mengaktifkan kembali penghentian sehingga akan memulai proses validasi?

Persis! ,, Urutannya cukup penting - Anda harus memanggil hit_on_purpose () jika Anda yakin endstop TIDAK terpicu - Di saat yang tepat dalam proses kalibrasi

Anda tidak perlu memalsukan interupsi. Cukup menyetel endstop_poll_count ke FILTER_THRESHOLD sudah cukup.

Tetapi jika Anda tidak menyentuh live_state, itu tidak diperlukan (karena valid_state sudah berisi status yang valid, dan tidak perlu menunggu untuk mendeteksi penghentian lagi)

Komentar ini

  // Still 'enabled'? Then endstops are always on and kept in sync.
  // Otherwise reset 'live's variables to let axes move in both directions. 

Berarti mengubah dapat merusak bagian kode yang seharusnya diperbaiki. Saya tidak ingat pernah menulisnya sendiri ...

Hei hit_on_purpose tidak cukup ... Jika Anda bekerja dengan interupsi diaktifkan dan tidak ada ambang batas dan mengakhiri homing di atas endstop apa yang terjadi? laporan status langsung bahwa sumbu berada di atas penghentian dan jika Anda menjauh darinya live_state tidak pernah diperbarui, jadi apa yang terjadi? Anda hanya bisa bergerak ke satu arah

Jadi pengaturan endstop_poll_count dapat dilakukan di enable() dan enable_globally() jika parameter onoff adalah true . Panggilan ke hit_on_purpose() paling baik dilakukan setelahnya (tetapi dalam praktiknya, saya pikir itu berarti mengacak-acak semua rutinitas yang melakukan gerakan yang mendukung endstop).

Dan kemudian, apakah penghapusan #if ENABLED(ENDSTOP_INTERRUPTS_FEATURE) di aa92022 juga harus dikembalikan, atau apakah itu masih masuk akal?

Kami biasanya hanya membatalkan gerakan jika stepper benar-benar menggerakkan _ ke arah_ endstop yang dipicu.

Dan kemudian, apakah penghapusan #if ENABLED (ENDSTOP_INTERRUPTS_FEATURE) di aa92022 juga harus dikembalikan, atau apakah itu masih masuk akal?

Tolong jangan mengembalikannya ... variabel 'live' perlu disetel ulang setelah homing

@ejtagle komentarnya adalah bagian dari perbaikan saya ... jangan lupa apa yang saya katakan di atas. live_state perlu dibersihkan setelah rumah (atau lebih baik setelah penghentian dinonaktifkan) untuk menghindari masalah.

Jadi setting endstop_poll_count bisa dilakukan di

jika Anda memalsukan variabel, Anda kehilangan tindakan penyaringan

FFS - Bagaimana jika kembali ke metodologi endstop dari 1.1.8?

@ Thinkyhead : Itu masih benar: Mutasi hanya dibatalkan jika melawan endstop.
@GMagician : Masalahnya adalah dual endstop?

Secara pribadi menurut saya pendekatan @ejtagle itu bagus, hanya saja perlu disempurnakan

@ejtagle dengan dual endstop masalahnya pasti ada tetapi variabel status langsung mencegah perpindahan endstop dan jika dibiarkan disetel, saya pikir dapat memberikan masalah juga dengan sakelar tunggal

Saya tahu apa yang sedang terjadi ... Kami membatalkan hanya pada gerakan melawan penghentian, tetapi ada beberapa kasus ketika kami harus melawan penghentian: Ganda penghentian! atau sumbu ganda! ... Anda biasanya membatalkan gerakan melawan sakelar batas jika sakelar batas apa pun terpicu, kecuali saat mengarahkan setiap sumbu secara terpisah ...

Baiklah…

1. Biarkan ENDSTOP_NOISE_THRESHOLD di tempatnya dengan ENDSTOP_INTERRUPTS_FEATURE di # 12373.
2. Mari kita lihat bahwa forceupdate benar-benar berfungsi di semua skenario. Saat ini kodenya terlihat berpotensi salah. (mis., Mungkin seharusnya memanggil update() dan safe_delay() keduanya dalam putaran while .)

Anda tidak perlu memanggil update () ... cukup mengatur endstop_poll_count ke apapun! = 0 akan membuat suhu isr call update () untuk Anda pada 1khz

Maka itu lebih baik. Tapi kemudian, dalam beberapa hal apakah itu tidak seperti tidak menyentuh live_state dan validated_live_state pada awalnya?

Tapi, @thinkyhead , saya tidak yakin apakah mengatur live_state ke 0 adalah hal yang benar untuk dilakukan. "Jendela waktu" yang terbuka tampaknya lebih seperti solusi daripada perbaikan yang tepat.

Saya mengubah forceupdate ... sekarang saya memanggil update dulu dan kemudian saya lakukan sambil menelepon safe_delay

Menyetel live_state ke 0 memberikan FILTER_THRESHOLD milidetik tanpa penghentian yang dipicu. Dan kodenya entah bagaimana bergantung padanya untuk bekerja ...: O

Nah, idenya ada hanya untuk membiarkannya disegarkan nanti, pada pengaktifan berikutnya dari penghentian.

Saya mengaturnya ke 0 ketika pemeriksaan endstop dinonaktifkan .. dan karena dinonaktifkan, variabel tidak diperbarui lagi atau poll_count diperbarui

Tidak begitu. Lihat update() . Maksud saya, menyetel poll_count ke 0 akan mencegah pembaruan selama statusnya tetap sama. Tetapi kode validasi memang terjadi.

"buruk" Saya membuat perubahan yang salah ... idenya adalah memanggil pembaruan untuk memulai mesin filter dan kemudian menunggu hingga berlalu

(mengedit komentar saya sebelumnya)

Pastinya adalah jendela waktu tanpa penghentian (saya tidak khawatir tentang 5 milidetik, itu bukan intinya) - Ada sesuatu di kode homing yang tidak menunggu dalam urutan yang benar ...

Saya juga menghapus panggilan pembaruan dari stepper karena dengan modifikasi ini, penghentian diperbarui dengan benar dan seharusnya tidak perlu memanggilnya saat memulai gerakan

Apakah kami menentukan bahwa masalah mendasar adalah karena tidak ada interupsi yang dihasilkan, tidak ada waktu setelah mengaktifkan penghentian bahwa status akan diperbarui?

Nah untuk mencegah adanya masalah endstop filtering, saat aktif, harus selalu berfungsi meski tidak diperlukan. Atau jika pemeriksaan filter dinonaktifkan, saat Anda mengaktifkannya kembali, Anda masih harus menunggu hingga sinkronisasi ulang dengan benar

Itulah alasannya: panggilan sepi ke update () dari stepper ISR tidak cukup untuk mendeteksi penghentian jika FILTER_THRESHOLD diaktifkan dan juga menggunakan ENDSTOP_INTERRUPTS

… Jika demikian, maka cukup dengan mengatur jumlah polling ke beberapa angka saat mengaktifkan endstops / probe akan memungkinkan pembaruan untuk dimulai.

ya, tetapi Anda tidak dapat melakukan apa pun yang menjaga status diperbarui ketika Anda telah menjualnya. memalsukan poll_count tidak ada pilihan yang baik karena Anda merusak tindakan filter

Ya @rambutbuka . menyetel endstop_poll_count ke FILTER_THRESHOLD memastikan status akan diperbarui. Tetapi perhatikan bahwa mungkin bisa merusak perbaikan @GMagician .

karena kode sekarang menyetel jendela waktu _infinite_ tanpa penghentian hingga panggilan ke

Layak untuk dicoba, dan menurut saya itu juga benar untuk menyetel live_state / validated_live_state menjadi 0 dalam not_homing .

maaf untuk posting terakhir saya..tidak jelas ... memalsukan poll_count itu seperti tidak mempunyai filter sama sekali (atau bisa dikatakan anda menganggap status anda salah)

Ini patut dicoba, dan menurut saya itu juga benar untuk mengatur live_state / validated_live_state ke 0 di not_homing.

jika Anda ingin menyelesaikan "gerakan hanya satu arah" setelah pulang

Pada dasarnya, saya tidak yakin apakah ini akan berfungsi sama sekali ketika FILTER_THRESHOLD dinonaktifkan

Karena…

  #if !ENDSTOP_NOISE_THRESHOLD
    if (!abort_enabled()) return;
  #endif

itu bekerja itu bekerja dan pasti kode asli tidak

@ejtagle silakan periksa apa yang terjadi tanpa mengaktifkan tiga kali lipat dan interupsi ketika Anda mengakhiri rumah dengan menekan endstop. variabel hidup diatur kan? ok apa yang terjadi jika setelah rumah Anda pindah endstops ..... variabel langsung masih disetel
tetapi karena stepper isr periksa variabel-variabel ini untuk memblokir gerakan ... Anda tidak akan pernah bergerak ke arah lain (melawan penghentian)

Nah, mari kita ambil elemen terbaik dari apa yang kita diskusikan dan gabungkan ke # 12373, dan pastikan kita memahami semua jalur kode potensial yang dapat diambil. Ingat bahwa dalam implementasi kami saat ini, satu-satunya hal yang dilakukan oleh interupsi endstop adalah menghitung jumlah polling.

Tidak membantah @GMagician itu . Masalahnya nyata. Tidak diragukan lagi. Hanya saja menambahkan solusi tambahan membuat kode (sekali lagi) sangat sulit untuk dipertahankan. Anda sengaja memperkenalkan kondisi balapan atau "penonaktifan sementara" dari penghentian untuk menyelesaikan masalah. Mungkin itu keputusan yang tepat, mungkin pendekatan yang lebih baik adalah menemukan akar masalahnya ...

Tidak ada kondisi balapan karena status penghentian tidak diperbarui saat dinonaktifkan. dan forceupdate tunggu saja sampai tindakan filter selesai. Satu-satunya masalah adalah jika kebisingan adalah cointinuos. jika akan menggantung menunggu stabilisasi

Ups, salahku. Interupsi endstop sepertinya hanya memanggil endstops.update .

Tidak ada kondisi balapan karena status penghentian tidak diperbarui saat dinonaktifkan.

Tidak begitu. Status live terus diperbarui saat ambang batas diaktifkan.

@ Thinkyhead mereka tidak diperbarui saat interupsi diaktifkan dan penjualan tidak

Ya @rambutbuka . Tetapi memanggil update () sudah cukup, karena endstop dibaca, dan endstop_poll_count akan disetel ke FILTER_THRESHOLD, karena ada perubahan;)

Bukan kondisi ras dalam "pengertian tradisional". Tidak ada bahaya pembaruan variabel. Ini adalah kondisi balapan antara utas utama dan panggilan ISR suhu ke update ()

Oke, saya mengerti apa yang Anda berdua katakan.

variabel langsung tidak boleh disetel ulang saat penjualan aktif

Untuk membuatnya sejelas mungkin: @GMagician membuka "jendela waktu tanpa penghentian" dan beberapa kode (prosedur homing) harus diselesaikan sebelum "jendela waktu" itu ditutup. Saya tidak tahu apa, mungkin bagian dari proses homing

Apakah Anda mengacu pada perubahan # 12373?

jendela waktu tanpa henti

kode apa ini? Saya kehilangan diri saya tentang apa masalah perbaikan sebelumnya dan masalah saat ini ... maaf tapi sulit karena bahasa Inggris bukan bahasa saya

Ya ... Ada alasan untuk panggilan itu ke update () di dalam stepper - saya akan menjadi orang yang paling bahagia jika panggilan itu dapat dihapus (lebih sedikit waktu di stepper)

Tetapi saya tidak menemukan alasan untuk panggilan itu sekarang (dan saya tidak dapat mengingat alasan aslinya). Itu adalah sesuatu yang berhubungan dengan homing, mungkin - Saya tahu pemblokiran tidak akan langsung dibatalkan tanpa panggilan itu, tetapi pada akhirnya mereka akan melakukannya, jadi seharusnya berfungsi.

@GMagician : Menyetel ulang status filter tidak boleh dilakukan. Itu adalah filter. Anda tidak ingin membayar penalti waktu pendeteksian ulang status - Alasan Anda melakukan pengaturan ulang adalah karena Anda mendapatkan "tidak ada deteksi endstop" selama 5 milidetik atau lebih. Itu mungkin memungkinkan untuk mengantrekan gerakan baru dan mulai menjalankannya, dan dengan demikian mengubah status endstop menjadi tidak ditekan

Dan itulah kondisi balapan yang saya bicarakan: Anda perlu mengantri dan mulai mengeksekusi pada waktu itu, atau perbaikan tidak akan berhasil

panggilan di stepper diperlukan karena interupsi tidak dipicu saat Anda masih di atas endstop. tapi kenapa status tidak diupdate? karena Anda dapat menonaktifkan endstop diaktifkan setelah rumah. Kemudian jika status dipulihkan ketika Anda mengaktifkannya kembali maka tidak perlu panggilan seperti itu

jika status dipulihkan saat Anda mengaktifkannya kembali maka tidak perlu panggilan seperti itu

Benar. Tentu saja perhatikan bahwa panggilan ke update terjadi hanya ketika blok berikutnya diambil, jadi tidak apa-apa selama penghentian diaktifkan dan update siap digunakan sebelum merencanakan gerakan homing.

Jadi apa yang ditinggalkan untuk kita? Apakah kami melihat kekurangan dengan…

• pendekatan umum kami untuk penanganan endstop?
• not_homing pengaturan [validated_]live_state menjadi 0 yang mematahkan update ?
• not_homing pengaturan endstop_poll_count menjadi 0 yang merusak update ?
• panggilan ke update dari stepper ISR? <- Sepertinya tidak dibutuhkan…
• enabled dan enable_globally perlu menelepon update (atau forceupdate )?
• interupsi endstop gagal menyetel endstop_poll_count dan hanya memanggil update ?

Apakah ini cukup…?

void Endstops::force_update() {
  #if ENDSTOP_NOISE_THRESHOLD
    endstop_poll_count = 1; // get current state now
  #endif
  update();
}

`` cpp
void endstop_ISR (void) {endstops.force_update (); }

```cpp
void Endstops::enable(const bool onoff) {
  enabled = onoff;
  forceupdate();
}

void Endstops::enable_globally(const bool onoff) {
  enabled_globally = enabled = onoff;
  forceupdate();
}

not_homing menyetel live_state ke 0 yang merusak pembaruan?

setelah homing, jika endstop tidak terus beroperasi, wajib jika tidak, Anda hanya dapat bergerak satu arah

not_homing menyetel endstop_poll_count ke 0 yang merusak pembaruan?

sama seperti sebelumnya, untuk reset tinggal jika harus diset ke 0

panggilan untuk memperbarui dari stepper ISR? <- Sepertinya tidak dibutuhkan…

benar jika Anda yakin untuk terus memperbarui endstop sebelum mulai bergerak

enabled dan enable_globally perlu memanggil update (atau forceupdate)?

ya jika Anda ingin memastikan endstop diperbarui dengan benar setelah pembaruan dihentikan

@bayu_joo
1) Pendekatan umum benar
2) Penonaktifan polling endstop saat endstop dinonaktifkan, tetapi prosedur "bangun" perlu disetel. Kita mungkin kehilangan interupsi dalam prosesnya, jadi kita harus menyetel endstops_poll_count ke nilai yang masuk akal saat bangun
3) Sesuatu yang aneh dengan kebutuhan untuk mengatur live_state ke 0. Mungkin prosedur homing, mungkin pengaturan sumbu ganda yang tidak dapat memindahkan sumbu ke-2 ketika min endstop dipicu?
4) menyetel endstop_poll_count ke 0 berarti tidak ada deteksi endstop hingga perubahan sakelar berikutnya (hanya ISR yang dapat memanggil pembaruan dan memuat ulang endstop_poll_count): Itu adalah jendela "tanpa penghentian" yang saya bicarakan
Panggilan ke stepper.update () diperlukan untuk masalah yang sama: Tidak ada ISR, tidak ada pembaruan penghentian, tidak ada pembatalan pemblokiran.

Aku akan mengatakan:
force_update () harus menyetel endstop_poll_count ke FILTER_THRESHOLD
endstop_ISR hanya perlu memanggil update () (
perubahan ke enable_globally () tidak masalah

Sesuatu yang aneh dengan kebutuhan untuk menyetel live_state ke 0.

Nah, kita harus bisa mengizinkan endstop untuk selalu aktif, namun tetap bisa menjauh dari endstop yang dipicu.

Tapi @GMagician tetap harus menguji apakah itu menyelesaikan masalah.
Mungkin panggilan ke update () di stepper bisa dihilangkan dengan perubahan ini, karena kita force_updating sebelum pindah

Sesuatu yang aneh dengan kebutuhan untuk menyetel live_state ke 0.

Nah, kita harus bisa mengizinkan endstop untuk selalu aktif, namun tetap bisa menjauh dari endstop yang dipicu.

Sudah selesai. Anda selalu dapat bergerak ke arah berlawanan dari sebuah endstop, tetapi prosedur homing dari sumbu ganda membutuhkan perilaku yang berbeda

… Dan saya pikir idenya adalah bahwa kami tidak ingin terjadi interupsi endstop namun masih mengalami fall-through validated_live_state , yang menyebabkan pemindahan dibatalkan.

Nah, dengan penghentian ganda, saya yakin kami memperlakukan kedua sakelar sebagai satu bit di hit_state .

@pak_makassar Dan itu TIDAK berhasil untuk homing!

Itulah masalahnya! - Untuk operasi normal, SETIAP endstop pasangan harus membatalkan gerakan!
Tetapi di homing, ini tidak benar: Kita harus dapat memindahkan sumbu lain, bahkan jika salah satu penghenti terpicu!

Bukankah kita punya bendera untuk mengabaikan salah satu pasangan? Saya pikir kami telah menyelesaikannya.

@thinkyhead hit_state tidak cukup untuk membiarkan motor bergerak .. live state digunakan untuk mencegah penyetelan pin step

Saya melihat. Kami menetapkan hit_state sebagai bagian dari pembatalan pemindahan.

ya, tetapi live_state mencegah gerakan lebih lanjut dengan memblokir pin fisik

Betulkah? Saya pikir kami hanya membatalkan dan membuang blok saat ini.

Ada fungsi stepper.set_separate_multi_axis () yang harus digunakan untuk menghindari pemblokiran semacam ini
Dan itu digunakan untuk Lihat itu di DUAL_ENDSTOP_APPLY_STEP ()

Tapi, mungkin, masalahnya adalah kondisi itu sendiri ... atau fungsi stepper.set_separate_multi_axis () tidak dipanggil pada saat yang tepat

Saya pikir kita baru saja berurusan dengan masalah umum G28 satu-endstop sekarang.

Oke, lihat apakah pendekatan yang dimodifikasi yang saya kirimkan ke # 12373 berfungsi. Dan mungkin itu juga menghilangkan kebutuhan untuk menyetel live_state , validated_live_state , dan endstop_poll_count dalam not_homing .

Ini tidak akan berfungsi ... live_state disetel karena setelah home endstops ditekan (dan ini benar). Jadi kalau tidak dipaksakan ke 0 .... satu arah saja

Jika penghentian dimatikan, tidak ada penyumbatan gerakan, benar?
Jika nilainya dihapus sebelum penghentian diaktifkan, maka itu sama saja, bukan?

Dan jika penghentian selalu aktif, lalu…?

Dan… bagaimana dengan ini? Hanya hubungi force_update jika belum diaktifkan:

void Endstops::enable(const bool onoff) {
  if (onoff && !enabled) force_update();
  enabled = onoff;
}

… Ditambah pemberitahuan itu memanggil force_update sebelum mengaktifkannya. Itu akan mencegah planner.endstop_triggered dipanggil segera, karena itu seharusnya hanya dipanggil setelah langkah berikutnya dimulai.

Mungkin saya terlalu memikirkannya, tetapi saya rasa ini bisa terjadi.

Sekarang saya harus pergi dan tidak dapat membantu tetapi ketika Anda mematikan penghentian saat mereka terlibat live_state adalah! = 0 jadi Anda jika Anda meminta mereka untuk memperbarui status (dan Anda harus memblokir pembaruan live_state jika tidak Anda dengan endstops alwyas pada) Anda hanya akan bergerak satu arah karena, saya mungkin bekerja tetapi makro WRITE menggunakan live_state, itu mencegah bergerak

ketika Anda mematikan penghentian saat mereka terlibat live_state! = 0 jadi Anda jika Anda [mencegah] mereka untuk memperbarui status

• Jika ENDSTOP_NOISE_THRESHOLD tidak diaktifkan, penghentian tidak akan diuji saat mati.
• Saat ENDSTOP_NOISE_THRESHOLD diaktifkan, live_state selalu diperbarui, bahkan saat mati.

saya mungkin [salah] tetapi makro WRITE menggunakan live_state, itu mencegah perpindahan

Saya tidak yakin di mana ini seharusnya. Pemicu endstop membunuh blok saat ini, tetapi tidak menonaktifkan gerakan dengan cara level rendah (yang dapat saya pikirkan saat ini).

@thinkyhead Saya akan mencoba menjelaskan lagi ... mengapa Anda tidak mengerti bahasa Italia atau saya menulis bahasa Inggris yang lebih baik ?, sangat sulit untuk mentransfer detail seperti itu ... ;-)

Saat Anda menghentikan homing, Anda menekan endstop (dalam sumbu ganda mungkin hanya satu), ini memberi Anda set live_state (dan ini benar).
Setelah rumah dihentikan, Anda menonaktifkan pemeriksaan penghentian sehingga live_state mempertahankan nilai lamanya, perhatikan bahwa saat ambang aktif, Anda terus memperbarui live_state tetapi menyalin nilai tersebut ke yang lain setelah waktu filter, tetapi ini tidak mengubah apa pun, motor masih dihentikan dengan penghentian aktif jadi live_status atau saudaranya disetel. Setelah pemeriksaan endstops dinonaktifkan dengan status live 'not_homing' tidak pernah diperbarui lagi tetapi ingat, mereka disetel !!!!
Hal apa yang akan terjadi dengan ini:
DUAL_ENDSTOP_APPLY_STEP

ketika Anda menjauh dari endstop (live_state akan tetap disetel) dan kemudian Anda mencoba untuk bergerak melawan endstop?

Masalah @ejtagle hanya untuk sistem endstop ganda karena makro di atas tidak digunakan dengan tunggal

@thinkyhead Saya tidak suka solusi yang Anda usulkan karena memaksa polling ke 1 sebelum pembaruan akan membaca status input saat ini yang hilang oleh fakta tindakan filter

mungkin solusi yang bersih adalah mengembalikan perbaikan saya sebelumnya dan membiarkan state() tidak mengembalikan live_state ketika penghentian tidak perlu diperiksa.

@ejtagle dan @inkyhead

Tapi, mungkin, masalahnya adalah kondisi itu sendiri ... atau fungsi stepper.set_separate_multi_axis () tidak dipanggil pada saat yang tepat

Saya dapat mencoba menggunakan fungsi ini untuk mencegah live_state mengunci stepper ganda setelah homing. Beri saya beberapa jam dan saya akan memposting PR baru dengan proposal solusi ke-2

wow kalian sibuk, jadi. Apa yang harus saya uji jika ada sesuatu untuk Anda?

@GhostlyCrowd apa-apa untuk saat ini ... memberi saya beberapa jam dan saya akan posting PR yang harus mengikuti @ejtagle ide kerja endstop asli, bekerja dengan endstops ganda dan memecahkan masalah Anda

@GMagician : Anda harus mengakui bahwa hal ini aneh: Implementasi makro DUAL_ENDSTOP_APPLY_STEP , jelas melarang melanggar batas _ sakelar terkait_ ... Jadi, seharusnya tidak melarang pergerakan sumbu "kembar" lainnya, jika sakelar batas penghenti akhir terkait tidak ditekan

Jika makro ini mencegah sumbu bergerak, maka separate_multi_axis adalah true ,
Karena solusi Anda tampaknya "memperbaiki" masalah, maka itu bukan locked_motor , jadi, seperti yang Anda katakan, itu harus endstops :: state () mengembalikan true untuk sumbu terkait.

endstops::state() mengembalikan validated_live_state , tetapi pada endstops::update()

 /**
   * Check and update endstops
   */
  #if HAS_X_MIN
    #if ENABLED(X_DUAL_ENDSTOPS)
      UPDATE_ENDSTOP_BIT(X, MIN);
      #if HAS_X2_MIN
        UPDATE_ENDSTOP_BIT(X2, MIN);
      #else
        COPY_LIVE_STATE(X_MIN, X2_MIN);
      #endif
    #else
      UPDATE_ENDSTOP_BIT(X, MIN);
    #endif
  #endif 

Jelas bahwa ada 2 bit independen, satu untuk setiap bit endstop ... Jadi pergerakan tidak boleh dibatalkan ...

Tapi, ada kemungkinan semua ini bisa gagal: Ini adalah bug dari prosedur homing.

Untuk sesaat, anggaplah KEDUA tombol endstop ditekan (X1_MIN dan X2_MIN)

Fungsi homeaxis() melakukan hal berikut:
1) Kami memindahkan sumbu X1 terhadap saklar penghenti X1
2) Sakelar sudah ditekan, jadi gerakan pertama langsung dibatalkan.
3) Sumbu kedua digerakkan melawan batas endstop, dan saat ditekan, gerakan segera dibatalkan.

Tidak ada tonjolan untuk sumbu ganda ...

Saya tidak mengerti mengapa, tapi prosedur pelacak untuk sumbu ganda ini cacat. Rasanya tidak benar. Prosedurnya harus:

1) Jika endstop sudah ditekan, lakukan gerakan yang sangat kecil untuk melepaskan sakelar endstop. 2mm tampaknya masuk akal - Tunggu sampai endstop SEBENARNYA dilepaskan
2) Lakukan gerakan ke arah endstop - Tunggu hingga endstop mencapai dan gerakan dibatalkan
3) (Tonjolan optik) Lakukan lagi gerakan kecil untuk melepaskan penghenti akhir - Tunggu hingga benar-benar IS dilepaskan
4) (Tonjolan optik) Lakukan lagi gerakan yang lebih lambat ke arah penghentian akhir untuk menekan sakelar penghentian (dengan kecepatan yang lebih lambat) hingga penghenti akhir ditekan.

Ini harus dilakukan untuk SEMUA sumbu.
Tetapi langkah (1) yang sangat penting, hilang !! - Dapatkah @thinkyhead atau @GMagician menjelaskan mengapa langkah yang sangat penting ini hilang dari prosedur homing? ... Saya pikir langkah yang terlewat adalah penyebab dari semua masalah dan solusi yang diusulkan di sini !!

(Dan ada alasan untuk perlunya langkah yang hilang itu (1) ... Ketika sumbu menekan endstop, bisa jadi, karena kegagalan fungsi gerakan sebelumnya, sumbu memaksa endstop. Memiliki saklar penghenti ditekan tidak cukup untuk memastikan bahwa sumbu berada di posisi awal yang tepat. Jadi, langkah bersyarat ekstra di awal adalah HARUS - Kami ingin prosedur yang sesuai untuk transisi sakelar endstop - Itulah trik untuk presisi maksimum

Bahkan, ada pengoptimalan di sini: Jika langkah (1) diterapkan, dan benjolan diaktifkan, tidak perlu menjalankan langkah (2) dan (3)

@ejtagle masalahnya bukan selama di rumah, fase itu bekerja dengan benar, adalah setelahnya.
Saya pikir ketika Anda menyatakan separate_multi_axis dibiarkan benar setelah homing dan di sini mengangkat masalah. Saya ingin mengatur ulang setelah homing, mengembalikan kode ke # 11900 sebelumnya dan melihat apa yang terjadi

@ejtagle dan @thinkyhead beri saya kesempatan, saya akan segera memposting PR yang memperbaiki dual enstops reverting # 11900 dan modifikasi seperti itu juga harus memperbaiki masalah ini .. kemudian mari kita bahas tentang solusi tersebut

Saya telah menggabungkan # 12382, karena sangat elegan dan memperbaiki pengawasan 💩 separate_multi_axis wtf kami.

Saya telah menarik dan menyusun ini. Ini memecahkan masalah saya dengan sempurna. Saya akan melanjutkan dan menutup ini.

Terima kasih atas laporannya, @GhostlyCrowd. Ini adalah kesempatan yang baik bagi kami untuk meninjau kode endstop / probe, terlalu membiasakan diri dengannya, dan menyelesaikan apa yang pasti akan menjadi masalah yang menjengkelkan bagi banyak orang.

Terima kasih kepada semua orang yang berpartisipasi, saya membaca setiap komentar. Saya belajar beberapa hal di sepanjang jalan.

Masalah ini telah dikunci secara otomatis karena tidak ada aktivitas baru-baru ini setelah ditutup. Silakan buka masalah baru untuk bug terkait.