Raspberry Pi 5 jako lokalny serwer MES dla warsztatu CNC — mój projekt

Cześć,

Dzielę się projektem, który rozwijam od 2024 roku — zbudowałem lokalny
system MES oparty na Raspberry Pi 5, który podłącza się do przemysłowych
obrabiarek CNC i zbiera dane ze sterowników w czasie rzeczywistym.

Co to robi:
— odczytuje statusy, czasy cykli, alarmy i obciążenie wrzeciona
bezpośrednio ze sterowników (OPC-UA, S7/Siemens PLC, FOCAS/Fanuc, Modbus)
— kolejkuje zlecenia produkcyjne i przypisuje do maszyn
— liczy OEE automatycznie z danych maszynowych, bez ingerencji operatora
— zarządza magazynem narzędzi i materiałów

Stack techniczny:
Raspberry Pi 5 + własne oprogramowanie serwowane lokalnie przez przeglądarkę.
Zero chmury, wszystko w sieci zakładowej. Zdalny dostęp przez VPN (Tailscale)
bez otwierania portów w routerze.

Pierwsze wdrożenie:
2 frezarki AFM BACA R1000 + tokarka AFM VENUS 350 w warsztacie Inframet.
Podłączenie przez adapter S7 (Siemens PLC). Codziennie odzyskujemy minimum
1 godzinę, która wcześniej szła na koordynację — kto co robi, gdzie jest
narzędzie, ile materiału zostało.

Sam jestem technologiem i programistą CNC — buduję to z perspektywy
kogoś pracującego na hali, nie software house'u.

Jeśli ktoś jest ciekaw jak to wygląda w praktyce, postawiłem środowisko
demo online — można się zalogować gotowymi danymi i poklikać bez
rejestracji: https://prodq.app

Chętnie też wyślę Boxa do przetestowania na prawdziwych maszynach
jeśli ktoś ma ochotę — koszt zerowy, wysyłka gratis.

Chętnie odpowiem na pytania o protokoły, adaptery, architekturę RPi.

Kuba

To jest reklama

Rozumiem wrażenie — jest link i oferta testu, więc wygląda reklamowo.

Ale to faktycznie projekt, który sam zbudowałem i używam codziennie
na hali. Jeśli coś konkretnego wzbudza wątpliwości — chętnie odpowiem.
Mogę opisać dokładnie jak działa integracja z S7, jak wygląda odczyt
danych przez OPC-UA, albo co konkretnie robi RPi5 w tej architekturze.

Nie mam problemu z pytaniami technicznymi.

Obiecałem konkrety, więc poniżej jak to działa pod spodem — bez marketingu,
sama technika. Jak coś jest niejasne albo brzmi naciągane, pytajcie, odpiszę.

ARCHITEKTURA W SKRÓCIE
RPi5 stoi w szafie w sieci zakładowej i robi dwie rzeczy: kolektor danych
z maszyn + serwer aplikacji (UI w przeglądarce w LAN). Żadna dana nie
wychodzi na zewnątrz. Zdalny podgląd robię przez Tailscale (WireGuard),
więc nie otwieram żadnego portu w routerze ani nie wystawiam niczego do netu.

SKĄD BIORĘ DANE (zależnie od sterownika)
— Siemens (u mnie BACA R1000 i VENUS 350): po S7, czytam cyklicznie
konkretne sygnały ze sterownika — stan (praca/stop/alarm), obciążenie
wrzeciona, licznik/czas cyklu. [TU Twój konkret: jaki adapter/biblioteka
S7, co ile sekund pollujesz, z którego DB lecą sygnały]
— Fanuc: przez FOCAS.
— Sterowniki wystawiające OPC-UA: subskrypcja po OPC-UA.
— Proste przypadki / starsze PLC: Modbus TCP.
Nic nie wpisuje operator — dane lecą prosto ze sterownika.

JAK LICZĘ OEE BEZ OPERATORA
OEE = Dostępność × Wydajność × Jakość, liczone z surowych sygnałów:
— Dostępność: z czasu praca/stop/alarm (z sygnałów stanu, nie z kartki).
— Wydajność: rzeczywisty czas cyklu vs nominalny dla danego programu.
— Jakość: z liczby sztuk dobrych/braków.
Klucz w tym, że to leci z maszyny automatycznie — nie z ręcznych wpisów,
które i tak nikt rzetelnie nie prowadzi.

CO RPi5 REALNIE UDŹWIGA
Polling kilku maszyn co kilka sekund + lekka baza lokalna + serwowanie UI
to dla RPi5 (8GB) żaden problem — 24/7, bez wentylatora pod obciążeniem.
3 maszyny, interwał 1s, obciążenie CPU 18%, RAM 2488 MB / 8063 MB

DLACZEGO LOKALNIE, A NIE W CHMURZE
Rysunki techniczne i programy NC to często know-how klienta. U mnie nigdy
nie opuszczają sieci zakładu — to był wymóg od początku, nie dodatek.

Jak kogoś interesuje konkretny kawałek — np. odczyt z S7 albo jak wygląda
liczenie czasu cyklu z sygnału — mogę pokazać zrzut albo opisać dokładniej.

Ogólnie Szacun.

Zastanawia mnie sposób określania jakości, czyli ilości wadliwych sztuk. Kto i kiedy wprowadza ilość braków i na jakiej podstawie? Spc, czy kontrola 100%?

Z danych, brakowałoby jeszcze rejestru posuwu i obrotów wrzeciona. Oraz przyrównanie posuwu rzeczywistego, do posuwu optymalnego dobranego z technologiem.

Dzięki za konkretne pytania — to dokładnie te tematy, które rozstrzygają,
czy taki system ma sens na hali, czy jest tylko ładnym dashboardem.
Odpowiadam po kolei, ze zrzutami.

JAKOŚĆ / BRAKI — KTO, KIEDY I NA JAKIEJ PODSTAWIE

Braki wpisuje człowiek, system tego nie zgaduje — i celowo. Są trzy drogi:

1) W trakcie zlecenia: przy maszynie działa kiosk operatora (tablet albo
stary monitor z przeglądarką). Operator klika "zgłoś brak", podaje ilość
i kategorię: wymiar / powierzchnia / wada materiału / złamanie narzędzia /
błąd programu / inne, opcjonalnie dopisuje opis. Zajmuje to kilkanaście
sekund, więc realnie jest robione na bieżąco, a nie "potem się uzupełni".



2) Przy zamknięciu zlecenia: operator podaje sztuki dobre / wadliwe
+ ewentualne uwagi. To zamyka bilans zlecenia.



3) Wariant bez tabletu/telefonu na hali: na każdej maszynie leży plik
tekstowy kolejki, który stanowi prosty interfejs między operatorem
a biurem. Operator otwiera go na sterowniku tak samo, jak zwykły
program NC — i tam wpisuje braki albo oznacza zlecenie jako ukończone.
Zero dodatkowego sprzętu na hali.



Czy podstawą jest SPC, czy kontrola 100% — to zostawiam procesowi zakładu.
System rejestruje wynik i kategorię, nie narzuca metodyki kontroli. Za to
kategorie braków dają po czasie rozkład przyczyn — np. że połowa braków
w miesiącu poszła na złamane narzędzie, a nie na błędy programu. To często
cenniejsze niż sam procent jakości.

Jeden szczegół, na który zwracam uwagę, bo wiele systemów tu kłamie:
jeśli nikt nic nie zaraportuje, system NIE przyjmuje 100% jakości.
OEE liczy się wtedy z samej dostępności i wydajności, a komponent jakości
jest jawnie oznaczony jako nieraportowany. Wolę uczciwe "brak danych"
niż ładny, zmyślony wskaźnik.

Drugi szczegół: sztuki są przypisywane do konkretnej maszyny. Jak zlecenie
wędruje między maszynami (np. dokończone na innej frezarce), braki nie
liczą się podwójnie i nie obciążają niewłaściwej maszyny.

POSUW I OBROTY — TO JUŻ JEST ZBIERANE

Tu mogę uspokoić — rejestr istnieje i jest szerszy niż samo obciążenie
wrzeciona. Co ~1 s zapisuję per maszyna m.in.:

— posuw rzeczywisty i zadany + procent korekty posuwu (override 0-200%),
— korektę posuwu szybkiego (rapid override),
— obroty rzeczywiste i zadane + override obrotów,
— obciążenie wrzeciona, aktualny program i numer bloku, stan, alarmy.

Tak to wygląda w surowym rejestrze (każdy wiersz to snapshot z maszyny):







Źródło zależy od sterownika: na Fanucu to FOCAS (cnc_acts/cnc_actf,
korekty z PMC), na sterownikach z OPC-UA — subskrypcja tagów, na prostszych
— rejestry Modbus, u mnie na Siemensach — odczyt z S7. I ważne dla
spokoju ducha: wszystko jest READ-ONLY. Adapter niczego nie zapisuje
do sterownika — maszyna nawet nie wie, że ktoś ją czyta.

Sam override w praktyce mówi bardzo dużo — od razu widać moment, w którym
operator kręci gałką w dół i cykl "nagle" robi się 30% dłuższy. Bez tego
sygnału wygląda to jak problem z maszyną albo programem.



POSUW RZECZYWISTY VS OPTYMALNY OD TECHNOLOGA

Bardzo dobry pomysł i powiem szczerze, jak to dziś wygląda: dane po
stronie maszyny już mam (rzeczywisty vs zadany + override), natomiast
brakuje warstwy "nominał ustalony z technologiem" jako punktu odniesienia
w raporcie — czyli żeby przy operacji był zapisany posuw technologiczny
i raport pokazywał odchyłkę od niego, a nie tylko od wartości zadanej
w programie. Dedykowanego wykresu posuwu w czasie też jeszcze nie mam —
dane są w rejestrze, widok dorobię. Zapisuję jedno i drugie do planu,
bo to domyka pętlę technolog → maszyna → raport. Dzięki za ten trop.

Jak coś jeszcze budzi wątpliwości — pytajcie, chętnie zejdę głębiej.

Jeśli zadasz operatorowi za dużo papierologii do wypełniania, jak nadmierne info o kontroli, wtedy oee spadnie bo gość nie zdąży z robotą.
Podobnie, oee spada gdy operator musi obsługiwać za dużo maszyn jednocześnie.
Wtedy operator może sobie zmniejszyć posuw w g-kodzie albo pokrętłem, a biuro nie połapie się w nadmiernej ilości danych.

Dodane 24 minuty 13 sekundy:
Zbieranie danych ze sterowników to bardzo dobry pomysł i może usprawnić produkcję, bo "Pańskie oko konia tuczy".