[AD2][LabVIEW] Analog Discovery 2 vs LabVIEW, bezpośredni zapis danych do Elasticsearch, Kibana w tle

Tutaj umieszczamy tematy związane z językami programowania niepasującymi do innych działów.
Regulamin forum
Temat prosimy poprzedzić nazwą języka umieszczonego w nawiasach kwadratowych np. [Pascal].
Awatar użytkownika
tasza
Expert
Expert
Posty: 988
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

[AD2][LabVIEW] Analog Discovery 2 vs LabVIEW, bezpośredni zapis danych do Elasticsearch, Kibana w tle

Postautor: tasza » czwartek 04 lip 2019, 20:56

♬ ☘ Moja muzyka do kodowania ♬ ♬ ♬ ☘
♫ ♩ ♪ KAT ⚡ ☘ ⚡ Łza Dla Cieniów Minionych ♪ ♩ ♫
https://youtu.be/pofHffhzd_Q


Nooo, lektura lipcowej Poczty EdW dała mi do myślenia, że niby programowania było w gazetce za dużo? I że LabVIEW też? No faktycznie, bazgroły o LV nie mają startu do opisów palenisk i wspomnień z technikum za czasów PRL, prawda to.
Tak więc tutaj swobodna kontynuacja napoczętego kiedyś tematu obsługi puderniczki AD2 w moim ulubionym LabVIEW, w ramach ciekawostek zagonimy także do pracy oprogramowanie Elasticsearch i jego graficzne opakowanie - Kibanę.

Na początku garść linków, co automatycznie zwolni mnie z detalicznego opisywania każdej użytej w demku kostki:

:arrow: Getting Started with LabVIEW and Analog Discovery 2
:arrow: WaveForms vs LabForms Part 1
:arrow: WaveForms vs LabForms Part 2
:arrow: DIY ECG Using a Analog Discovery 2 and LabVIEW
:arrow: JSON Serialization & Deserialization Library for LabVIEW
:arrow: HTTP REST Client Library for LabVIEW


Z zestawem komponentów do AD2/WaveForms wystąpił pewien smuteczek, a mianowicie Digilent połknięty przez firmę National Instruments zaczyna powolutku uprawiać politykę nagonki na co raz to nowsze wersje LV. Osoby, które ciągle pracują z wersją LV 2014 Home Bundle i nie upilnują, aby skompletować sobie starsze, natywne dla tej wersji zestawy kostek i przykładów zostają nagle z ręką w majtkach - starszych wersji na stronach już nie ma, a LV2014 nowszych z reguły nie potrafi poprawnie otworzyć - vide rysunek poniżej.

01_bad_version.png


Taka właśnie zaskoczka spotkała mnie przy plikach przykładów do AD2/WaveForms. O ile komponenty pobrane z repozytoriów National Instruments (via VI Package Manager) pasują do wersji i pracują poprawnie, to przykładów tam już dali. A te z for NI są pod wersję 2015. I brzdęk.
W załączniku podzielam się wynikami szybkiej konwersji VI-ek, macie spakowany firmowy komplet. To robi się tak, że na czystej kopii Win7 pod VirtualBox instaluje się LV2019, NI-VISA i WaveForms od Digilenta. LV jest oczywiście w wersji próbnej ale co tam i tak zaraz idzie do piasku. No i pracowicie wołamy po kolei File->Save for previous version.

Na początek drobne eksperymenty, jak wstawiać rekordy bezpośrednio do Elasticsearch. Sztuczka nie jest skomplikowana, ale trzeba poświęcić nieco uwagi na spreparowanie poprawnego strukturalnie JSON-a, do które źródłem danych pomiarowych jest niezdzieralny MCP9700 oraz fotoogniwo z lampki solarnej za 3 zł, z Castoramy.

03_IMG_5781.JPG


Próbny diagram poniżej, operacja HTTP POST wykonywana jest do dwóch rozłącznych indeksów o nazwach ad2daq-temperature-* oraz ad2daq-light-*. Struktura danych jest identyczna - pola: value, @timestamp oraz sensor. No i zasadniczo to ładnie działało, choć generowało pewne problemy z korelacją danych w Kibanie. Do zapamiętania z rysunku powyżej jest klocuszek `Flatten to JSON`. Kostka potrafi skonwertować klaster wejściowy o zdefiniowanej typem strukturze na string JSON, jest fajna i oszczędza upierdliwych operacji na napisach.
Druga rzecz, już mniej fajna to konieczność wprowadzenia bokiem danych do autoryzacji, widać fragment tabeli z nagłówkiem HTTP Authorization/Basic wprowadzonej do komponentu JKI HTTP POST. No więc Elasticsearch sam w sobie spokojnie wspiera mechanizm preemptive authentication, tylko kostki JKI REST mają z tym jakiś problem bo gdy podawałam po bożemu user/password to kończyło się to klasycznym 403/forbidden. Podejrzewam, że JKI czeka na status HTTP 401 i dopiero wtedy wysyła dane logowania. W sumie szkoda dociekać i lepiej dostawiać logowanie dodatkowym nagłówkiem, tylko wypadałoby ubrać to w ładny klocuszek konwertujący dane do base64 itp, żeby nie było wioski.

02_lv_elastic.png


Kolejne demko to już kompletna aplikacja do akwizycji danych o temperaturze i poziomie oświetlenia. I kolejna zmiana koncepcyjna we wstawianiu danych do Elastica - tym razem dane o świetle i temperaturze są w jednej paczce, konfekcjonowanie danych w jednym indeksie ad2daqcpx-*.
Obsługa AD2 chyba nie stanowi tu specjalnej zagadki - wykorzystuję dwa bloki puderniczki: zasilacz (PWS) oraz oscyloskop (MSO). Oba bloki są konfigurowane jednocześnie, mogę sobie na to pozwolić, ponieważ te kostki korzystają z rozłącznych handlerów. W przypadku zasilacza może tylko uwaga: na zakończenie aplikacji dobrze jest wykonać na nim operację wyłączenia, inaczej AD2 może generować napięcie aż do fizycznego zamknięcia LabVIEW.
Obsługa MSO także prosta jest - ustawiamy oba kanały mso/1 oraz mso/2 w tryb DC i na zakres 5V. Samplowanie przyjmijmy że 20kHz i jednosekundowy czas zbierania danych. I w ten sposób, po wyzwoleniu pomiaru w pętli głównej aplikacji kostka DWF MSO Read zwróci nam dwuwymiarową tablicę z próbkami do dalszej analizy. Tu nieco matematyki na poziomie liceum - Basic Averaged DC-RMS - z kostki pobieram sobie uśrednione wartości pracowicie zebranych przez AD2 próbek. No i dalej wiadomo - na miernik wskazówkowy, termometr i wysyłka do Elasticsearch znaną już metodą. Diagram i panel dema poniżej:

04_ad2-mcp9700-fotop.gif

05_ad2-mcp9700-fotod.gif


Jednej rzeczy w tym wszystkim brakuje - obsługi odpowiedzi z Elasticsearch, pominęłam aby nie motać bardziej diagramu. Ta aplikacja pisze raz na kilka sekund, ale bardziej żwawe i gadatliwe rozwiązanie mogłoby zwyczajnie przeciążyć interfejs HTTP Elastica, który sam z siebie nie kolejkuje danych (od takich spraw ma m.in. Logstash-a lub Kafkę /o tym kiedyś/).

Aplikacja chwilę sobie popracowała - od popołudnia, cała nocka, wyłączenie o poranku. Widać jak niewiele zmieniała się temperatura (czujnik przeniesiony na parapet balkonowy), za to ładnie widać zmiany oświetlenia (słońce >2V, nocka pojedyncze mV).

06_kibana_T_L.png


No i oczywiście filmik z nawigacji po danych oraz klecenia wizualizacji na kolanie, polecam zabawę.

https://youtu.be/bGAD1YxCf14

#slowanawiatr
Nie masz wymaganych uprawnień, aby zobaczyć pliki załączone do tego posta.
______________________________________________ ____ ___ __ _ _ _ _
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)

Awatar użytkownika
GrumpyRez
User
User
Posty: 107
Rejestracja: poniedziałek 04 cze 2018, 09:19

Re: [AD2][LabVIEW] Analog Discovery 2 vs LabVIEW, bezpośredni zapis danych do Elasticsearch, Kibana w tle

Postautor: GrumpyRez » piątek 05 lip 2019, 07:39

Może czytelnicy EP będą bardziej wdzięczni za podobny cykl, mimo wszystko EdW to cały czas dla początkujących jest. W EP artykuł by poszedł jak świeże bułeczki.

Pióro masz lekkie, a wiedzy dużo. Zdecydowanie uderzał bym w EP, lub nawet w elektronik.

Awatar użytkownika
tasza
Expert
Expert
Posty: 988
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [AD2][LabVIEW] Analog Discovery 2 vs LabVIEW, bezpośredni zapis danych do Elasticsearch, Kibana w tle

Postautor: tasza » środa 10 lip 2019, 22:54

♬ ☘ Moja muzyka do kodowania ♬ ♬ ♬ ☘
♫ ♩ ♪ KAT ⚡ ☘ ⚡ Głos z Ciemności ♪ ♩ ♫
https://youtu.be/oV1PjofKKCI



W ramach rozwinięcia tematu bezpośredniego wstawiania danych do Elasticsearch przedstawiam taką oto prostą instalację testową do szacowania wydajności - aplikacja LV jako generator danych, EL - odbiorca, Kibana oczywiście do wizualizacji.

Diagram aplikacji widzimy poniżej i zwyczajowo komentarz co do czego idzie.

lv__elastic__insert__1d.gif


Zacznijmy od struktury komunikatu wejściowego dla Elasticsearch - to prosty rekord o trzech polach:

test.json pisze:

Kod: Zaznacz cały

{
  "@timestamp": "2019-07-07T11:22:33.444Z",
  "dblTemperature": 66.6,
  "dblCellVoltage": 12.3
}


Odpowiedzią EL na wysłanie tegoż metodą HTTP POST pod URI: /__index__/_doc jest taki przykładowy komunikat zwrotny:

elasticsearch response message pisze:

Kod: Zaznacz cały

{                                 
  "_index": "ad2test-2019.07.07",
  "_type": "_doc",               
  "_id": "RgV33WsBUz6Of5bPzAGx", 
  "_version": 1,                 
  "result": "created",           
  "_shards": {                   
    "total": 2,                   
    "successful": 1,             
    "failed": 0                   
  },                             
  "_seq_no": 26529,               
  "_primary_term": 2             
}                                 


Cytuję JSON-ki ponieważ operować będziemy nimi w aplikacji LabVIEW, a ich przygotowanie i interpretacja choć proste, to wymagają drobnych zabiegów. Diagram działa następująco: klaster wejściowy [2] o narzuconej przez definicję [1] strukturze wprowadzany jest na wejście klocka [3](Flatten to JSON string) i tam zamieniany na napis ale z pełną obsługą zagnieżdżeń i typów (numeric/string/datetime/boolean). Otwarte klockiem [4] (Create REST Client) wywołanie REST-owe wykonuje operację [5] (HTTP REST Post) dostając jako wejście wspomniany wcześniej rekord danych (JSON). Odpowiedź serwera trafia do komponentu [6] (Unflatten from JSON String) i jako typ variant wchodzi do kostki [9](Variant To Data Function). Kostka ta, widząc z jakim typem danych pracuje ([8] klaster `responseType`) wyprowadza gotowy do operacji [10] (unbundle by name) klaster wyjściowy, z jego pól możemy swobodnie korzystać w dalszej części diagramu. Oczywiście wypada zwolnić zasoby zarezerwowane kostką tworzącą zapytanie REST - do tego mamy [7](Destroy REST client).

Cała zabawka została wstawiona w strukturę typu Flat Sequence - to potrzebne do pomiaru czasu wykonania sekwencji operacji. I tak - w pierwszej klatce pobieramy aktualny znacznik czasu (w milisekundach). Środkowa klatka to N iteracji wstawiających kolejne rekordy do Elasticsearch. Prawa, końcowa klatka to wyliczenie parametru strumienia danych (req/sec). I tak, z proporcji:

wstawienie N rekordów => zajęło T milisekund
wstawienie X rekordów => zajmie 1000 milisekund

stąd widoczny w prawej klatce wzorek: X=(1000*N)/T [req/sec]

Wrócę na chwilkę o rekordu wyjściowego opisanego strukturą responseType - jak widać z JSON-a nie jest to płaski rekord, ale zawiera zagnieżdżoną strukturę (obiekt) o nazwie `_shards`. W LabVIEW implementacyjnie jest to dość łatwe. Ot, do przygotowywanego głównego klastra wrzucamy klaster podrzędny, oczywiście odpowiednio go nazywając. Jego strukturę definiujemy zgodnie z wymaganiami (tu: format typu _shards), wszelkie parsery/interpretery JSON będą w stanie skorzystać z tej definicji.

Filmik na koniec:

https://youtu.be/mNnGrm_W1TA

Widzimy, że nawet tak na kolanie nabazgrana i pozbawiona wszelkich optymalizacji aplikacja potrafi wstawiać dane z szybkością 60..90 rekordów na sekundę. I to wszystko na jednym biednym laptopie z Win7, to uważam dość dobry wynik. Na filmiku jest też moment, kiedy usuwam kontrolki prezentujące aktualny numer rekordu i jego ID. To test, czy odświeżanie ekranu ma wpływ na przepustowość całej zabawki. No więc ma, ale w tym przypadku niezauważalny, odświeżanie kontrolek daje się we znaki głównie przy obiektach typu Chart/Graph, przy zwykłych indykatorach narzut obliczeniowy jest pomijalny.

#slowanawiatr
Nie masz wymaganych uprawnień, aby zobaczyć pliki załączone do tego posta.
______________________________________________ ____ ___ __ _ _ _ _
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)

Awatar użytkownika
wojtek
Uber Geek
Uber Geek
Posty: 2061
Rejestracja: piątek 04 wrz 2015, 09:03

Re: [AD2][LabVIEW] Analog Discovery 2 vs LabVIEW, bezpośredni zapis danych do Elasticsearch, Kibana w tle

Postautor: wojtek » czwartek 11 lip 2019, 08:05

elegancko, dobra jak zwykle robota :)
73 Wojtek


Wróć do „Inne języki programowania”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 0 gości