Arada bir hata, ancak yüksek öncelik

Lazer yardımıyla şekilleri metale kesen bir CNC (bilgisayar sayısal kontrolü) projesi üzerinde çalışıyorum.

Şimdi benim sorunum arada bir (20 tuhaf günde 1-2 kez) kesme ayarlanmış olana göre yanlış ya da değil gider.

Ancak bu kayba neden olur, bu nedenle müşteri bu konuda çok mutlu değildir.

Bunun nedenini bulmaya çalıştım

1. Günlük dosyaları dahil
2. Hata ayıklama
3. Aynı ortamın tekrarlanması.

Ama tekrar etmeyecek.

Bir duraklatma ve devam etme işlemi, hata tekrar ortaya çıkmadan tekrar sorunsuz çalışmasını sağlayacaktır.

Bu sorunu nasıl çözebilirim? Bir Donanım Sorunu olarak belirtmeli miyim?

Etrafında çalışın

As ChrisF anlaşılacağı, pragmatik kısa vadeli çözüm kullanmak olabilir duraklama ve özgeçmiş hile, ancak önceliklerinin ne olması gerektiğini bilmek müşterilerinize konuşmak zorundayız. Örneğin:

• Arıza 1000 sterlinlik bir parçayı çöker veya haftada bir kez 4 saatlik kesinti süresine neden olurken, duraklatma-devam düzeltmesi üretimi% 1 azaltırken, muhtemelen şu anda düzeltmeyi tercih edeceklerdir.

• Arıza haftada bir kez 1 £ parça çöker veya 4 dakika kesinti süresine neden olur, ancak duraklatma-devam düzeltmesi üretimi% 1 azaltırsa, muhtemelen üretim oranını etkilemeyen bir düzeltme beklemeyi tercih ederler.

Lazer mikro işleme endüstrisinde yıllarca çalıştıktan sonra, süreci optimize etmek ve makinenizin saatte mümkün olduğunca çok parça üretmesini sağlamak için ne kadar basınç altında olabileceğinizi biliyorum, böylece her iki şekilde de sorunu düzeltmek için basınç.

Kerestecilik

Deneyimlerime göre, bir Heisenbug'u etkili bir şekilde izlemenin tek yolu bol günlük kaydıdır . Hatadan sorumlu olabilecek kodun içinde ve çevresinde her şeyi günlüğe kaydedin. Günlük dosyalarınızı etkili bir şekilde nasıl okuyacağınızı öğrenin , motorlarınızda aşağıdaki hatayı izlediğinizden emin olun (aşamalarınız olması gerektiği yerde hareket ediyor mu?). Makinedeki bellek kullanımına bakın, kritik bir sürecin aç kalmasına neden olan bir bellek sızıntısı mı?

Kullanıcı işlemlerini de günlüğe kaydettiğinizden emin olun, operatörün, acil durum durağına çarpmadığından emin misiniz, böylece tamir edilirken sigarayı bırakmak için mola verebilirler mi? Bunun olduğunu gördüm!

Statik analiz

Ayrıca, belirli kalıpları çizmekle az ya da çok tetiklenen hata arasındaki korelasyonları arayın. Sorunu daha sık tetikleyen (veya hiç tetiklemeyen) desenler bulabilirseniz, bunlar sorununuzu gösterebilir.

Sorunu daha sık tetikleyen desenler yapmaya çalışın . Sorunu güvenilir bir şekilde tetiklemenin bir yolunu bulabilirseniz, bir çözüme giden yolun yarısı vardır.

Diğer seçenekler

Son olarak, donanımı suçlamak için hızlı olmayın, ancak asla mükemmel olduğunu varsaymayın. Birçok kez doğada elektriksel veya mekanik olduğu ortaya çıkan sorunlardan dolayı suçlandım, bu yüzden her zaman zihninizin arkasında olmalısınız.

Normalde makineye erişiminiz olmayabilir, ancak bazı sorunların yalnızca makinede verimli bir şekilde çözülebileceğini unutmayın. Bazen yerinde birkaç gün uzak masaüstü ve hafta tamamen çevrimdışı aracılığıyla haftalara değer olabilir. Çevrimdışı seçenekleriniz biterse, site ziyareti teklif etmekten korkmayın, sadece hayır diyebilirler.

Ayrıca , bir heisenbug ile ne yapıyorsunuz? ve üremeyen böceklerle ne yapmalı? ancak bunlar durumunuz için çok yararlı olmayabilir.

Duvardan bir öneri sunacağım.

Fabrika yöneticisine gidin ve arızaların meydana geldiği zamanlar için o aracın veya o alanın güç hattı monitör kayıtlarını görmenizi isteyin. Ayrıca ona o zamanlarda kaynak veya başka bir olağan dışı etkinlik olup olmadığını sorun.

Birkaç on yıl önce, babam hiçbir sebepten ötürü çökmekte olan bir mini bilgisayarla çok cehennem yaşıyordu. Üreticinin müşteri temsilcisini aradılar.

Temsilci fabrika alanına ofisine geldi ve mini'nin yanındaki duvara bir voltmetre taktı ve sonra "Bunu izle" dedi.

Birkaç dakika sonra voltmetre aniden sarktı, önemli ölçüde geri döndü. Temsilci, "Bu test yayına çarpıyordu. Bir dakika." Bundan kısa bir süre sonra voltmetre tekrar sarktı ve bu kez sarkık kaldı.

Temsilci, "Bu senin sorunun. Fabrikada kaynak yapan bir adam var ve seninle aynı güç bacağında. Ben yürürken onu kururken gördüm."

Ofise tamamen ayrı bir güç beslemesi yapmak zorunda kaldılar.

Sorun, kullanıcı için gerçek sonuçları olan gerçek bir sorundur - yani yıkılmış iş vb. Ancak, "düzgün" olarak düzeltilmesi gerekmez. Siz belirtiniz:

Bir duraklatma ve devam etme işlemi, hata tekrar ortaya çıktığında tekrar düzgün çalışmasını sağlayacaktır.

Bu durumda sadece bunu yapın. Müşteri, normal çalışmalar birkaç saniye daha uzun sürse bile kusurlu çalışmalarda malzeme israf etmemesinden memnun olacaktır.

Açıkçası uzun vadede bu "düzgün" düzeltmek ama varlık kesmek süre gerekebilir senin kayıpları, geçici çözüm gidip başka bir şey üzerine olsun.

Bir milyarda sadece 1 kez olan bir oyunda bir hata yaşadım. Neyse ki bu, her 15 ila 30 dakikada bir gördüğüm anlamına geliyordu, ancak hata ayıklayıcıdaki koddan geçmek işe yaramayacaktı. Sonunda hata ayıklama iletileri koydum. Onlar sadece bir sorun olduğunda bir şey istedim çünkü fantezi if-ifadeleri kullanmak gerekiyordu. Çoğu durumda hata ayıklama kodu, normal kodda ancak farklı teknikler kullanarak hesaplamaları tekrar ediyordu. Tekrarların kesin olması gerekmiyordu. Bir sayının her zaman 10.000'in altında olması gerektiğini bilseydim ve zaman zaman 150.000'i vurdu gibi görünüyorsa, sadece 100.000'in üzerinde bir değer olup olmadığını kontrol ederdim. Hata her ortaya çıktığında, sonuçlarımı inceledim, daha ayrıntılı hata ayıklama iletileri tasarladım (veya daha kesin olarak, bir ileti görüntülemem gerekip gerekmediğini görmek için daha ayrıntılı kontroller) ve sorunun tekrar ortaya çıkmasını beklerdim.

Döngüleriniz benimkinden çok daha uzun olacak, ama sonunda sorunu kapatacaksınız. Umarım çözümü başka, daha hızlı bir yöntemle bulabilirsin, ama sonuçta başka bir şey yapmazsa bu onu yakalayacak ve daha iyi bir fikir bulana kadar bir şey yaptığına dair bir fikir verecektir .

(Yardımcı olması durumunda, nihayet sorun olarak tanımladığım birkaç kod satırını temizleyerek sorunumu çözdüm. Yemin ederim ki yanlış bir şey yoktu, ama bence hem iyileştirici hem de CPU için talimatlar yeniden sıralandı performans ve sanırım zaman zaman biraz daha fazla hız elde etmek için şansları vardı .. Bu gün bile tek çekirdekli çok süreçler ve bence bir kayıt yazılmadan önce bir aa her büyük kez bir büyük. Ben "Instance alan" değerlerini doğru başlangıcında yerel değişkenler taşındı. yerel değişkenler çalışmalarına tüm hesaplamaları anahtarlamalı ve yerel değerler senkronizasyon bloklar içinde geri sadece en sonunda taşındı. ve ben bir kullanılmış yerel değerini "örnek alanı" yerine yöntem döndürme değeriKullanıyordum.)

Hata ayıklamada birinci kural: tekrarlanabilir bir senaryoya ihtiyacınız var .

Eğer bir hesabınız yoksa, önce bu konuda çalışmalısınız. Bu hatayı, hiçbir metalin kesilmediği bir tür "simülasyon modu" nda çoğaltabilir misiniz? Burada mantıklı geliyor. Birkaç gün içinde 20 günlük süreci simüle ederek birkaç farklı kesme programını hızlı ve otomatik olarak çalıştırabilir misiniz? Bu, sorunun ortaya çıkma olasılığını artırabilir.

Sonra, böyle bir senaryo olduğunda, bir sonraki adım mümkün olduğunca fazla bilgi toplamak ve aslında hata ayıklamaya başlamaktır.

Bu hangi dilde çalıştığından emin değilim, ancak kodumda (C ++) düzensiz hatalar yaşıyorsam , bellek açısından hiçbir şeyin olmadığından emin olmak için valgrind veya cppcheck gibi bir araç kullanacağım .

RalphChapin'in cevabı hakkında bir uzatma:

Yıllar boyunca, yalnızca ekli donanım nedeniyle çoğaltılamadığım sistemlerde kendilerini gösteren çok sayıda hata avlamak zorunda kaldım.

Başka bir şey deli gibi günlüğe ek olarak yararlı buldum: Kodun nerede olduğunu ve bazı ilgili değişkenlerin değerlerini gösteren ekrana bilgi koymak. Sorun ortaya çıktığında fabrika katındaki işçiler bile bilgileri okuyabiliyorlardı.

Tam olarak tespit etmek genellikle birkaç tur incelik gerektirdi, ancak çok etkili oldu.