|
Moje LabVIEW treści niespójne stylistycznie |
|
|
Makaron sojowy W ramach notki autorskiej od wariatki z lutownicą: LabVIEW atrakcji wielu mi dostarcza nie tylko w fabryce i samo w sobie jest naprawdę bardzo wdzięcznym narzędziem, są jednak chwile gdy zaczynam pod nosem mruczeć słowa ogólnie uznane na niedyplomatyczne, szczególnie gdy zrobienie najprostszej rzeczy generuje tytułową michę kluchów na ekranie i bez notatek na boku trudno ogarnąć co do czego idzie. Jak w każdej znajomości - od fazy zauroczenia przechodzimy do bliższego poznania i wtedy widać nie tylko zalety, ale i wady, które do tej pory ukrywała ochronna ślepota i opary euforii. Ta strona to w zamyśle opis kilku narowistych przypadków i moich rozwiązań na różne labviowe okazje, którymi podzielić się pragnę, może komuś będzie łatwiej podobny temat ogarnąć. Oczywiście zalecam klauzulę minimalnego zaufania - to że u mnie aplikacja działa, to nie znaczy że tak hop-siup ruszy w obcym środowisku i z innym sprzętem (myślę o peryferiach typu Ardu i kartach pomiarowych, bo też będą :) ). Będzie to tworzone w miarę wolnego czasu i ataków weny twórczej, a póki co można się częstować tym co akurat jest. Kulisy natury sprzętowej Na chwilę obecną występują chińskie Arduino, tak na przekór bzdurnym opiniom wszelkim, że towar z Chinowa to na nic zdający się badziew, a instalacja sterowników CH340 to jakaś makabra. Modułki me pracują z LV idealnie, a skoro cena niewielka to i nie strach wykorzystać w bardziej ryzykownych eksperymentach.       Są Nano i zwykłe Uno-podobne oraz rozszerzenie dedykowane raczej Scratch - taki klon Sensor Board, wszystko to od ➮ Keyestudio. Ładne to, pstrokato kolorowe i co najważniejsze - tanie jak ryż. W dalszej perspektywie pojawi się karta pomiarowa Advantech PCI-1710 z odzysku, z własnoręcznie zrobionym okablowaniem. Zdarza się, że na śmietnik idą całkiem dobre urządzenia, grunt to mieć szczęście i w porę klamot capnąć, ja miałam. I. Obsługa komunikacji szeregowej Demko owe powstało z potrzeby chwili, ot ktoś walczył z odbieraniem danych z gadatliwego urządzenia i jakoś mnie natchnęło. Słowo-klucz na dziś: gadatliwy. Koncepcji na komunikację z urządzeniami jest kilka, można nazwać je ewentualnie jakby wzorcami projektowymi (brzmi profesjonalnie) a dla mnie przynajmniej najważniejsze są dwa podejścia, nazwijmy je - komunikatywne oraz konwersacyjne (dialogowe). Pierwsze z nich polega na tym, że urządzenie w sposób ciągły rozgłasza informację o własnym stanie do otoczenia, robi to przy pomocy aktualnie dostępnych środków (np. RS232/485, IR, sieć) nie bacząc na fakt czy dane są przez kogokolwiek odbierane. Konsekwencją tego jest brak wsparcia dla ewentualnej kontroli przekazu i jego spójności czy choćby ponowień wiadomości w przypadku błędów. To komunikacja w jedną stronę, taka zerojedynkowa cieczka. Zaleta taka, że grono odbiorców może dynamicznie się zmieniać bez wiedzy urządzenia generującego informacje. Wada natomiast, że odbiorcy muszą dostosować się do tempa przyjętego przez stronę nadawczą, tak aby nie utracić ciągłości transmisji ewentualnie być w stanie zaakceptować braki w danych. W praktyce oznacza to także, że w większości przypadków strona odbiorcza musi dysponować nadwyżką mocy obliczeniowej względem nadawcy lub posiadać mechanizmy buforowania napływającego strumienia danych. Kolejna sprawa to taka organizacja aplikacji, aby brak czy przerwy w strumieniu danych i konieczność oczekiwania nie sparaliżowały całości rozwiązania. Drugie podejście, dialogowe, polega na tym, że urządzenie samo z siebie nie generuje ruchu na łączu w kierunku systemu nadrzędnego, natomiast cały czas nasłuchuje i odpowiada (reaguje) tylko wtedy gdy wyrazimy w pobudzeniu takie życzenie. W taki model wpasowują się we wszelkie określenia typu master-slave, request-response czy `speak when spoken to`. Z punktu widzenia systemu nadrzędnego oznacza to konieczność ciągłego odpytywania urządzenia o bieżący stan celem odświeżenia danych i trudność w szybkim reagowaniu na zdarzenia zachodzące na obiekcie, po prostu - aby się dowiedzieć czy cokolwiek się zadziało, to trzeba najpierw zapytać. Oczywiście możliwe są formy pośrednie, łatwo wyobrazić sobie rozwiązanie w którym urządzenie wysyła częste i krótkie notyfikacje o własnym stanie, gdy którąś z nich uznamy za interesującą - wysyłamy do niego polecenie odesłania szczegółowych danych, w większej ilości. I.a Odbieranie danych z wykorzystaniem VISA Events Demko przedstawia komunikację z `urządzeniem pomiarowym` cierpiącym na wzmiankowaną wyżej przypadłość - chroniczny słowotok. Dane numeryczne ubrane w format `xxx|yyy|zzz<CRLF>’ wysyłane są przez łącze szeregowe z szybkością 115 kbaud, odstęp pomiędzy kolejnymi ramkami danych wynosi 50 milisekund, czyli jak widać niezły przeciąg. Kod zupełnie prostej aplikacji dla Arduino dostępny jest tu: ➮ serial-send-auto-1.ino i z prezentacyjnego punktu widzenia generuje dane trzech przebiegów - piły, sinusa i cosinusa, coś na ten kształt:
. . . .
Sprawdzenie działania aplikacji w lokalnym terminalu Arduino IDE: #slowanawiatr, czerwiec 2018/~ |
|
|
 |
|