Bug sesekali, tetapi prioritas tinggi

Saya sedang mengerjakan proyek CNC (kontrol numerik komputer) yang memotong bentuk menjadi logam dengan bantuan laser.

Sekarang masalah saya adalah sesekali (1-2 kali dalam 20 hari ganjil) pemotongan salah atau tidak sesuai dengan apa yang ditetapkan.

Tetapi ini menyebabkan kerugian sehingga klien tidak terlalu senang karenanya.

Saya mencoba mencari tahu penyebabnya

1. Termasuk file log
2. Debugging
3. Mengulangi lingkungan yang sama.

Tapi itu tidak akan diulang.

Jeda dan melanjutkan operasi lagi akan membuatnya berjalan lancar tanpa bug muncul kembali.

Bagaimana cara mengatasi masalah ini? Haruskah saya menyatakannya sebagai Masalah Perangkat Keras?

Bekerja di sekitar

Seperti yang disarankan ChrisF , solusi jangka pendek pragmatis mungkin adalah dengan menggunakan jeda dan melanjutkan trik, tetapi Anda harus berbicara dengan pelanggan Anda untuk mengetahui apa yang seharusnya menjadi prioritas Anda. Sebagai contoh:

• Jika kesalahan merusak bagian £ 1000 atau menyebabkan 4 jam downtime sekali seminggu, sementara perbaikan jeda-mengurangi produksi sebesar 1%, mereka mungkin akan lebih memilih memperbaiki sekarang.

• Jika kesalahan merusak bagian £ 1 atau menyebabkan downtime 4 menit sekali seminggu, tetapi perbaikan jeda-mengurangi produksi sebesar 1%, mereka mungkin akan lebih memilih untuk menunggu perbaikan yang tidak mempengaruhi tingkat produksi.

Setelah bekerja di industri mesin mikro-laser selama bertahun-tahun, saya tahu seberapa besar tekanan yang Anda dapat untuk mengoptimalkan proses dan membuat mesin Anda memproduksi sebanyak mungkin komponen per jam, jadi Anda akan berada di bawah tekanan untuk memperbaiki masalah dengan benar.

Penebangan

Dalam pengalaman saya, satu-satunya cara untuk melacak Heisenbug secara efektif adalah penebangan yang berlebihan. Log segala sesuatu di dalam dan sekitar bagian kode yang dapat bertanggung jawab atas kesalahan. Pelajari cara membaca file log Anda secara efektif, pastikan Anda memantau kesalahan berikut pada motor Anda (apakah tahapan Anda bergerak ke mana seharusnya ketika seharusnya?). Lihatlah penggunaan memori pada mesin, apakah kebocoran memori menyebabkan proses kritis menjadi kelaparan?

Pastikan Anda mencatat tindakan pengguna juga, apakah Anda yakin bahwa operator tidak memukul berhenti darurat sehingga mereka dapat keluar untuk istirahat rokok sembarangan saat sedang diperbaiki? Saya telah melihat ini terjadi!

Analisis statis

Juga, cari korelasi antara menulis pola-pola tertentu dan bug yang dipicu lebih atau kurang sering. Jika Anda dapat menemukan pola yang lebih sering memicu masalah (atau tidak pernah memicunya), ini mungkin mengarah ke masalah Anda.

Cobalah untuk membuat pola yang memicu masalah bahkan lebih sering. Jika Anda dapat menemukan cara untuk memicu masalah dengan andal maka Anda setengah jalan menuju solusi.

Pilihan lain

Akhirnya, jangan cepat menyalahkan perangkat keras, tetapi jangan pernah berasumsi bahwa itu sempurna. Sering kali saya dipersalahkan atas masalah yang ternyata bersifat listrik atau mekanis, jadi Anda harus selalu mengingatnya.

Meskipun Anda biasanya tidak memiliki akses ke mesin, ingatlah bahwa beberapa masalah hanya dapat diselesaikan secara efisien pada mesin. Kadang-kadang beberapa hari di tempat dapat bernilai berminggu-minggu melalui remote desktop dan berbulan-bulan off-line sepenuhnya. Jika Anda kehabisan opsi offline, jangan takut untuk mengusulkan kunjungan situs, mereka hanya bisa mengatakan tidak.

Anda mungkin juga ingin melihat pertanyaan dan jawaban untuk Apa yang Anda lakukan dengan heisenbug? dan Apa yang harus dilakukan dengan bug yang tidak repro? tetapi ini mungkin tidak begitu berguna untuk situasi Anda.

Saya akan membuat saran di luar tembok.

Pergi ke manajer pabrik dan minta untuk melihat catatan monitor saluran listrik untuk alat itu, atau daerah itu, untuk saat-saat ketika malfungsi terjadi. Juga tanyakan padanya apakah ada pengelasan, atau kegiatan tidak biasa lainnya, di sekitar waktu itu.

Beberapa dekade yang lalu, ayah saya bersenang-senang dengan komputer mini yang mogok tanpa alasan sama sekali. Mereka memanggil perwakilan pelanggan pabrikan.

Perwakilan itu datang ke kantor mereka, di area pabrik, dan memasang voltmeter ke dinding, di sebelah mini, dan kemudian berkata "Lihat ini."

Beberapa menit kemudian, voltmeter tiba-tiba merosot, secara signifikan, lalu kembali. Perwakilan itu berkata, "Itu dia yang memukul busur tesnya. Tunggu sebentar." Tak lama setelah itu, voltmeter merosot lagi, dan kali ini ia tetap merosot.

Perwakilan itu berkata, "Itu masalah Anda. Anda punya orang yang sedang mengelas di lantai pabrik, dan Anda memiliki kekuatan yang sama dengan Anda. Saya melihatnya berdiri ketika saya sedang berjalan masuk."

Mereka harus menjalankan pasokan daya yang benar-benar terpisah ke kantor.

Masalahnya adalah masalah nyata dengan konsekuensi nyata bagi pengguna - yaitu pekerjaan yang hancur dll. Sehingga perlu diperbaiki. Namun, itu tidak harus diperbaiki "dengan benar". Anda menyatakan:

Jeda dan melanjutkan operasi akan membuatnya berjalan kembali dengan bug muncul kembali.

Dalam hal ini lakukan saja ini. Pelanggan akan senang bahwa mereka tidak menyia-nyiakan material pada proses yang rusak bahkan jika proses normal membutuhkan waktu beberapa detik lebih lama.

Jelas dalam jangka panjang Anda mungkin perlu memperbaiki ini dengan "benar" tetapi untuk sementara waktu mengurangi kerugian Anda , pergi dengan solusi dan mulai sesuatu yang lain.

Saya memiliki bug dalam permainan yang terjadi hanya 1 kali dalam satu miliar. Untungnya ini berarti saya melihatnya setiap 15 hingga 30 menit, tetapi melangkah melalui kode di debugger tidak akan berhasil. Saya akhirnya memasukkan pesan debug. Mereka perlu menggunakan pernyataan if mewah karena saya hanya menginginkan sesuatu ketika ada masalah. Dalam kebanyakan kasus, kode debug mengulangi perhitungan dalam kode biasa tetapi menggunakan teknik yang berbeda. Pengulangan tidak harus tepat. Jika saya tahu angka harus selalu di bawah 10.000 dan sepertinya mencapai 150.000 pada kesempatan, saya hanya akan memeriksa nilai lebih dari 100.000. Setiap kali bug terjadi, saya akan mempelajari hasil saya, menyusun pesan debug yang lebih rumit (atau lebih tepatnya, pemeriksaan yang lebih rumit untuk melihat apakah saya harus menampilkan pesan), dan menunggu masalah muncul lagi.

Siklus Anda akan jauh lebih lama daripada siklus saya, tetapi Anda akhirnya akan menyelesaikan masalahnya. Saya harap Anda dapat menemukan solusinya dengan metode lain yang lebih cepat, tetapi ini akan menangkapnya pada akhirnya jika tidak ada yang lain, dan akan memberi Anda perasaan bahwa Anda sedang melakukan sesuatu sampai Anda mendapatkan ide yang lebih baik.

(Seandainya itu membantu, saya akhirnya memecahkan masalah saya dengan membersihkan beberapa baris kode yang akhirnya saya identifikasi sebagai masalah. Saya bersumpah tidak ada yang salah dengan mereka, tapi saya pikir pengoptimal dan CPU sedang menyusun kembali instruksi untuk kinerja, dan saya pikir sesekali mereka mengambil kesempatan untuk mendapatkan sedikit kecepatan ekstra. Bahkan satu inti multi-proses hari ini, dan saya pikir setiap sekali dalam satu saat register dibaca sebelum ditulis untuk. Saya mengalihkan semua perhitungan agar bekerja dengan variabel lokal. Nilai "Bidang Instance" dipindahkan ke variabel lokal di awal, dan nilai lokal dipindahkan kembali hanya di bagian paling akhir, di dalam blok sinkronisasi. Dan saya menggunakan nilai lokal untuk nilai metode pengembalian daripada "bidang contoh"Saya telah menggunakan.)

Aturan 1 nomor satu dalam debugging: Anda membutuhkan skenario yang dapat direproduksi .

Jika Anda tidak memilikinya, Anda harus mengerjakannya terlebih dahulu. Bisakah Anda mereproduksi bug itu dalam semacam "mode simulasi" mesin, di mana tidak ada logam yang benar-benar dipotong? Ini sepertinya masuk akal di sini. Bisakah Anda menjalankan beberapa program pemotongan berbeda secara cepat dan otomatis, mensimulasikan proses 20 hari dalam beberapa menit? Itu dapat meningkatkan kemungkinan masalah muncul.

Kemudian, ketika Anda memiliki skenario seperti itu, langkah selanjutnya adalah mengumpulkan informasi sebanyak mungkin dan benar-benar mulai melakukan debugging.

Tidak yakin dalam bahasa apa ini dijalankan, tetapi jika saya mengalami bug yang tidak menentu dalam kode saya (C ++), saya akan menggunakan alat seperti valgrind atau cppcheck untuk memastikan tidak ada yang terjadi pada memori-bijaksana.

Perpanjangan jawaban RalphChapin:

Selama bertahun-tahun saya harus berburu sejumlah bug yang hanya menunjukkan diri mereka pada sistem saya tidak bisa menduplikasi karena perangkat keras yang terpasang.

Selain melakukan logging seperti orang gila, satu hal lain yang saya temukan berguna: Menempatkan informasi di layar yang menunjukkan di mana kode itu dan nilai beberapa variabel yang relevan. Ketika masalah muncul, bahkan para pekerja di lantai pabrik dapat membaca saya informasinya.

Biasanya diperlukan beberapa putaran penyempurnaan untuk menjabarkannya dengan tepat tetapi sangat efektif.