Ciekawy artykuł od Grzegorza na iAutomatyka.pl z 10 konkretnymi poradami dotyczącymi programowania.
Czytałem. Myślałem, że w artykule będzie coś ciekawego i się zawiodłem. W mojej opinii powiela informacje jakie można znaleźć w dokumentach: Programming guideline i programming styleguide od Siemensa (czy analogiczne dokumenty dla sterowników AB). W zasadzie te 2 dokumentacje można znaleźć po polsku i zawierają to, co ten artykuł, a nawet dużo więcej. Jedyna różnica to rzeczy charakterystyczne dla Mitsubishi jak “Stosuj techniki redukujące liczbę kroków programu” i “Zakładaj rezerwową liczbę zmiennych”.
Jeszcze odnośnie: “Dobrym zwyczajem jest określanie typu zmiennej w jej nazwie” - ale czemu? Jaki ma to sens w dzisiejszych czasach? W Siemensie jeśli jest jakiś problem z typem zmiennych to albo kompilator to wykryje, albo po prostu coś nam źle wyliczy, ale typ zmiennej w nazwie w niczym tu nie pomoże. W sterownikach Allen-Bradley ani razu nie miałem problemu z typem zmiennej. Nie wiem jak inne PLC. Jedyne, co powoduje ten przedrostek z typem zmiennej to chaos, bo jak przykładowo chcę znaleźć parametr PredkoscNapedu to mogę szukać: iPredkoscNapedu, diPredkoscNapedu, rPredkoscNapedu -> wpisywania fraz “iPred…, rPred” - irytujące.
Co w tym złego, że ktoś na bazie dostępnych materiałów opracował w pewnym sensie podsumowanie? Moim zdaniem jest OK, nawet jeśli część jest przekopiowana. Nie każdy grzebał w dokumentacjach a może natknąć się na taki artykuł w Internecie 
Nie napisałem, że coś w tym złego tylko, że dla mnie nie było w tym nic ciekawego.
Nie wiemy czy część jest przekopiowana i czy autor inspirował się dokumentacjami. Może sam równolegle i niezależnie wymyślił notację węgierską, czy zauważył korzyść płynącą ze stosowania struktur i UDT, ale jeśli nie to może warto napisać o materiałach źródłowych 
. Choćby dlatego, że dokumenty takie jak programming guideline/styleguide i inne podobne są mało znane i niedoceniane, a może ktoś będzie chciał bardziej zgłębić temat.
Racja, masz może jak podać linki do tych dokumentacji?
Cześć.
@Marcin wywołał mnie do tablicy, więc pozwolę sobie odpowiedzieć na kilka zastrzeżeń, które napisałeś w komentarzu.
Nie zamieściłem materiałów źródłowych ponieważ tekst napisałem w całości z głowy. Nie ma on charakteru naukowego, ani nawet pseudonaukowo więc pozwoliłem sobie na swobodny styl wypowiedzi bez zamieszczania i bibliografii i odwoływania się do źródeł.
Tekst powstał jako pewnego rodzaju spisanie zasad i praktyk, które wypracowałem wraz z kilku osobowych zespołem, w którym pracuje. Oczywiście nie wymyśliliśmy tego wszystkiego sami. Nie było jednego źródła informacji, o którym mógłbym powiedzie, że z niego kopiowaliśmy. Dojście do konsensusu zajęło nam trochę czasu ponieważ każdy z nas miał już doświadczenie i swój własny styl pisania. Jeżeli miałbym wskazać pozycje na której wzorowałem się na początku to byłyby to chyba poradniki do C#. Była to lektura po której stwierdziłem, że należało by wprowadzić trochę ładu i składu do swoich projektów PLC. Niestety nigdy nie czytałem opracowań o których wspominałeś. Pewnie gdybym na nie trafił to sporo by mi mogły na początku nauki.
Co do wątku oznaczania typu zmiennej w jej nazwie, to mam na ten temat całkowicie inne zdanie. Bardzo często zdarza nam się, że pracujemy nad programem w parze, lub też do projektu który jest już bliski ukończenia trzeba wdrożyć nową osobę. Przedrostek przed zmienną stosujemy również po to by ułatwić sobie wyszukiwanie zmiennych. Opisowe nazwy mają to do siebie, że można je tworzyć na wiele sposobów. Wspominany przez Ciebie parametr przez jednego nazwany będzie jako PredkoscNapedu, przez innego MotorSpeed, przez innego ObrotySilnika a jeszcze przez innego AxisSpeed. Pod jaką literą szukać w takim przypadku? Wiedząc w jakiej strukturze znajduje się zmienna i jaki powinien być jej typ od razu dostajemy przefiltrowaną listę propozycji do przejrzenia. Nie trzeba skakać po programie i szukać przykładu użycia.
W przypadku instrukcji niedopasowanej do typu danych, kompilator oczywiście zgłosi nam błąd. Tylko po co tracić czas? Niekończące się kompilacje z tak błahego powodu? To jest dopiero irytujące.
Wg mnie kod ma być jednoznaczny. Patrząc na zmienną powinienem mieć o niej od razu jak najwięcej informacji. Wiadomo, że nie zawsze udaje się trzymać sztywno zasad. Nie mniej jednak staram się je stosować. Dla mnie absolutnym minimum jest oznaczenie typu wejść i wyjść w bloczkach funkcyjnych.
Co do tego czy artykuł jest ciekawy. Dla mnie nie. Wszystko co się tam znajduję, podobnie jak Ty, już wiedziałem. Trudno by taki poradnik mógł zainteresować starych wyjadaczy.
Artykuł jest skierowany raczej dla mniej doświadczonych automatyków, mam nadzieje że oni znajdą tam coś interesującego.
2 polubienia
Dokładnie tak! Moim zdaniem artykuł spełnia swoje założenie bardzo dobrze. Z pewnością początkujący czytelnicy znajdą coś dla siebie 
i dzięki Ci za zaangażowanie
Nie chcę tutaj być jakimś hejterem . Nie mam żadnego problemu z tym artykułem, więc odpowiem tylko na to, co jest związane z programowaniem.
Napisałeś “Wiedząc w jakiej strukturze znajduje się zmienna i jaki powinien być jej typ” - dla mnie wydaje się nienaturalne znać typ zmiennej.
Przykładowo - chcemy dostać zmienną odpowiadającą za prędkość danego urządzenia, więc potrzebujemy 2 rzeczy odnośnie nazwy: prędkości i nazwy urządzenia. Jak dla mnie te 2 rzeczy powinny być zestandaryzowane i w projekcie prędkość danego urządzenia powinna nazywać się zawsze tak samo: MotorSpeed lub ObrotySilnika lub AxisSpeed lub jakakolwiek inna nazwa, ale taka sama w całym projekcie oraz urządzenie powinno się nazywać tak samo w całym projekcie. Więc jeśli wiem, że moim urządzeniem jest TransporterZaladunkowy, a w projekcie prędkość określam zawsze z przedrostkiem speed to wiem, że muszę szukać speedTransporterZaladunkowy. Rozważając opcję z notacją węgierską mógłbym szukać iSpeedTransporterZaladunkowy lub diSpeedTransporterZaladunkowy lub rSpeedTransporterZaladunkowy lub inne. Biorąc pod uwagę to co pisałeś znamy rodzaj zmiennej - OK ale w takim wypadku po co nam ten przedrostek skoro i tak znamy typ zmiennej. Jeszcze raz podkreślę, że dla mnie wydaje się nienaturalne znać typ zmiennej. Jeśli nie stosujemy konwersji wszystkiego do zmiennej o szerokim zastosowaniu jak np. Real to wracając do jakiegoś projektu po dłuższym czasie możemy mieć dylemat: czy w tym projekcie częstotliwość zadawana na falownik to było Real (50,0) czy Int z przesuniętym przecinkiem (500).
Przyczepię się nieco, ponieważ zauważyłem dwa poważne błędy powyżej!
speedTransporterZaladunkowy
diSpeedTransporterZaladunkowy
Gdyby tak opisywać zmienne w dużym projekcie to zrobiłby się straszny koszmar, po pierwsze w podglądzie zmiennych nie mielibyśmy zgrupowanych danych od danego urządzenia w jednym miejscu, dużo lepiej zastosować TransporterZaladunkowy_Speed lub coś podobnego, dlaczego? Ułatwia nam znalezienie wszystkich zmiennych dla TransporterZaladunkowy.
Druga sprawa, że oznaczenie di sugeruje digital input, a nie double integer i po ujrzeniu “di” na początku na pewno nie sugerowałbym się, że jest to coś innego niż bool.
PS. Pisząc aktualnie oprogramowanie początkowo korzystałem jedynie ze struktur bez oznaczeń typów zmiennych, jak np. Maszyna.ZaworGlowny.Rozkaz.Otworz lecz zrezygnowałem na rzecz oznaczeń typów zmiennych na Maszyan.ZaworGlowny.Rozkaz.bOtworz.
PS2. Najważniejsze jest czytelność, czytelność i czytelność po raz kolejny, nad optymalizację czy szybkość pisania.
2 polubienia
I brawo @unnameduser001 .
Moja główna zasada - po pierwsze priomo - szukam materiałów pomocowych na stronie vendora: manuale, tutoriale, gotowe kawałki kodu do wykorzystania. Potem na forach, bo z ta wiedzą na forach bywa różnie.
1 polubienie
Odnośnie nazw zmiennych “speedTransporterZaladunkowy, diSpeedTransporterZaladunkowy” to pisałem “lub jakakolwiek inna nazwa, ale taka sama w całym projekcie”. To tylko przykład na szybko, a nie proponowany przeze mnie sposób nazywania zmiennych.
Odnośnie przedrostka “di” - nie wiem jaki jest przedrostek na zmienną typu double integer, bo ich nie stosuję, a posta pisałem z głowy.
Jak dla mnie kawał dobrej roboty, pozdrawiam.
1 polubienie