Dobre praktyki programowania sterowników PLC

Nie rozumiem trochę. Dlaczego nie używasz DB? Masz falownik czy cokolwiek z rozpisaną ramką do komunikacji to tworzysz db input i db output rozpisujesz w nich odpowiednio ramki i już. Inputa odczutujesz na początku cyklu outputa wysyłasz na koniec i wszystko śmiga bez markerów. Też z nich nie korzystam.

Wiem, że tak można. Przeważnie w blokach do komunikacji z falownikami od producentów stosowane jest takie rozwiązanie. Nie pasuje mi w nim to, że zmienne są ukryte wewnątrz bloku. Wolę, żeby Inputy i Outputy były wymieniane przez interfejsy bloku, a nie przez instrukcję wewnątrz.
Jednak IO nie po profinecie/profibusie a z modułów sterownika nie odczytasz w ten sposób?

Nie do końca się z Tobą zgadzam. Podczas analizy czyjegoś kodu, niezbyt mnie interesuje co programista miał na myśli, tylko co zawiera/realizuje poniższy kod, tak abym mógł go szybko zrozumieć. Sam tak robię, każdy rung/network komentuje. Komentarz zawiera informację jak działa poniższy kod i co robi.

Jeszcze jedna ważna rzecz o której nikt nie wspomniał, uważam iż należy nazywać zmienne oraz pisać komentarze w języku angielskim. W polskim źle to wygląda.
Nazwy tagów urządzeń powinny być takie jak na schemacie P&ID. Porządne nazwy a nie jakieś z dupy jak to nie raz bywa.

Chodzi mi o to, że jak wiesz, co programista ma na myśli to nie musisz analizować każdego networku styk po styku tylko możesz część kodu pomijać wnioskując z komentarzy, co realizuje.

3 posts were split to a new topic: 10 porad programowania sterowników PLC na bazie GX Works od Mitsubishi Electric

Jacku, czy mógłbyś podzielić się treścią tego przewodnika?

Witam, czy jest możliwość wglądu do tego przewodnika który otrzymałeś? Pozdrawiam

  1. Ktore rozwiazanie uwazacie za lepsze w momencie np. gdy chcemy wysterowac trzy cewki, nie mowie o jakis bardziej skomplikowanych networkach, tylko proste wyjscia, czy rozbiajcie to na linijki, czy wszytsko w jednej.
    image

  2. Czy tworzycie takie struktury dla np. przyciskow i uzywacie ich w kodzie ? Np. zbocz sa wygodne, wszystkie zmienne i wszystkie ich stany w jednym bloku, ale wtedy w kodzie zbocze juz nie jest dla obcej osoby odrazu widziane jako zbocze tylko musi dokladnie wczytac sie w nazwe, tak samo inversja jakiegos stanu moze byc mylaca. Czy uwazacie takie rozwiasanie za dobre, czy jednak daje wiecej szkody niz pożytku.
    image

1 polubienie
  1. Dla funkcjonowania i kodu to nie ma znaczenia ale Network 4 jest bardziej rozciągnięty na ekranie a 5 zwarty i pozwala jednym rzutem oka ogarnąć całość gdy jest więcej elementów, ja preferuje rozwiązanie Network 5.
  2. Struktury są jak bardziej wskazane, nawet bez komentarzy są dość oczywiste. Często używam tablic to pomaga gdy używasz zmienne w funkcjach gdzie logika jest powtarzalna -->
    idx=1;
    IF przycisk[idx]=1 AND one_shot[idx] AND warunek[idx]=1 THEN cewka[idx]=1 END;
    idx=2
    IF przycisk[idx]=1 AND one_shot[idx] AND warunek[idx]=1 THEN cewka[idx]=1 END; // //taki przykład może nie czytelny ale pokazujący ideę, taka prosta drabinka w kodzie
1 polubienie

Tak w teksie to widoczne odrazu, w drabince juz mniej. If lepiej w teksie, ale jednak staramy sie mieszac, uzywac tego tak aby bylo to z jednej strony wydaje i optymalne, a z drugiej czytelne. Wiec tam gdzie drabinka sie sprawdza tam zostanie. Mieszanie tych nazw tez chyba nie bedzie dobrym rozwiazaniem. I tutaj mam taka watpliwosc, jak wiadomo nadgorliwosc jest gorsza od faszyzmu.
image

polecam definiować stałe i używać ich zamiast wpisywania czystych wartości liczbowych w miejsca takie jak krok, faza, operacja

2 polubienia