Padł komputer na produkcji. Dramat w firmie.

W jednej z krakowskich firm zepsuł się komputer zbierający dane z pras wulkanizujących produkowane elementy gumowe. Padł dysk twardy, a jego uszkodzenie było na tyle poważnie, że ratowanie nie było opłacalne. Uszkodzenie tego komputera spowodowało brak możliwości kontroli jakości oraz rozliczania wyprodukowanych elementów. Sprawa zrobiła się pilna.

Instalacja nowego komputera

Stary komputer działał na systemie Windows XP, dlatego że wymagał tego autorski program obsługujący dane z interfejsów pras. W związku z tym należało na nowym komputerze zainstalować właśnie Windows XP. Ten system nie ma wielkich wymagań sprzętowych,więc wziąłem sprzęt z firmowego „archiwum” i postawiłem system. Kłopoty zaczęły się później. Dostawca rozwiązania nie dostarczył instrukcji instalacji systemu i musiałem polegać na własnych spostrzeżeniach. Z pomocą przyszedł katalog uruchomieniowy zachowany na innym komputerze. Wynikało z niego, że podstawą przechowywania danych z programu była baza danych postgresql-8.2. Udało się ją pozyskać z Internetu. Instalacja przebiegła zwyczajnie. Kłopoty zaczęły się później. Program obsługujący dane z pras uruchamiał się normalnie, a nawet udało się za jego pomocą stworzyć potrzebną bazę danych, jednak dodawanie poszczególnych urządzeń do bazy skutkowało niczym. Nie wyświetlał się nawet komunikat o błędzie. Nastąpił impas.

Uruchomienie programu

Wnikliwe zapoznanie się z katalogiem uruchomieniowym programu do obsługi danych z pras trwało dość długo, ale opłacało się. Znalazłem tam plik zawierający zapytania SQL. Po analizie zapytań okazało się, że zakładają one właściwe tabele, tworzą indeksy i zależności między nimi. Należało spróbować użyć tych zapytań w programie administracyjnym bazy. Tak też zrobiłem, ale wcześniej wykasowałem wszystkie tabele, żeby uniknąć kolizji. Ta operacja przyniosła sukces. Udawało się dodawać urządzenia do bazy. Można było uznać, że komputer jest przygotowany do przyjmowania danych z pras.

RS485

Nie było jednak pewności co do sprawności urządzenia służącego do komunikacji z prasami za pomocą interfejsu RS485. Zostało więc zakupione nowe urządzenie wyposażone w diody sygnalizujące stan komunikacji. Po podłączeniu magistrali RS485 okazało się, że jakaś komunikacja przebiega, ale nadal komputer nie pobiera danych z urządzeń. Powodem tego stanu była nieznajomość adresów interfejsów znajdujących się przy maszynach. Potrzebna była dokumentacja. Zorganizowałem sobie stanowisko testowe, które składało się z komputera roboczego (Windows XP), laptopa ( Windows 10 ), urządzenia sterującego pracą pras, i dwóch interfejsów USB-RS485. Połączyłem to w ten sposób, że komputer z XP, na którym był zainstalowany program do zbierania danych z produkcji komunikował się z urządzeniem sterującym prasą, a drugi interfejs USB-RS485 podłączyłem do laptopa w celu podglądania komunikacji za

pomocą programu PuTTY. Urządzenie sterujące należało podłączyć do zasilania 230V, więc użyłem do tego celu warsztatowego przewodu z płaską wtyczką. Mając w ręku dokumentację techniczną ustawiłem właściwe parametry transmisji na portach COM – prędkość oraz kontrolę parzystości. Pozostał do ustalenia jeszcze adres urządzenia, który jak można było wyczytać w dokumentacji ustalany był w menu urządzenia sterującego. Po odczytaniu adresu i wpisaniu go do programu zbierającego dane komunikacja z urządzeniem została uruchomiona. Na ekranie podglądu zaczęły się pojawiać sensowne dane zamiast „krzaczków”.

Z tą wiedzą pojechałem do firmy i odczytałem adresy z wszystkich pras, a następnie skonfigurowałem program gromadzący dane z produkcji zgodnie z odczytem. Maszyna ruszyła. Pozostało jeszcze uzupełnić dokumentacje techniczną o brakującą instrukcję instalacji oprogramowania i fajrant.