Pytanie dotyczy kolejności diagnostyki zależnej od kontekstu. W praktyce mechatroniki (szczególnie przy sterowaniu PLC/PAC) inaczej postępuje się, gdy:
- testujesz nowy lub zmieniony program (uruchomienie/commissioning),
- usuwasz awarię w dotąd działającym układzie (troubleshooting eksploatacyjny).
W treści jest wprost: "Podczas testowania działania programu". To oznacza, że właśnie weryfikujesz oprogramowanie po wgraniu lub zmianach. Zgodnie z zasadą "najpierw sprawdź to, co właśnie zmieniłeś", pierwszą czynnością jest sprawdzenie poprawności kodu programu sterującego silnikiem.
Co konkretnie w kodzie bywa przyczyną, że po naciśnięciu START silnik nie rusza?
- błędna logika (np. brak warunku zezwolenia, nieprawidłowa sekwencja),
- błędne przypisanie adresu wejścia przycisku S (mapowanie I/O),
- błędny adres/wyjście dla silnika M,
- pomyłka w typie sygnału lub negacja (NO/NC) w logice programu.
Dlaczego pozostałe odpowiedzi nie są "pierwsze" w tym scenariuszu?
- Sprawdź połączenia elektryczne silnika – to ważne przy awarii sprzętowej, ale w fazie testu nowego programu statystycznie częściej zawodzi świeżo zmieniony kod niż okablowanie.
- Sprawdź stan przycisku start – również możliwe, ale zanim uznasz element za uszkodzony, sprawdzasz czy program widzi sygnał START (adres, monitorowanie online).
- Sprawdź stan zasilania systemu – brak zasilania zwykle powoduje szersze objawy (brak pracy sterownika, brak sygnalizacji). W pytaniu problem dotyczy reakcji na START podczas testu programu, więc pierwszeństwo ma weryfikacja oprogramowania.
Wskazówka egzaminacyjna: zwracaj uwagę na słowa-klucze typu "testowanie programu", "po modyfikacji", "uruchamianie" – one zmieniają właściwą kolejność działań diagnostycznych.
