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
-
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.
-
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.
1 polubienie
- 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.
- 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.
polecam definiować stałe i używać ich zamiast wpisywania czystych wartości liczbowych w miejsca takie jak krok, faza, operacja
2 polubienia