Program do analizy przebiegów

Tematy związane z tworzeniem dużych aplikacji. Zaganiednia dotyczące architektury oraz zasad tworzenia optymalnych rozwiązań.
kali
Posty: 24
Rejestracja: 22 wrz 2011 14:27
Wersja środowiska: LabVIEW 2017

Program do analizy przebiegów

Post autor: kali »

Witam szanowne grono

Od jakiegoś czasu walczę z programem do analizy przebiegów napięciowych.
Pokrótce opisze co ma on robić:
1. umożliwiać analizę przebiegu napięciowego z rejestratora zapisanego w pliku .csv;
2. umożliwić odczytanie takich wartości napięcia jak RMS, Upp, THD, f, Amin, Amax;
3. obliczać współczynniki amplitudy ka i głębokości modulacji amplitudy;
4. obliczać dryft częstotliwościowy w ciągu 60s;
5. analizować kształt napięcia ( określać odchylenie od kształtu sinusoidy zgodnie ze wzorem (15,5+5,5cos2alfa)%;

Jak do tej pory udało mi się napisać część kodu odpowiedzialną za wczytywanie danych z pliku .csv oraz wyodrębnianie z niego poszczególnych informacji: informacji o pliku pomiarowym, danych liczbowych potrzebnych do stworzenia przebiegu w postaci kolumny, oraz wartości częstotliwości próbkowania dt potrzebnej do dalszych obliczeń.
Mam także funkcje które na podstawie dt i czasu dla jakiego ma być przeprowadzana analiza (domyślnie 60s) odlicza ilość próbek potrzebnych do dalszej analizy, żeby nie obrabiać zbędnych danych.
Dalej mam funkcje, która za pomocą bloczków waveform mesurement daje mi wartości napięcia Urms itd.
Całość programu oparłem o state machine.

Mam jednak problem z jej działaniem, ponieważ nie wiem czemu zawiesza się na wczytaniu danych i nie chce przystąpić do obliczania ilości próbek potrzebnych do analizy. Nie wiem gdzie tkwi błąd.
Nie wiem także jak zabrać się za kształt napięcia. Nie mam pomysłu jak określić kąt na którym występuje zniekształcenie i jaką ma amplitudę.
Może mogli byście coś podpowiedzieć i przy okazji zerknąć na poprawność kodu. Projekt ten traktuje jako możliwość dalszej nauki i podnoszenia swoich umiejętności w LabView dlatego nie chce gotowych rozwiązań. I proszę nie przenoście tego tematu do działu "dam prace" :D
Załączniki
Analiza danych z rejestratora.rar
(1.99 MiB) Pobrany 453 razy
widok analizotora.png
Adrian47
Posty: 3
Rejestracja: 19 paź 2018 15:35
Wersja środowiska: LabVIEW 2017

Re: Program do analizy przebiegów

Post autor: Adrian47 »

Struktura Event ma to do siebie, że czeka na Event lub timeout (który u Ciebie nie występuje). Więc w momencie wejścia w stan "Wczytanie danych" struktura Event czeka na wciśnięcie przycisku "Open Button". Jednak w międzyczasie wykonuje się reszta kodu w tym casie która nie wymaga wyniku z Eventu (poczytaj o DataFlow) czyli zostaje zczytany stan przycisku "analiza danych" (odpal żarówkę wszystko będzie bardzo ładnie widać co kiedy się wykonuje) który jest w tym momencie False (zczytywanie z terminala kontrolki na nic nie czeka po prostu czyta stan aktualny), czyli zaraz po wejściu do stanu "Wczytanie danych" na terminalu wyjściowym z niego już czeka znowu stan "Wczytanie danych", program więc do niego idzie i znowu czeka na wciśnięcie przycisku "Open Button" w nieskończoność (bo już go nie widać więc nikt go nie kliknie) co powoduje teoretyczne zwieszenie.
Polecam, żebyś najpierw (po poczytaniu o Eventach i DataFlow) zrobił nowy stan Idle ze strukturą Event (tylko jedną na cały program) w środku, po stanie Init idziesz do Idle, tam Event czeka na twoje czynności (obsługuje wszystkie buttony które mają coś wykonać), po kliknięciu konkretnego przycisku idzie do określonego stanu (np. Wczytanie danych) a stamtąd wraca do Idle i znowu czeka na czynność użytkownika.
kali
Posty: 24
Rejestracja: 22 wrz 2011 14:27
Wersja środowiska: LabVIEW 2017

Re: Program do analizy przebiegów

Post autor: kali »

Dzięki za uwagi. Uzupełniłem trochę wiedzę i już wszystko działa jak należy. Program się nie zawiesza i podaje prawidłowe wartości parametrów napięcia.

Teraz zmagam się z analizą przebiegu pod kątem kształtu napięcia i dryftu częstotliwościowego.
Co do kształtu to wpadłem na pomysł aby porównywać badany sygnał z wzorcem generowanym w programie. Co wy na to? Dobry pomysł.

Adrian zamieszczam poprawiony kod czy o takie rozwiązanie ci chodziło czy jest coś w nim jeszcze do poprawienia?
Załączniki
Analiza danych z rejestratora.rar
(1.93 MiB) Pobrany 420 razy
kali
Posty: 24
Rejestracja: 22 wrz 2011 14:27
Wersja środowiska: LabVIEW 2017

Re: Program do analizy przebiegów

Post autor: kali »

Znalazłem trochę czasu i coś pokombinowałem z kształtem przebiegu. Nie udało mi się zrobić tego automatycznie ale manualnie.
Za pomocą kursorów na wykresie ustawiam parametry potrzebne do obliczeń.
Widok analizatora.png
kali
Posty: 24
Rejestracja: 22 wrz 2011 14:27
Wersja środowiska: LabVIEW 2017

Re: Program do analizy przebiegów

Post autor: kali »

Po pewnym czasie wróciłem do programu. Jednak napotkałem problem. Kiedy przystępuje do analizy właściwego sygnału,którego
parametry to 100kS/s, a czas trwania rejestracji to więcej niż 60s. Program poprawnie wczytuje dane z pliku
widok wczytanych 60s.png
Następnie określając długość sygnału jaki ma być poddany analizie na t=60 s program zawiesza się.
widok wczytanych 60s komunikat 1.png
Po pewnym czasie pojawia się komunikat:
widok wczytanych 60s komunikat 2.png

Nie wiem co może być tego przyczyną. Za mały bufor? Może macie jakieś sugestie.

Dodatkowo chciałbym dodać do programu możliwość analizy sygnałów trójfazowych jednak wiąże się to ze znacznym jego rozbudowaniem. Co za tym idzie zmianą architektury programu. Simple state machine będzie niewystarczająca może producent/konsument będzie wystarczająca? Jedna pętla producenta i kilka pętli konsumenta. Z podziałem na zadania odczyt, obróbka, analiza 1 fazy, analiza 3 faz,... Może macie jakieś sugestie?
Awatar użytkownika
micard
Posty: 207
Rejestracja: 30 wrz 2011 11:28
Wersja środowiska: LabVIEW 2017
Kontakt:

Re: Program do analizy przebiegów

Post autor: micard »

Komunikaty jasno piszą na czym polega problem - brak pamięci. Sprawdź w menedżerze zadań albo w wydajności systemu ilość pamięci konsumowanej przez LV przed uruchomieniem i w trakcie działania aplikacji.

Chcesz analizować 60s sygnału 100ks/s - co daje 6 000 000 wartości - nie jest to liczba ogromna, ale tez nie jest pomijalnie mała i przy takiej ilości próbek trzeba zwrócić już uwagę na to jak alokujesz pamięć do przechowywania tych danych.

Nie podzieliłeś się kodem, ale podejrzewam że problemem jest dynamicznie powiększana tablica albo tworzenie wielu kopii tablicy.

Na "state machine" zrobisz wszystko - pytanie z jaką strukturą aplikacji czujesz się najlepiej. niemniej jeśli chcesz pogłębić swoją wiedzę i umiejętności w zaawansowanych rozwiązaniach proponuję rzucić okiem na:
Awatar użytkownika
micard
Posty: 207
Rejestracja: 30 wrz 2011 11:28
Wersja środowiska: LabVIEW 2017
Kontakt:

Re: Program do analizy przebiegów

Post autor: micard »

Mam też nadzieję, że nie próbujesz przepchnąć owych 6M próbek do DFFT?

Jeśli tak to odeślę do zadania domowego z przetwarzania sygnałów - ile pamięci potrzebuje algorytm DFFT do analizy sygnału składającego się z N próbek?
Podpowiedź tutaj:
https://bit.ly/2C6bV9q
kali
Posty: 24
Rejestracja: 22 wrz 2011 14:27
Wersja środowiska: LabVIEW 2017

Re: Program do analizy przebiegów

Post autor: kali »

Sprawdziłem w menedżerze zużycie pamięci LV. Przed uruchomieniem aplikacji 1569 540 kB po uruchomieniu 3 554 448 kB. Ogólnie z 4GB Ramu wszystko znika i program się wysypuje.
FFT też było w programie bo potrzebuje tej analizy. Lecz na razie wyciąłem to z programu aby zmniejszyć zużycie danych.
Dla podglądu dołączam program :)
Załączniki
Analiza danych z rejestratora.rar
(180.93 KiB) Pobrany 419 razy
Awatar użytkownika
micard
Posty: 207
Rejestracja: 30 wrz 2011 11:28
Wersja środowiska: LabVIEW 2017
Kontakt:

Re: Program do analizy przebiegów

Post autor: micard »

1. zasada LabVIEW - LabVIEW nie radzi sobie z UNICODE!!!!! W przypadku etykietek, bądą to krzaczki - ale w przypadku plików - cały projekt się nie ładuje i LV nawet nie raczy poinformować o jakimkolwiek błędzie. Ogólnie używanie znaków dialektycznych w nazwach plików to kiepski pomy(s)ł. Jak się da to najlepiej ograniczyć się do 8 znaków i bez spacji.

Każdy bloczek w "parametry napięcia.vi" wykonuje swoją analizę FFT - i wykonuje ją jak się domyślam dla wszystkich 6M próbek. Trochę to na wyrost. Czy jest jakiś konkretny powód dla którego chcesz przeanalizować 60s sygnału próbkowanego 100kS/s ?

Takie parametry analizy FFT pozwalają Ci na analizę częstotliwościową z rozdzielczością 1/60Hz i zakresie 1/60Hz - 50kHz. Czy aby na pewno taki jest Twój cel?
kali
Posty: 24
Rejestracja: 22 wrz 2011 14:27
Wersja środowiska: LabVIEW 2017

Re: Program do analizy przebiegów

Post autor: kali »

Ogólnie podstawowym założeniem programu jest zmniejszenie aparatury kontrolno-pomiarowej jaką wożę ze sobą w pracy. Zamiast zabierać ze sobą woltomierz, analizator, scopometr, multimetr, itd. Chce zabierać jedynie rejestrator i laptop.
Próbkowanie 100 kS/s na kanał wynika z konieczności rejestracji dynamicznych zjawisk jakie mogą wystąpić w badanym układzie, a im wyższe próbkowanie tym lepsze odwzorowanie kształtu. Dodam tylko, że jedzie do mnie rejestrator, który rejestruje z częstotliwością 1 MS/s na kanał :D
Co do czasu 60 s jednym z kryteriów jakie oceniam jest dryft częstotliwości w ciągu właśnie 60s. Dodam jeszcze, że nie pracuje na sygnałach 50 Hz tylko 350-900 Hz.

Co do unicode pozmieniam wszystkie nazwy tak aby nie występowały w nich polskie znaki i postaram się skrócić ich nazwy do 8 znaków.
Dlaczego uważasz, że każdy bloczek w "parametry napięcia" wykonuje FFT? Bo nie rozumiem, lub czegoś nie wiem.

Fakt nie potrzebuje analizować sygnału z tak duża rozdzielczością jak 1/60 Hz. Wystarczy mi 1 Hz.
Awatar użytkownika
micard
Posty: 207
Rejestracja: 30 wrz 2011 11:28
Wersja środowiska: LabVIEW 2017
Kontakt:

Re: Program do analizy przebiegów

Post autor: micard »

Dlaczego uważasz, że każdy bloczek w "parametry napięcia" wykonuje FFT?
- Zajrzyj do środka.

Wydaje mi się (nie sprawdziłem na papierze ;p), że jeśli poddasz FFT sygnał, w którym częstotliwość się zmienia w czasie (ów dryft), to w dziedzinie częstotliwości zobaczysz jedynie poszerzanie się peak'a. Próbkowanie "im szybciej tym lepiej" oczywiście sprawdza się przy analizie sygnałów w domenie czasowej - ale w celu oszczędzenia czasu i pamięci zaproponuję zastosowanie odpowiedniego przygotowania sygnałów przed konkretnymi analizami.
Tutaj lepszą strategią będzie podzielenie sygnału na K okresów w taki sposób, że każdy okres da Ci rozdzielczość 1Hz (z teorii FFT: df=f_0/N). Dzięki temu będziesz mógł zrobić wykres mający K punktów, który pokaże zmiany częstotliwości w czasie.
kali
Posty: 24
Rejestracja: 22 wrz 2011 14:27
Wersja środowiska: LabVIEW 2017

Re: Program do analizy przebiegów

Post autor: kali »

Borykam się dalej z problemem wczytywania danych. O ile pliki z sygnałem jednofazowym (dla próbkowania 100kS/s) wczytują się bez problemu to pliki z sygnałem trójfazowym już nie (próbkowanie 50kS/s).

Tak jak pisałem wcześniej potrzebuje wczytywać pliki o długości zapisu danych min 60 sekund i nie wiem jak to ugryźć. A za chwile do zbierania danych zacznę używać rejestratora o próbkowaniu 1MS i 500kS dla odpowiednio dla jednej i trzech faz. Może macie jakieś pomysły jak to rozwiązać bo mi się już pomysły skończyły. :((
PiDi
Posty: 641
Rejestracja: 31 gru 2010 01:36
Wersja środowiska: LabVIEW 2017
Lokalizacja: Katowice

Re: Program do analizy przebiegów

Post autor: PiDi »

kali pisze: 25 kwie 2019 13:05 Borykam się dalej z problemem wczytywania danych. O ile pliki z sygnałem jednofazowym (dla próbkowania 100kS/s) wczytują się bez problemu to pliki z sygnałem trójfazowym już nie (próbkowanie 50kS/s).
Rozwiązaniem tego problemu będzie wczytanie plików w lepszy sposób (*odpowiedź adekwatna do opisu problemu).

Mówiąc poważniej - co już zrobiłeś w temacie zużywania zbyt dużej ilości pamięci?
1. Zaczynając od podawania 6 MLN próbek do analiz częstotliwościowych. Jesteś pewien, że tak chcesz robić? Chyba, że mierzysz pulsary, to bardziej rozumiem. Trochę rozgrzebując dla przykładu: Cycle Average and RMS liczy średnią i RMS z pojedynczego cyklu (wskazanego jako parametr VI). Podkreślam - jednego cyklu. Przypominam - sygnał 400 Hz to 400 cykli na sekundę, czyli 24000 cykli na minutę, z czego nasz bloczek znajduje jeden jedyny do analizy, co więcej - w domyślnych ustawieniach ten pierwszy... Ale pamięci zjada niepotrzebnie za całe 60 sekund albo i jeszcze więcej.
2. W Twoim kodzie jest generalnie dużo miejsc, które można podejrzewać o tworzenie dodatkowych kopii danych. Dla ułatwienia możesz założyć, że każda kontrolka tworzy dodatkową kopię (potrzebujesz wykres "cały przebieg", który efektywnie pokazuje niebieski kwadrat na białym tle?).
3. Zakładając, że operujemy tymi 6 MLN próbek typu DBL, to na czysto wychodzi ~48 MB danych. Niedużo, ale jest pewien haczyk - LabVIEW alokuje tablice w ciągłym obszarze pamięci, czyli musi sobie znaleźć ciągłe 48 MB. Pomijając szczegóły, efektywnie jedna kopia Twojej tablicy może zająć więcej niż 48 MB.
4. Kilka oczywistych rzeczy na koniec: wyłącz Retain Wire Values, wyłącz debugging w VIju.
ObrazekObrazekObrazekObrazek
kali
Posty: 24
Rejestracja: 22 wrz 2011 14:27
Wersja środowiska: LabVIEW 2017

Re: Program do analizy przebiegów

Post autor: kali »

A więc po kolei:
PiDi pisze: 25 kwie 2019 23:21 Mówiąc poważniej - co już zrobiłeś w temacie zużywania zbyt dużej ilości pamięci?
1. Zaczynając od podawania 6 MLN próbek do analiz częstotliwościowych. Jesteś pewien, że tak chcesz robić? Chyba, że mierzysz pulsary, to bardziej rozumiem. Trochę rozgrzebując dla przykładu: Cycle Average and RMS liczy średnią i RMS z pojedynczego cyklu (wskazanego jako parametr VI). Podkreślam - jednego cyklu. Przypominam - sygnał 400 Hz to 400 cykli na sekundę, czyli 24000 cykli na minutę, z czego nasz bloczek znajduje jeden jedyny do analizy, co więcej - w domyślnych ustawieniach ten pierwszy... Ale pamięci zjada niepotrzebnie za całe 60 sekund albo i jeszcze więcej.
Problem nie dotyczy obróbki sygnału. Z tym sobie poradziłem poddając analizie fft tylko mały wycinek sygnału. Zmianą częstotliwości w czasie na razie się nie zajmuje. Tym samym zniknął problem zasobów pamięci podczas obróbki danych.
Sęk w tym, że nie mogę wczytać danych z pliku csv. Wiem, że należałoby wczytywać go partiami, ale nie mogę sobie z tym poradzić lub coś robię źle.
PiDi pisze: 25 kwie 2019 23:21 2. W Twoim kodzie jest generalnie dużo miejsc, które można podejrzewać o tworzenie dodatkowych kopii danych. Dla ułatwienia możesz założyć, że każda kontrolka tworzy dodatkową kopię (potrzebujesz wykres "cały przebieg", który efektywnie pokazuje niebieski kwadrat na białym tle?).
Zapewne masz racje ;) nie będę się spierał co do powielania danych bo tego nie sprawdzałem (a chyba powinienem). Jednak wyświetlanie całego przebiegu jest mi potrzebne chociażby ze względy na możliwość wystąpienia jakiegoś stanu przejściowego, który będzie na nim widoczny. Oraz późniejsze wybranie właśnie tego fragmentu sygnału do analizy.
PiDi pisze: 25 kwie 2019 23:21 3. Zakładając, że operujemy tymi 6 MLN próbek typu DBL, to na czysto wychodzi ~48 MB danych. Niedużo, ale jest pewien haczyk - LabVIEW alokuje tablice w ciągłym obszarze pamięci, czyli musi sobie znaleźć ciągłe 48 MB. Pomijając szczegóły, efektywnie jedna kopia Twojej tablicy może zająć więcej niż 48 MB.
Nie bardzo rozumiem wczytuje ( a raczej próbuje wczytać) ok 200 MB a ty mówisz o 48 MB.
PiDi pisze: 25 kwie 2019 23:21 4. Kilka oczywistych rzeczy na koniec: wyłącz Retain Wire Values, wyłącz debugging w VIju.
To mam zrobione.
ODPOWIEDZ