Ten artykuł jest trochę mniej o robotyce dla nieinżynierów. Ogólnie jest trochę mniej dla nieinżynierów, ale postaram się ubrać go w taki język, żebyśmy wszyscy mieli frajdę, czytając go.
LabView jest graficznym środowiskiem programowania, stworzonym przez firmę National Instruments. W odróżnieniu od tradycyjnych metod programowania, to w LabView polega na wstawianiu na pulpit różnego rodzaju ikon funkcji, pętli etc. Każda z nich posiada indywidualne wejścia i wyjścia i połączone są między sobą-to z kolei determinuje kolejność wykonania programu: we->wy. Docelowo stworzone zostało dla naukowców i badaczy rozwiązujących różne problemy, wykorzystywane między innymi w CERNie i NASA.
Do części zasadniczej przystąpmy.
1. Nadużywanie poziomów sekwencyjnych.
Co to oznacza ? A no to, że wielu początkujących nie do końca rozumie idee wykorzystywania pętli i tego, co z nich uzyskujemy (macierze 1D, 2D, 3D). Ponadto powoduje to spore obciążenie procesora, a wiele z tych operacji wykonanych może zostać w pominięciem pętli lub z mniejszą ich ilością równolegle. Warto zwrócić na to uwagę, ponieważ przy bardziej złożonych problemach może to być mocno odczuwalne.
2. Nadużywanie zmiennych lokalnych.
Ten problem dotyka chyba programistów każdego środowiska, nie tylko LabView. Jednak w normalnych językach programowanie zmienne lokalne są raz użyte i usunięte. W LabView, przez jego równoległą strukturę programowania, są one po prostu pamięciożerne i nic nie daje ich każdorazowe tworzenie.
3. Ignorowanie modułowości kodu
Wielu początkujących użytkowników środowiska tworzy proste programy, a potem po prostu je wyrzuca. Pamiętać należy jednak o tym, że LabView daje możliwośś tworzenia modułów na podstawie utworzonych programów, więc jeśli wiemy, że jakiś fragment kodu może nam być w przyszłości przydatnym warto skorzystać z tej opcji, zamiast każdorazowo wykonywać go od nowa.
4. Tworzenie masywnych diagramów blokowych
Wielu użytkowników nie ma jeszcze swojego stylu tworzenia diagramów lub po prostu ich styl nie jest zbyt wydajny. Konsekwencją takiego podejścia są bardzo "ciężkie" i nieefektywne programy. Aby temu zapobiec, warto zaznajomić się z gotowymi przykładami, dostarczonymi przez National Instruments (Simple State Machine)
5. Pomijanie potrzeb dokumentacyjnych
Ważny element. Często programy powstają pod wpływem różnego rodzaju deadline'ów, kawy i zapałek na powiekach. Są to te momenty, kiedy nawet po sukcesie programistycznym, często po porannej pobudce nie do końca jesteśmy w stanie określić dokładnie sposób działania poszczególnych bloczków, ale i całego programu. Właśnie w celu zapobieżenia takim sytuacjom warto jednak przysiąść nad dokumentacją, dzięki której sami będziemy mieli sporo łatwiej, a i inni będą mogli z łatwością odtworzyć i zrozumieć nasz program.
Brak komentarzy:
Prześlij komentarz