Obsługa przerwań

Starszyzna mawiała: „szybko to się pchły łapie”. Dziś większość z nas żyje w przekonaniu, że wszystko da się zaplanować — rozłożyć w czasie, ustawić priorytety, oszacować, ile zajmie dane zadanie. Kalendarz, lista rzeczy do zrobienia, blok czasowy na konkretny projekt. W teorii to się zgadza.

W praktyce prędzej czy później pojawia się coś, co w informatyce nazwalibyśmy przerwaniem — zdarzenie, które w ułamku sekundy potrafi całkowicie zmienić skrzętnie ułożony plan dnia. Telefon od klienta w środku pisania kodu. Plik DXF, który trzeba poprawić „na już”, bo maszyna stoi. Program CNC, który miał być gotowy na jutro- jest potrzebny za pół godziny.

Tryb standby

Dzieje się tak wtedy, gdy nie robisz jednej rzeczy na raz w izolacji od środowiska zewnętrznego, tylko jesteś dostępny dla zadań, które mogą — ale nie muszą — wystąpić. To coś w rodzaju trybu standby znanego z elektroniki: urządzenie nie pracuje pełną mocą przez cały czas, ale jest gotowe uruchomić się natychmiast, gdy przyjdzie sygnał. W pracy nad oprogramowaniem CAM/CNC ten sygnał przychodzi zwykle w najmniej dogodnym momencie 😉

Z zewnątrz może to wyglądać na brak zorganizowania albo niezbyt profesjonalny sposób pracy — praca ciągle przerywana, plan dnia rozjeżdżający się w połowie. Rzeczywistość jest inna, jeśli wiesz, że coś takiego może się zdarzyć i jesteś na to przygotowany na kilku poziomach naraz:

• Sprzętowo — środowisko pracy gotowe do natychmiastowego działania, bez tracenia czasu na uruchamianie i konfigurację od zera.
• Programowo — narzędzia i szablony pod ręką, żeby poprawka geometrii czy postprocesora nie zaczynała się od zera za każdym razem.
• Merytorycznie — znajomość specyfiki konkretnej maszyny, sterownika, klienta na tyle dobra, żeby diagnoza nie wymagała długiego namysłu.
• Po prostu po ludzku — nastawienie, że to nie jest „katastrofa, która rujnuje dzień”, tylko naturalna część tej pracy.

Kiedy te cztery elementy się zgadzają, poprawianie łuków, dodawanie mostków technicznych czy korekta geometrii w programie przestaje być „żmudną robotą” wykonywaną pod presją. Staje się częścią tego, na co się umówiłeś, podejmując się pisania oprogramowania dla realnych maszyn w realnych firmach — a nie oprogramowania testowanego wyłącznie na spokojnie, w laboratoryjnych warunkach.

Dlaczego to ma znaczenie akurat tutaj

W świecie CNC — cięcia plazmowego, laserowego, obróbki na szlifierkach — przerwania mają często bardzo konkretną przyczynę: produkcja nie czeka. W małych i średnich firmach produkcyjnych zlecenie „na CITO”  to może nie codzienność ale i nie rzadkość. Klient dostaje pilne zamówienie, jego technolog akurat jest poza biurem albo na urlopie, a program do wycięcia detalu musi powstać teraz. Wtedy liczy się to, czy narzędzie, z którego korzysta programista, pozwala szybko rozwiązać  problem.

To jeden z powodów, dla których warto traktować pisanie oprogramowania CAM/CNC nie jako jednorazowy projekt „zrobiony i zapomniany”, tylko jako coś, co rozwija się razem z realnymi przypadkami użycia zgłaszanymi przez Klientów w takich właśnie momentach. Poprawka wprowadzona, żeby rozwiązać konkretny, pilny problem u jednego Klienta, bardzo często okazuje się przydatna dla wszystkich pozostałych — bo ten sam typ błędu geometrii czy tej samej niedoskonałości postprocesora prędzej czy później pojawi się gdzie indziej.

Efekt, którego nie widać na pierwszy rzut oka

Co dostaje się w zamian za tę gotowość — oczywiście poza samą gratyfikacją i satysfakcją z dobrze wykonanej pracy?

Zdjęcia wypalonych elementów od Klientów, którzy palą blachę w trybie awaryjnym, w chwili gdy program musiał powstać „na już”, a mimo to detal wyszedł czysto i bez poprawek. Po jakimś czasie zdarza mi się przejść nabrzeżem portowym i rozpoznać kawałek konstrukcji wypalonej programem wygenerowanym w Neron CNC. Podobnie jest z maszynami rolniczymi stojącymi gdzieś na polu, czy z kotłami c.o. — jeden mam zresztą we własnym domu. To nie są sytuacje planowane z wyprzedzeniem ani efekty dużych, głośnych wdrożeń — to zwykle skutek tych właśnie „przerwań”: pilnej poprawki, szybkiej konsultacji, jednej linijki kodu dodanej wieczorem, żeby rano wszystko działało jak trzeba.

Podsumowanie

Praca w trybie ciągłej dostępności na zdarzenia, które mogą, ale nie muszą wystąpić, wymaga innego podejścia niż praca w ściśle zaplanowanym harmonogramie. Wymaga przygotowania na kilku poziomach naraz i pewnej odporności na to, że plan dnia i tak się rozjedzie. Ale jeśli robi się to, co się lubi — możliwie najlepiej, jak się umie — to właśnie te nieplanowane momenty często dają najwięcej: zarówno w postaci realnie rozwiązanych problemów klientów, jak i w postaci ciągłego rozwoju samego oprogramowania. I tego, kto je pisze.