Podstawą wszystkich środowisk programistycznych, nie tylko związanych ze sterownikami PLC, jest modularność tworzonych programów. Umożliwia to łatwe, wielokrotne wykorzystanie tych samych obiektów w obrębie tego samego projektu. Kolejnym krokiem w kierunku optymalizacji pracy jest korzystanie w nowych projektach z kodu napisanego dla poprzednich programów. W środowisku CODESYS v2.3 można w tym celu wykorzystać własne biblioteki programowe.
W przypadku małych fragmentów kodu tworzenie bibliotek może być jednak nieopłacalne. Często wystarczy korzystanie z funkcji Import/Export lub Merge Project. Biblioteki stają się jednak niezastąpione, kiedy:
- pracujemy nad większą liczbą bloków funkcyjnych i funkcji
- bloki programowe wymagają korzystania z innych bibliotek
- bloki programowe są powiązane z niestandardowymi typami danych
- planowane jest rozwijanie i utrzymywanie kodu przez dłuższy czas
- istnieje konieczność kontroli wykorzystania kodu w celu ochrony własności intelektualnej.
Tworzenie bibliotek
Biblioteka to tak naprawdę zwykły projekt PLC zapisany jako biblioteka. Pracę nad nią zaczynamy więc tak, jak każdy projekt. Kiedy wszystkie obiekty są już gotowe, z menu [File] należy wybrać [Save as], a następnie zmienić typ pliku na Internal library(*.lib).
UWAGA:
Po zapisie w formie biblioteki przestajemy mieć możliwość wgrywania programu do sterownika. Do testowania poprawności działania biblioteki, należy korzystać albo ze źródłowego programu z rozszerzeniem *.pro, albo dodać stworzoną bibliotekę do czystego projektu.
Biblioteki umożliwiają wielokrotne wykorzystanie praktycznie wszystkich obiektów, z jakich składa się projekt:
- bloki funkcyjne
- funkcje
- struktury danych
- wizualizacje
- wykorzystane biblioteki
- listy zmiennych globalnych.
Należy pamiętać, że za pośrednictwem biblioteki nie jest możliwe przenoszenie programów, ustawień targetów oraz konfiguracji sprzętowej PLC. W tym celu należy wykorzystać opcje Export-u.
Dobre praktyki
Ze względu na wspomniane wcześniej cechy bibliotek, podczas tworzenia własnych, zalecane jest trzymanie się pewnych reguł.
- Kod powinien być rozwijany w pliku z rozszerzeniem *.pro. Dzięki temu możliwe jest testowanie wprowadzanych zmian na bieżąco.
- Dobrą praktyką jest, aby po każdej ważniejszej modyfikacji zapisywać plik pod nową nazwą trzymając się np. schematu Nazwa_biblioteki_[data_modyfikacji].pro
- Projekt zapisujemy jako bibliotekę, już bez dodatku daty. Dzięki temu wprowadzone zmiany będą miały od razu efekt we wszystkich projektach, w których biblioteka została użyta.
- Zawsze zachowujemy oryginalny plik z rozszerzeniem *.pro
- Modyfikując bibliotekę nie zmieniamy nazw istniejących już obiektów. Może to powodować problemy w projektach, w których dane obiekty zostały wykorzystane.
- Unikamy zmiany kolejności zmiennych wejściowo-wyjściowych. Jeśli użytkownik biblioteki korzysta z języków graficznych, może to prowadzić do błędnego podłączenia bloków funkcyjnych.
Zabezpieczanie bibliotek
Można wyróżnić cztery rodzaje bibliotek:
1. Biblioteki otwarte – z ogólnie dostępnym kodem źródłowym. Taką bibliotekę można otworzyć za pomocą CODESYS, bez konieczności podawania hasła. Umożliwia to każdemu podgląd i modyfikację kodu źródłowego. Jest to optymalne rozwiązanie, jeśli z biblioteki korzystamy tylko my lub jest to kod Open Source. Przykładem takiej biblioteki jest OSCAT.
Aby stworzyć taki rodzaj biblioteki, wystarczy zapisać projekt jako Internal library(*.lib)
2. Biblioteki zamknięte – czyli takie, w których dostęp do kodu źródłowego zabezpieczony jest hasłem, ale nie jest ono wymagane, aby z nich skorzystać. Przykładem są wszystkie biblioteki WAGO. Jest to rozwiązanie optymalne, gdy udostępniamy biblioteki innym osobom, ale tylko do wykorzystania, bez możliwości edycji.
Aby stworzyć tego typu bibliotekę, należy zabezpieczyć hasłem projekt z rozszerzeniem *.pro. Hasło możemy ustawić w opcjach projektu.
W kategorii Passwords należy zaznaczyć opcję Encrypt project with this password i potwierdzić.
Następnie można zapisać projekt jako bibliotekę tak, jak opisano w punkcie pierwszym.
3. Biblioteki zaszyfrowane – czyli takie, do których wymagane jest podanie hasła zarówno przy otwieraniu biblioteki do edycji, jak i przy dodawaniu jej do projektu.
Żeby utworzyć taką bibliotekę, należy zapisać ją jako typ pliku Encrypted Internal Library(*.lib).
4. Zabezpieczone biblioteki zaszyfrowane – są zabezpieczone na dwóch poziomach, dwoma różnymi hasłami. Jedno hasło zabezpiecza przed nieupoważnionym dodaniem biblioteki do projektu. Nie jest ono jednak wystarczające, aby otworzyć bibliotekę do edycji, jak w przypadku zwykłej biblioteki zaszyfrowanej. Aby otworzyć taką bibliotekę, należy najpierw podać jedno, a następnie drugie hasło.
Rozwiązanie to pozwala na udostępnienie biblioteki tylko wybranym osobom w zakresie wykorzystania, ale nie edycji.
Tworzenie tego typu biblioteki rozpoczynamy od zabezpieczenia projektu tak, jak opisano w punkcie drugim. Ustawione tu hasło zabezpieczać będzie otwieranie biblioteki do edycji. Następnie należy zapisać projekt jako Encrypted Internal Library(*.lib). Hasło ustawione na tym etapie będzie później wymagane zarówno przy dodawaniu biblioteki do projektu, jak i przy otwieraniu jej w celu edycji.
UWAGA:
Przy otwieraniu takiej biblioteki do edycji najpierw wymagane jest hasło ustawione przy zapisie pliku. W drugiej kolejności należy podać hasło, jakim został zabezpieczony projekt.
Profesjonalne biblioteki
Jeśli bibliotekę tworzymy w celu późniejszego udostępniania np. klientom, powinniśmy zadbać o ich przejrzystość. Profesjonalny wygląd można osiągnąć w 4 prostych krokach.
- Komentarze przy deklaracjach zmiennych – podczas korzystania z biblioteki użytkownik ma dostęp tylko do okna deklaracji zmiennych. Wszystkie zmienne wejściowe i wyjściowe powinny zostać odpowiednio opisane, aby poprawne podłączenie bloku funkcyjnego było możliwe bez konieczności odwoływania się do dokumentacji.
- Krótki opis funkcjonalności w deklaracji bloku – z tego samego powodu w oknie deklaracji zmiennych powinien znaleźć się opis działania kodu.
- Funkcja zwracająca aktualną wersję biblioteki – dobrą praktyką jest stworzenie funkcji, która na swoim wyjściu podaje aktualną wersją biblioteki. W oknie deklaracji zmiennych często jako komentarz podawana jest historia modyfikacji.
- Podział zmiennych na public i private – najczęściej przy tworzeniu bloków funkcyjnych korzystamy z wielu zmiennych pośrednich i innych bloków funkcyjnych. Sposób ich wykorzystania jest ukryty wewnątrz biblioteki, ale ich deklaracje są widoczne dla każdego użytkownika biblioteki. Dlatego często ukrywa się deklaracje wszystkich zmiennych, za wyjątkiem zmiennych wejściowo-wyjściowych. Można to osiągnąć korzystając z nagłówków: {library public} i {library private}.
Krzysztof Nosal, WAGO.PL