Błąd raz na jakiś czas, ale wysoki priorytet

Pracuję nad projektem CNC (komputerowa kontrola numeryczna), który tnie kształty na metal za pomocą lasera.

Teraz mój problem występuje raz na jakiś czas (1-2 razy w ciągu 20 nieparzystych dni) cięcie przebiega źle lub nie, zgodnie z ustawionymi ustawieniami.

Ale powoduje to stratę, więc klient nie jest z tego powodu bardzo zadowolony.

Próbowałem znaleźć przyczynę tego przez

1. W tym pliki dziennika
2. Debugowanie
3. Powtarzanie tego samego środowiska.

Ale to się nie powtórzy.

Wstrzymanie i kontynuowanie operacji ponownie sprawi, że będzie działać płynnie bez ponownego pojawiania się błędu.

Jak rozwiązać ten problem? Czy powinienem to określić jako problem sprzętowy?

Obejść

Jak sugeruje ChrisF , pragmatycznym rozwiązaniem krótkoterminowym może być zastosowanie sztuczki pauzy i wznowienia , ale musisz porozmawiać z klientami, aby dowiedzieć się, jakie powinny być twoje priorytety. Na przykład:

• Jeśli usterka spowoduje utratę części o wartości 1000 GBP lub spowoduje 4 godziny przestoju raz w tygodniu, a poprawka wstrzymania i wznowienia produkcji zmniejszy się o 1%, prawdopodobnie teraz preferują naprawę.

• Jeśli usterka spowoduje uszkodzenie części o wartości 1 GBP lub spowoduje 4 minuty przestoju raz w tygodniu, ale poprawka wstrzymania-wznowienia zmniejsza produkcję o 1%, prawdopodobnie wolą poczekać na poprawkę, która nie wpływa na szybkość produkcji.

Pracując przez wiele lat w branży mikroobróbki laserowej, wiem, jak duży nacisk możesz wywierać, aby zoptymalizować proces i sprawić, aby Twoja maszyna produkowała tak dużo części na godzinę, jak to możliwe, więc tak czy inaczej nacisk, aby poprawnie rozwiązać problem.

Logowanie

Z mojego doświadczenia wynika , że jedynym sposobem skutecznego wyśledzenia Heisenbuga jest obfite rejestrowanie. Zaloguj się do wszystkich części kodu i wokół niego, które mogą być odpowiedzialne za błąd. Dowiedz się, jak skutecznie odczytywać pliki dziennika, upewnij się, że monitorujesz błędy w silnikach (czy etapy poruszają się tam, gdzie powinny, kiedy powinny?). Spójrz na użycie pamięci na komputerze, czy wyciek pamięci powoduje głodzenie krytycznego procesu?

Upewnij się, że rejestrujesz również działania użytkownika, czy masz pewność, że operator nie uderza w przycisk zatrzymania awaryjnego, aby mógł wyskoczyć na przerwę na papierosa podczas naprawy? Widziałem, jak to się dzieje!

Analiza statyczna

Poszukaj również korelacji między zapisywaniem pewnych wzorców a uruchamianym błędem częściej lub rzadziej. Jeśli znajdziesz wzorce, które częściej wyzwalają problem (lub nigdy go nie wyzwalają), może to wskazywać na problem.

Staraj się tworzyć wzory, które powodują problem jeszcze częściej. Jeśli potrafisz znaleźć sposób na niezawodne wywołanie problemu, jesteś w połowie drogi do rozwiązania.

Inne opcje

Wreszcie, nie spiesz się z obwinianiem sprzętu, ale nigdy nie zakładaj, że jest idealny. Wiele razy obwiniano mnie za problemy, które okazały się natury elektrycznej lub mechanicznej, więc zawsze musisz mieć to za sobą.

Mimo że zwykle nie masz dostępu do komputera, pamiętaj, że niektóre problemy można skutecznie rozwiązać tylko na komputerze. Czasami kilka dni w witrynie może być wartych tygodni za pomocą zdalnego pulpitu i miesięcy całkowicie offline. Jeśli zabraknie Ci opcji off-line, nie bój się zaproponować wizyty na stronie, mogą tylko powiedzieć „nie”.

Możesz także przyjrzeć się pytaniom i odpowiedziom na pytanie Co robisz z heisenbugiem? i co zrobić z błędami, które nie powodują repro? ale mogą nie być tak przydatne w twojej sytuacji.

Przedstawię sugestię „od ściany”.

Idź do kierownika fabryki i poproś o przejrzenie zapisów monitorowania linii elektroenergetycznej dla tego narzędzia lub tego obszaru, w odniesieniu do czasów wystąpienia awarii. Zapytaj go również, czy w tym czasie było jakieś spawanie lub inna nietypowa czynność.

Kilkadziesiąt lat temu mój ojciec spędził naprawdę miło czas z minikomputerem, który w ogóle nie miał żadnego powodu. Zadzwonili do przedstawiciela klienta producenta.

Przedstawiciele przyszli do ich biura, w obszarze fabryki, i podłączyli woltomierz do ściany obok mini, a następnie powiedzieli „Obejrzyj to”.

Kilka minut później woltomierz nagle opadł znacząco, a potem wrócił. Przedstawiciel powiedział: „To on uderzył w łuk testowy. Poczekaj chwilę”. Niedługo potem woltomierz ponownie się zapadł i tym razem pozostał.

Przedstawiciel powiedział: „To twój problem. Masz faceta spawającego się na hali produkcyjnej, a on jest na tej samej nodze, co ty. Widziałem, jak się przygotowywał, kiedy wchodziłem”.

Musieli uruchomić zupełnie osobne źródło zasilania do biura.

Problem jest prawdziwy, ma realne konsekwencje dla użytkownika - tj. Zrujnowaną pracę itp., Więc wymaga naprawy. Nie trzeba go jednak „poprawnie” naprawiać. Stwierdzasz:

Wstrzymanie i kontynuowanie operacji ponownie sprawi, że będzie działać płynnie, a błąd pojawi się ponownie.

W takim przypadku po prostu zrób to. Klient będzie zadowolony, że nie marnuje materiału na wadliwe przebiegi, nawet jeśli normalne przebiegi trwają kilka sekund dłużej.

Oczywiście w perspektywie długoterminowej może być konieczne naprawienie tego „poprawnie”, ale na razie zmniejsz swoje straty, przejdź do obejścia i przejdź do czegoś innego.

Miałem błąd w grze, który zdarzył się tylko 1 raz na miliard. Na szczęście oznaczało to, że widziałem to co 15-30 minut, ale przeglądanie kodu w debuggerze nie działało. W końcu wprowadziłem komunikaty debugowania. Musieli używać fantazyjnych instrukcji if, ponieważ chciałem czegoś tylko wtedy, gdy pojawił się problem. W większości przypadków kod debugowania powtarzał obliczenia w zwykłym kodzie, ale stosował różne techniki. Powtórzenia nie musiały być precyzyjne. Gdybym wiedział, że liczba zawsze powinna być mniejsza niż 10 000, a czasami wydaje się, że osiąga 150 000, po prostu sprawdziłbym wartość ponad 100 000. Za każdym razem, gdy pojawiał się błąd, analizowałem moje wyniki, opracowywałem bardziej skomplikowane komunikaty debugowania (a dokładniej, bardziej skomplikowane kontrole, aby sprawdzić, czy powinienem wyświetlić komunikat), i czekałem na ponowne pojawienie się problemu.

Twoje cykle będą znacznie dłuższe niż moje, ale w końcu zbliżysz się do problemu. Mam nadzieję, że uda ci się znaleźć rozwiązanie inną, szybszą metodą, ale w końcu to złapie, jeśli nic innego nie da, i da ci poczucie, że robisz coś, dopóki nie wpadniesz na lepszy pomysł.

(W przypadku, gdy jest to pomocne, w końcu rozwiązałem problem, usuwając kilka wierszy kodu, który w końcu zidentyfikowałem jako problem. Przysięgam, że nie było z nimi nic złego, ale myślę, że zarówno optymalizator, jak i procesor zmieniają instrukcje dla wydajność i myślę, że od czasu do czasu próbowali uzyskać trochę dodatkowej prędkości. Nawet jeden rdzeń wieloprocesowy w dzisiejszych czasach i myślę, że co chwila, gdy rejestr był czytany, zanim został zapisany. Wszystkie obliczenia przestawiłem na pracę ze zmiennymi lokalnymi. Wartości „pola wystąpienia” zostały przeniesione do zmiennych lokalnych na samym początku, a wartości lokalne zostały przeniesione tylko z powrotem na samym końcu, wewnątrz bloków synchronizacji. I użyłem wartości lokalnej dla metoda zwraca wartość zamiast „pola instancji”Używałem.)

Zasada numer 1 w debugowaniu: potrzebujesz odtwarzalnego scenariusza .

Jeśli nie masz, powinieneś najpierw nad tym popracować. Czy potrafisz odtworzyć ten błąd w jakimś „trybie symulacyjnym” maszyny, w którym metal nie jest tak naprawdę wycinany? To wydaje się mieć sens tutaj. Czy potrafisz szybko i automatycznie uruchomić kilka różnych programów cięcia, symulując proces 20 dni w kilka minut? Może to zwiększyć prawdopodobieństwo pojawienia się problemu.

Następnie, gdy masz taki scenariusz, następnym krokiem jest zebranie jak największej ilości informacji i rozpoczęcie debugowania.

Nie jestem pewien, w jakim języku jest on uruchomiony, ale jeśli napotkam błędne błędy w moim kodzie (C ++), użyję narzędzia takiego jak valgrind lub cppcheck, aby upewnić się, że nic nie dzieje się pod względem pamięci.

Rozszerzenie odpowiedzi RalphChapina:

Przez lata musiałem wyłapać sporo błędów, które pokazały się tylko na systemach, których nie mogłem powielić z powodu podłączonego sprzętu.

Oprócz logowania jak szalona jeszcze jedna rzecz, która mi się przydała: Umieszczenie na ekranie informacji pokazujących, gdzie był kod i wartości niektórych istotnych zmiennych. Kiedy pojawił się problem, nawet pracownicy fabryki mogli przeczytać mi informacje.

Zazwyczaj wymagało to kilku rund udoskonalenia, aby dokładnie go określić, ale było bardzo skuteczne.