hotdeejay

Python wprowadzenie część IV nabyta. Akurat jest troszkę czasu na naukę czegoś nowego. Dzięki.

Dziękuję za miłe słowa pod artykułem! 🙂 oczywiście, że nie. Ciężko dostać lepszy komplement. Szkoda, że wszyscy nauczyciele nie uczą w taki sposób jak Pan Zelent.

Dla każdego operatora obsługującego zrobotyzowany proces, praca staje się dużo bardziej komfortowa gdy robot wyposażony jest w przyjemny dla oka interfejs. W dzisiejszym artykule przybliżę nieco tworzenie prostej wizualizacji na robocie KAWASAKI. Niestety możliwości robota KAWASAKI nie są tak duże jak paneli operatorskich SIEMENS czy BECKHOFF, nie mniej często wystarcza wykonanie prostej wizualizacji czy okienek do wprowadzania parametrów pracy robota, aby zastąpić kosztowne panele. Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. 1. Wizualizacja procesu – dlaczego nie na głównym panelu do obsługi stanowiska Projektując zautomatyzowane stanowisko pracy, automatyk czy robotyk najczęściej do stanowiska dobiera odpowiedni sterownik PLC oraz panel operatorski. Czasami jednak te elementy są pomijane, ponieważ często proces zrobotyzowany jest na tyle prosty, że nie jest wymagane użycie kosztownych urządzeń peryferyjnych. Bardzo często dla klienta kluczowym aspektem jest cena, a tą niewątpliwie sterownik PLC czy panel operatorski znacząco podwyższa, a nie zawsze można wykorzystać jego pełne możliwości. Poniżej przedstawiono poglądowe zdjęcie panelu robota KAWASAKI. 2. Tworzenie wizualizacji na robocie KAWASAKI Zacznijmy od kluczowego parametru dla każdego projektanta wizualizacji – rozdzielczość ekranu oraz jego rozmiar - 6 cali i 640 na 480 (co przekłada się również na jakość screenów przedstawionych w artykule). Jak widzimy, nie jest to rozdzielczość jaka jest spotykana w najnowszych smartfonach, przekątna ekranu jest na tyle niewielka, że wizualizacja będzie musiała być skromna – należy również pamiętać, że część ekranu wyświetla stałe okna z informacjami o aktualnej pracy robota. Jak większość rozwiązań przemysłowych, ekran jest oporowy więc multitouch też jest nieobecny. 3. Rodzaje przełączników Poniżej zostało przedstawione główne okno panelu robota KAWAKAKI. Jest ono podzielone na trzy mniejsze okienka. Pierwsze pokazuje tryb pracy robota, aktualne prędkości oraz statusy pracy. Drugie z okien ilustruje aktualnie wykonywaną przez robota linijkę kodu (w tym przypadku program nie jest wybrany więc mamy puste miejsce). W ostatnim oknie możemy wybrać dwa dowolne wskazania (z dostępnych mamy na przykład aktualną pozycję robota, sygnały wejściowe, wyjściowe itp.) Aby przejść do okna w którym tworzymy wizualizację, należy kliknąć w niebieski poziomy pasek. Otworzy się nam małe menu, z którego należy wybrać AUX FUNCTION. Następnie należy wybrać Advenced Setting. Na kolejnej karcie wybieramy interesujący nas Interface panel. Poniżej zostało zaprezentowane główne okno służące do konfiguracji panelu użytkownika. Jak widzimy, mamy możliwość stworzenia siatki przełączników i wskaźników – 4 wiersze i 7 kolumn. Mamy również możliwość stworzenia takich 4 kart, a jeśli tego będzie mało, to KAWASAKI przewiduje rozbudowę do 8. Każdą z kart możemy oczywiście nazwać nadając jej stosowny tytuł. Do najczęściej używanych ikon należą: Pilot lamp – lampkę, która będzie zapalać się w zależności od sygnału wejściowego lub wyjściowego; Push Button – przycisk – sygnał będzie podtrzymywany w stanie wysokim tak długo jak długo będziemy go trzymać; Push button with lamp – przycisk jak powyżej, ale możemy dodać lampkę (również od innego sygnału); 2-Notch Sel. Switch – dwustanowy przełącznik 3-Notch Sel. Switch – trzystanowy przełącznik Variable Data Display – umożliwia wyświetlanie zmiennych numerycznych, jak również ich wprowadzanie String Windows – umożliwia wyświetlanie zmiennych tekstowych 4. Utworzenie przełącznika Utwórzmy prosty włącznik. Aby to uczynić, kliknijmy w dowolne okienko (będzie to miało wpływ na to, w którym miejscu na ekranie będzie wyświetlała nam się dana włącznik) i wybierzmy wartość 4 i potwierdźmy to przyciskiem enter. Pokaże nam się okno do konfigurowania naszego przełącznika – najprostsza konfiguracja obywa się poprzez wpisanie numeru koloru w danym oknie, nadania nazwy oraz przypisania numeru sygnału. Wprowadźmy przykładowe dane. Zapiszmy konfigurację klikając enter i sprawdźmy jak wygląda nasz przycisk. Oczywiście naciskając na ekran dotykowy panelu robota KAWASAKI zmieniamy stan przycisku z jednego na drugi, co powoduje ustawienie sygnału wyjściowego na stan wysoki lub niski. Skonfigurujmy druga ikonę, która będzie umożliwiała operatorowi zmianę prędkości spawania robota dla danej spoiny. Wybierzmy więc wartość 8 i skonfigurujmy ją przykładowo. Potwierdźmy przyciskiem enter i zobaczmy jak wygląda nasze okienko do wprowadzania wartości. Klikając na okienko mamy możliwość wprowadzenia liczby typu real opisanej jako dwa znaki (tak skonfigurowaliśmy), wartość ta odnosi się do zmiennej rWeldSpeed. Należy pamiętać, że w robocie KAWASAKI zdecydowana większość zmiennych (99%) to zmienne globalne. Po potwierdzeniu wpisanej liczby przyciskiem enter, zmienna rWeldSpeed przyjmuje nową wartość zgodnie z tym co wprowadziliśmy. 5. Eksport panelu HMI do pliku wynikowego Oczywiście nic nie stoi na przeszkodzie, aby wyeksportować utworzony panel HMI do pliku tekstowego. Poniżej przykładowa konfiguracja panelu. Poniższy kod możemy wgrać do robota KAWASAKI, co spowoduje pojawienie się panelu na odpowiednich kartach. .INTER_PANEL_D 24,8,"gigri_measure","czujnik","pomiar",12,0,5,2,0 25,8,"ncycle","czas","cyklu [s]",12,0,3,2,0 29,3,"reset","pamieci","chwytaka","",12,4,0,0,0,2004,2004,0 30,4,1,"turbo","booster","","",12,4,0,2005,0,0 46,3,"sygnal","pausy od","plc","",12,4,0,0,0,0,1347,0 .END .INTER_PANEL_TITLE "",0 "",0 "",0 .END .INTER_PANEL_COLOR_D 182,3,224,244,28,159,252,255,251,255,0,31,2,241,52,219, .END 6. Podsumowanie Jak widać, w prosty sposób możemy przygotować interfejs dla operatora naszego robota. W przypadku polityki firmy KAWASAKI funkcja umożliwiająca tworzenie takiej wizualizacji jest całkowicie bezpłatna, co jest dodatkowym atutem. Rozwiązania konkurencji w kwestii wizualizacji potrafią kosztować powyżej 4 tysięcy Euro za jedną licencję. 7. Linki http://www.cnc-shopping.co.uk/kawasaki-50817-1347-60337-1201-teach-pendant-robot-p-8717.html

Reguła KISS, DRY oraz inne zasady dobrego programowania Reguła KISS (ang. Keep It Simple, Stupid), dosłownie zrób to prosto, idioto – Prostota (i unikanie złożoności) powinna być priorytetem podczas programowania. Kod powinien być łatwy do odczytania i zrozumienia wymagając do tego jak najmniej wysiłku. Większość systemów działa najlepiej, gdy polegają na prostocie, a nie na złożoności. Należy się więc starać, aby nasz kod podczas analizy nie zmuszał do zbytniego myślenia. Gdy po jakimś czasie do niego wrócimy i nie wiemy co tam się dzieje, to znak, że musimy nad tym popracować. Dobrą metodą jest również pisanie naszych programów raz jeszcze gdy już poznaliśmy dokładnie proces, wprowadziliśmy wszystkie zmiany jakie zgłosił nam klient w trakcie odbioru oraz po wyprowadzeniu wszystkich początkowych błędnych założeń w trakcie programowanie offline. Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2 DRY (ang. Don't Repeat Yourself, pol. Nie powtarzaj się) – reguła stosowana podczas wytwarzania oprogramowania, zalecająca unikanie różnego rodzaju powtórzeń wykonywanych przez programistów - na przykład unikanie tych samych czynności podczas kompilowania, unikanie wklejania (lub pisania) tych samych (lub bardzo podobnych) fragmentów kodu w wielu miejscach. Wielokrotne użycie tego samego kodu to podstawa programowania (Zmiana implementacji tylko w jednym miejscu oraz lepsza czytelność kodu oraz łatwość w utrzymaniu). Code for the Maintainer – czyli programuj tak jakbyś to robił dla osoby, która będzie później utrzymywać ten kod. Praca przy cudzym kawałku kodu to (przeważnie) najbardziej wymagająca i największa część pracy każdego programisty. Nie powinniśmy utrudniać sobie tego zadania. Zadbajmy więc o to, aby nie trzeba było się zbytnio głowić nad kawałkiem Twojego kodu. Pisz kod w taki sposób w jakim chciałbyś go otrzymać od kolego po fachu. Boy scout rule – zawsze pozostaw po sobie kod czystszy niż go zastałeś. REP - Reuse-release equivalence principle – ponowne użycie kodu to nie kopiowanie funkcji czy podprogramu z jednego projektu do drugiego. Jeżeli chcemy użyć ponownie kod, to należy go wydzielić do biblioteki, którą później możemy użyć ponownie. Klasy oraz funkcje, które są przeznaczone do ponownego wykorzystania, powinny być w jednej paczce, aby mogła stać się reużywalną biblioteką. Nie powinny się tam znaleźć te, które nie są przeznaczone do ponownego wykorzystania. W skrócie - albo wszystkie są reużywalne, albo żadne. Zdecydowanie ułatwi to edycje biblioteki oraz rozbudowę. Nie zawsze zasada KISS lub DRY jest słuszna! Weźmy np. zasadę DRY – Don’t Repeat Yourself – piszemy kod, który jest reużywalny, nie powtarzamy logiki zawartej w jednym miejscu w aplikacji, w innym. Tylko, że z tego rodzą się czasem klasy czy funkcje potwory. Okazuje się, że mają wiele rozglłęzień, skomplikowaną strukturę – tylko po to, żeby nie powtórzyć się w innym miejscu. I tu mamy problem – jest to świadome naginanie reguły KISS – Keep It Simple Stupid – która mówi o tym, żeby kod był tak prosty, jak to tylko możliwe. Wniosek nasuwa się jeden – nie istnieje srebrna kula. Nie istnieje też żaden złoty środek. Nie ma idealnego scenariusza, w którym weźmiemy garść złotych myśli (nasze reguły) i mamy gotowy przepis na sukces. Trzeba pamiętać o tym, żeby nie mieć klapek na oczach. Należy umiejętnie żonglować poszczególnymi zasadami, żeby osiągnąć satysfakcjonujący, końcowy rezultat. Zasady tylko wspomagają nas jako programistów, są narzędziem, które musimy umiejętnie wykorzystać. Zmiana osoby w projekcie a jakość kodu – jaki ma to wpływ na projekt i dochód? Wraz ze wzrostem bałaganu w oprogramowaniu niewątpliwie spada efektywność zespołu, co w znacznym stopniu paraliżuje projekt. Wobec spadku efektywności osoba odpowiedzialna za dany projekt zwykle dodaje do projektu więcej osób w nadziei, że podniesie to wydajność zespołu i uda się wyprowadzić problem tak, aby klient odebrał oprogramowanie. Jednak nowe osoby nie są zaznajomione z projektem oraz procesem jaki się tam odbywa, zasadą działania współpracujących ze sobą klas, czujników itd. Nie wiedzą, na jakie zmiany projektu mogą sobie pozwolić, a jakie spowodują jego naruszenie czy też zaprzestanie działania innych części kodu projektu. Dodatkowo, tak jak wszyscy pozostali w zespole, są pod ogromną presją zwiększenia wydajności swojej pracy, często w nadgodzinach czy dniach dla nich domyślnie wolnych. Należy tutaj pamiętać, że praca programisty to nie to samo, co człowieka na produkcji. Efektywność programisty to ok 6 godzin na dobę, ponieważ jest to praca umysłowa, wymagająca skupienia oraz kreatywnego myślenia. Należy mieć również na uwadze fakt, że to nie kierownictwo, ale programista jest fachowcem w programowaniu i zarządzaniu kodem i to programista musi umieć wywrzeć na swoich przełożonych świadomość jak ważny jest czysty kod. Nic nie ma tak głębokiego i w długim czasie degradującego wpływu na prowadzenie projektu, jak zły kod. Po pierwszym nieudanym projekcie spowodowanym złym kodem, lider projektu powinien wyciągnąć wnioski, aby zapobiec podobnym sytuacjom w przyszłości. Jednym z działań mającym zapobiegać bałaganowi w kodzie jest refaktoryzacja. Spowoduje to wprawdzie dodatkowe obłożenie czasowe (refaktoryzacja jest kosztowna czasowo, ale jest istotnym elementem zarządzania projektem informatycznym), które należy wziąć pod uwagę w trakcie ustalania harmonogramu projektu, ale zmniejsza prawdopodobieństwo pisania całego kodu od nowa. Podsumowanie Podsumowując, nie istnieje coś takiego, jak szablon dobrych zasad projektowania. Styl pisania kodu należy dostosować do projektu jaki jest tworzony, jego zagadnień czy problematyki – należy jednak być w tym bezwzględnie konsekwentnym. Jeśli będziemy w taki sposób pracować, efektywność naszej pracy będzie stale rosnąć. Jeśli czytelnik artykułu jest początkującym programistą, to stosując powyższe metody zoptymalizuje i uporządkuje swój kod, a co za tym idzie, jego projekty będą bardziej satysfakcjonujące i być może dzięki temu stanie się zawodowym programistą czego z całego serca życzę. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2 Bibliografia: Martin R. - Czysty kod. Podręcznik dobrego programisty https://pl.wikipedia.org/ https://i1.wp.com/blog.knoldus.com/wp-content/uploads/2018/06/cleancode.png?fit=743%2C656&ssl=1 https://www.wykop.pl/cdn/c3201142/comment_kIUd4zw6h9I4Wt4s2yRz977DpSEBAUOv.jpg https://i.ytimg.com/vi/Fevz-Kb4bxc/maxresdefault.jpg https://cdn5.vectorstock.com/i/1000x1000/77/09/clean-code-vector-4247709.jpg https://www.perforce.com/sites/default/files/image/2019-09/image-blog-social-writing-clean-code_0.png https://3.bp.blogspot.com/-lcAjDyJMDzw/UpOnmQVcPyI/AAAAAAAALYQ/Zqf4yEU-z-s/s640/good_code.png https://1024kb.pl/wp-content/uploads/2018/08/var-1024x516.png https://res.cloudinary.com/teepublic/image/private/s--yz3dO1aO--/t_Resized Artwork/c_fit,g_north_west,h_954,w_954/co_ffffff,e_outline:48/co_ffffff,e_outline:inner_fill:48/co_ffffff,e_outline:48/co_ffffff,e_outline:inner_fill:48/co_bbbbbb,e_outline:3:1000/c_mpad,g_center,h_1260,w_1260/b_rgb:eeeeee/c_limit,f_jpg,h_630,q_90,w_630/v1536857572/production/designs/3150589_0.jpg https://ronjeffries.com/xprog/wp-content/uploads/Photo-Dec-07-1-45-14-PM.jpg https://i0.wp.com/image.slidesharecdn.com/cleancode-110520031623-phpapp02/95/clean-code-5-728.jpg?w=584&ssl=1 https://cloudogu.com/images/blog/2018/CleanCode_TheartofProgramming.jpg https://slideplayer.com/slide/12686823/76/images/6/What+is+clean+code+Clean+code+can+be+read%2C+and+enhanced+by+other+developers.+It+has+meaningful+names..jpg https://octoperf.com/img/blog/are-you-buying-quality-software/clean-code.png https://media.makeameme.org/created/clean-code-clean.jpg https://image.slidesharecdn.com/cleancode-vortrag-03-2009-pdf-121006112415-phpapp02/95/clean-code-pdf-version-5-728.jpg?cb=1349523162 https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/cde14740-68df-45f4-ab1f-e36ee4f16a47/cleancode-7.png

Wstęp Jeśli sięgnąłeś po ten artykuł, to prawdopodobnie jesteś programistą, a co więcej, chcesz być lepszym programistą! To bardzo dobrze, ponieważ rynek IT potrzebuje lepszych programistów, a wytwarzanie czystego kodu według przyjętych standardów programowania jest zdecydowanym krokiem w tę stronę. Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. Czym właściwie jest czysty i dobry kod? Na to pytanie nie ma jednoznacznej odpowiedzi. Istnieje jednak zbiór pewnych reguł i narzędzi, które skutecznie wspomogą pracę programisty, a stosowane w całym zespole, polepszą jego efektywność i skuteczność. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2 Jak więc tworzyć oprogramowanie pozbawione błędów? Podstawową regułą jest stosowanie właściwie dobranych nazw opisujących zmienne, funkcje czy struktury – jeśli kwestia ta nie jest spełniona, to żadna konwencja nie zda egzaminu. Nazwa taka powinna być odpowiedzią na wszystkie ważne pytania – w jakim celu istnieje, co robi, jakiego jest typu i jak jest używana. Jeżeli nazwa zmiennej wymaga komentarza, to znaczy, że nie ilustruje swojej intencji (dobry kod jest samokomentujący!). Przedrostki określające typy zmiennych Przykładowe przedrostki określające typy zmiennych: diGripperOpen – cyfrowy sygnał wejściowy mówiący, że chwytak jest otwarty; doGripperOpen – cyfrowy sygnał wyjściowy mówiący, aby chwytak został otwarty; aiTemperatureSensor – analogowy sygnał wejściowy czujnika temperatury; giTemperatureSensor – grupowy sygnał wejściowy czujnika temperatury (cyfrowy sygnał zakodowany na przykład na 16 bitach); nIndex – zmienna typu int zawierająca dane licznikowe; rRadius – zmienna typu real zawierająca promień; bMP3Module_On – zmienna typu bool informująca o załączeniu modułu mp3; Nie bądźmy dowcipni (ale tylko w kodzie ;d) Jeżeli nazwy są dowcipnymi określeniami, mogą być zapamiętane wyłącznie przez osoby z identycznym co autor poczuciem humoru i tylko dopóki dane określenie nie wyjdzie z mody. Nazwa zmiennych i funkcji powinny odzwierciedlać ich znaczenie. Dowcipne hasła z najnowszego standupu Rafała Paczesia zostawmy na integrację po pracy. Jedno słowo na pojęcie Należy stosować zasadę jedno słowo na jedno abstrakcyjne pojęcie i trzymać się jej w całym swoim programie. Na przykład diHumiditySensor. Nie twórzmy zgadywanek! Należy unikać używania różnych określeń do jednego celu. Powoduje to brak jednoznaczności. Czujnik zmierzchu oprogramowany w kodzie musi mieć jedną nazwę – używanie zamiennej terminologii jak czujnik optyczny, czujnik zmierzchu czy czujnik zmierzchowy powodują tylko bałagan w kodzie. Jeśli w systemie, który programujemy mamy kilka czujników, dla ich rozróżnienia nazwijmy je zgodnie z ich rolą i lokalizacją – nie stosujmy na przykład: aiHumiditySensor, aiMoistureSensor, aiWetnessSensor a na przykład aiHumiditySensor_Room, aiHumiditySensor_Kitchen, aiHumiditySensor_Bathroom. Dodajmy znaczący kontekst Jeśli mamy grupę danych, możemy posłużyć się różnymi zabiegami (w zależności od możliwości języka w jakim programujemy), aby panował w nich ład i porządek, grupując np. dane adresowe jako addrFirstName, addrLastName, addrState i tak dalej. Dzięki temu inni programiści będą wiedzieli, że zmienne te są częścią większej grupy danych. Możemy również użyć struktury, klasy – wszystko w zależności od języka programowania. Stosujmy terminologię klienta Jeśli tylko to możliwe, to do nazewnictwa zmiennych stosujemy terminologie klienta – jeśli istnieją dwa lub więcej terminów klienta na jedno pojęcie, wybieramy jedno i konsekwentnie się do tego stosujemy. Na przykład jeśli programujemy system do zarządzania produkcją u klienta, który wytwarza pakiety baterii z ogniw, używajmy zmiennych nBatteryIndex, bBatteryPresent itd. Podsumujmy dobre nazwy w kodzie przedstawiają intencje; bez mylących i fałszywych wskazówek; bez zbyt subtelnych różnic; są spójne; można je wymówić; łatwo je wyszukać; nazwy zmiennych mają rzeczowniki; nazwy funkcji mają czasowniki; dowcipne nazwy mogą nie być zrozumiane; dodajemy znaczący kontekst; nazwy zmiennych, funkcji, podprogramów w języku angielskim; zmiana nazwy na czytelniejszą to nic złego. Stosujmy dobry, konsekwentny styl Jak zapewnić tę czytelność? Po pierwsze: nazwy - zmiennych, stałych, funkcji, klas, metod, struktur itd. Każda nazwa powinna być znacząca, chyba że ma marginalne znaczenie. Jednoliterowe nazwy mogą się nadawać do zmiennych tymczasowych, takich jak np. zmienne pętli, ale tylko i wyłącznie wtedy. Nazwy powinny odzwierciedlać zastosowanie – zmienna przechowująca indeks tablicy może nazywać się „index”, a funkcja dodająca do siebie dwie liczby – „add”. Trudno się nie zgodzić, że są to o wiele czytelniejsze nazwy niż np. „dupadupacycki” czy „qwert”. Jeśli chodzi o dokumentację i komentarze, to lepiej jest używać długich nazw zmiennych (o ile dany język programowania na to pozwala), procedur, programów i funkcji, które dobrze określają ich znaczenie, zamiast używać krótkich nazw i zaopatrywać ich długim komentarzem. Poza tym długie nazwy pomagają w przypomnieniu sobie działania programu jeśli zaglądamy do niego po długiej przerwie. Jaki sens mają szczegółowe komentarze? Nie powinno się pisać kodu wyłącznie czytelnego, bądź wyłącznie optymalnego. Kod powinien być zrównoważony i wypośrodkowany – na tyle zoptymalizowany na ile nie straci na czytelności. Argument czytelności można w ogóle pominąć dopiero wtedy gdy wydajność kodu jest niewystarczająca, jednak wtedy należy taki kod opatrzyć stosownym komentarzem. Komentarze – kiedy nie mają sensu? Niewiele jest rzeczy tak pomocnych, jak dobrze umieszczony komentarz. Jednocześnie nic tak nie zaciemnia modułu, jak kilka zbyt dogmatycznych komentarzy. Nic nie jest tak szkodliwe, jak stary komentarz szerzący kłamstwa i dezinformację. Komentarze nie są szminką dla złego kodu! Jednym z często spotykanych powodów pisania komentarzy jest nieudany kod. Napisaliśmy funkcję i zauważamy, że jest źle zorganizowana. Wiemy, że jest chaotyczny. Mówimy wówczas: „Hm, będzie lepiej, jak go skomentuję”. Nie! Lepiej go poprawić! Precyzyjny i czytelny kod z małą liczbą komentarzy jest o wiele lepszy niż zabałaganiony i złożony kod z mnóstwem komentarzy. Zamiast spędzać czas na pisaniu komentarza wyjaśniającego bałagan, jaki zrobiliśmy, warto poświęcić czas na posprzątanie tego bałaganu i poprawić nasz kod - czytelny kod nie wymaga komentarza. Komentarze – kiedy mają sens? W wielu przypadkach stosowanie komentarza jest jak najbardziej słuszne. Często musimy zastosować komentarz prawny z powodu korporacyjnych standardów klienta. Czasami przydatne jest umieszczenie w komentarzu podstawowych informacji – na przykład typu czy informacji o wartości zwracanej zmiennej i wtedy warto zawrzeć taką informację w komentarzu informacyjnym. Na etapie projektowania często praktyką są komentarze TODO jako notatki zagadnień, które pozostały jeszcze „do zrobienia”. Formatowanie kodu Pamiętajmy, że kod powinien być ładnie sformatowany. Należy wybrać zbiór prostych zasad, które rządzą formatowaniem kodu, a następnie w konsekwentny sposób je stosować. Jeżeli pracujemy w zespole kilku programistów, to wszyscy jego członkowie powinni przyjąć zbiór zasad formatowania i stosować się do nich. Bardzo dobrą praktyką jest stosowanie pionowych odstępów pomiędzy segmentami kodu oraz wcięć – do poszczególnych programów w pliku, do funkcji i bloków funkcji. Z naszego programu należy również usunąć cały martwy kod – to znaczy taki, który nigdy nie jest wykorzystany (na przykład kontrolują go nigdy niespełniane warunki) lub taki, który mógł służyć jedynie do testów. Zamiast stosować magiczne liczby, użyjmy stałych nazywanych – na przykład liczba 86 400 powinna być ukryta w stałej SECONDS_PER_DAY. Jeżeli wyświetlamy 70 wierszy na stronę, to liczba 70 powinna być ukryta w stałej LINES_PER_PAGE. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2

Witam, potrzebuję odpowiedzi na następujące pytanie. Potrzebuję wykonać urządzenie do ładowania akumulatora samochodowego z innego akumulatora (np Żelowy Aku 12V 14A). Chciałem do tego wykorzystać po prostu przetwornicę DC-DC podwyższającą napięcie do powiedzmy 14,5V i podłączeniu tego do akumulatora samochodowego. Czy wystarczy jakaś przetwornica jakich pełno na znanym serwisie aukcyjnym o wydajności ok 2-4A? Prąd jaki pójdzie na przeładowanie to pewnie max 10A więc nie potrzeba chyba żadnych układów kontrolujących napięcie? Chodzi mi o efekt, że jeśli aku samochodowy będzie rozładowany do poziomu, że światła, radio itp działa, ale ledwo kręci, to aby po ok godzinie ładowania dało się odpalić auto. Proszę o odpowiedź na powyższe pytanie pomijając sensowność takiego rozwiązania i rady typu "kupić inny akumulator, wyłączyć urządzenia co zużywają prąd itp". Z góry dzięki

shild jest w oparciu o akumulatory li pol, które powinny pracować w cyklach ładowanie, rozładowanie. Temat przejrzałem na szybko, bo sam miałem podobny problem, zastosowałem to co opisałem i wszystko ładnie działa, stąd propozycja. Oczywiście sprawdzić czy jest zasilanie można na kilka sposobów, zastosowanie przekaźnika to jeden z nich.

akumulatory jakie są w zaproponowanym shildzie nie nadają się do pracy buforowej. Idealnym rozwiązaniem dla autora jest zasilacz buforowy na 12V wraz z akumulatorem żelowym (takimi jakie są w UPS) + przekaźnik zwarty gdy jest prąd, rozwarty gdy prądu nie ma (informacja dla arduino, żeby przeszedł w tryb bardziej oszczędny jeśli może).