problem z wczytywaniem pliku w sposob ciagly

Jeśli masz coś do powiedzenia w sprawie LabVIEW napisz. Tutaj są tematy, których nie można uściślić do innych działów.
Awatar użytkownika
bartus
Posty: 141
Rejestracja: 07 maja 2007 00:00
Wersja środowiska: LabVIEW 2009
Lokalizacja: Wrocław/Żory

Re: problem z wczytywaniem pliku w sposob ciagly

Post autor: bartus »

Z tego co sie zaczynam orientowac, bo badz co badz ucze sie wciaz i nadal i z tego , co mi pewien wyjadacz powiedzial - functional globale sa wykorzystywane glownie do komunikacji miedzy petlami, ekranami itd, podobnie jak kolejki oraz podobnie jak "tradycyjne" globale.

O globalach moze nie bede wspominal, bo z tego co widze temat jest przewalkowany i to rozsadnie ;).
Kolejki sluza to przekazywania elementow miedzy petlami, z tym ze kolejki, jakoby nie nadaja sie do przenoszenia duzych ilosci danych, w tym celu zostaly wprowadzone, wymyslone functional globale - ot takie ustrojstow (jak to skoziate napisal - while + shift register+ case (jako tzw state machine) ).
wykorzystujac fglb nie sprzeniewierzasz sie data-flow, poniewaz sam decydujesz o momencie w ktorym akcja na tej "zmiennej" ma byc wykonana - najpierw ja inicjujesz, potem zapisujesz, w innym miejscu, petli odczytujesz jak wychodzisz sprogramu mozesz zniszczyc.
Mozna przyjac, ze to shift register, ktory moze sluzyc pomiedzy dwiema petlami (np - odczyt z przyrzadu w jednym vi, praca ciagla, i wyswietlanie wartosci na wykres w drugim). Tak przynajmniej ja to zrozumialem, jesli jest ktos bardziej otrzaskany w temacie, to poprosze o korekte :)
Jest pare rzeczy dla których warto zyc - TO,UE i nie zmienia sie nic :)
Awatar użytkownika
jogurt_owocowy
Posty: 1317
Rejestracja: 30 lis 2004 00:00
Wersja środowiska: LabVIEW 2015
Lokalizacja: Kraków

Re: problem z wczytywaniem pliku w sposob ciagly

Post autor: jogurt_owocowy »

Kolejki sluza to przekazywania elementow miedzy petlami, z tym ze kolejki, jakoby nie nadaja sie do przenoszenia duzych ilosci danych, w tym celu zostaly wprowadzone, wymyslone functional globale - ot takie ustrojstow (jak to skoziate napisal - while + shift register+ case (jako tzw state machine) ).
Z tymi kolejkami, to sprawa na inny temat. W razie jakichś wielkich porcji danych, wszystko zależy od konkretnego przypadku, a najlepszym sposobem zawsze jest ten najprostszy - drut ;) Functional Globale wywodzą się z prehistorii LabView (LV 2 global), gdy nie było jeszcze zwykłych globali - ot, potrzeba matką wynalazku. I nie jest to state machine!
wykorzystujac fglb nie sprzeniewierzasz sie data-flow, poniewaz sam decydujesz o momencie w ktorym akcja na tej "zmiennej" ma byc wykonana
Co nie zmienia faktu, że w jednym miejscu diagramu dane wciekają w "czarną dziurę", a w innym wypływają "spod dna" - to wystarczy. Cały urok (magia, siła - niepotrzebne skreślić) dataflow polega właśnie na tym, że o tym kiedy akcja na zmiennej się wykonuje decyduje ów flow.
Pozdrawiam (:
KaVciA
Posty: 8
Rejestracja: 19 cze 2007 00:00

Re: problem z wczytywaniem pliku w sposob ciagly

Post autor: KaVciA »

po 3 dniach wracam do tematu. Panowie (moze tez i Panie) nie zadne while+event. jak zaczalem to studiowac mialem wiecej pytan, niz przed tym, ze wiedzialem iz istnieje takie cos jak while+event, zrobilem to po swojemu. gdy to przemyslalem na drugi dzien doszedlem do wniosku, ze jest to cos unikalnego i na pewno istnieje cos bardziej prostego, moze to zagmatwalem, ale wiem ze jest moje. baa powiem wiecej zamierzam ten fragment zamiescic w pracy inz-mag. a bronie sie za pare tygodni.

jakby ktos nie zrozumial mojej intencji to krociutkie wyjasnienie w Case po lewej stronie jest false (czyli ciagle wczytuje tablice 1 wym z elem. 0) gdy wcisniemy "WCZYTAJ" wczytujemy plik - ciag probek, tez jako tablice) petla while ma za zadanie ciagle wczytywanie tablicy - na poczatku pustej - na wykresie nic nie ma, a gdy damy wczytaj, to bedzie ciagle wyswietlac wczytana tablice, gdy znowu damy wczytaj, wczyta kolejna tablice. czemu dalem zeby porownywal wczytywana tablice do 2 ? jako ze jest to program zwiazany z przetwarzaniem A/C to liczba probek w pliku bedzie min 32, 128 i w gore, dlatego tablice porownuje do 2, a ta "startowa ma jeden elemnet o wartosci 0), wiec tez sie sprawdza. A co jesli ktos wczyta plik w ktorym jest tyle samo probek co juz w wczytanym i aktualnie wykonywany pliku ? do tego jest to +3. jesli np. plik ma 128 i jest wczytany i wrzucany ciagle na shift register to dodaje do niego +3. ot tak sobie wymyslilem, wiec program mysli ze ma 131 probek, wiec wczyta 128 probek. na koncu (po prawej jest funkcja ktora usuwa "co nie co" z tablicy. bo potrzebuje wrzucac na wykres tab. 1 wym, a nie 2. wiec jest ta funkcja usuwajaca "co nie co". czekam na wasze opinie - pewnie mi troche pojedziecie, ale i sam sie czegos dowiem. moze doszukacie sie czegos czego owe wczytywanie pliku nie spelnia?

p.s. wiem, ze zamacilem z tym shift registerem - moje pierwsze zdjecie nie wiem jak to wyszlo, ale w paint-cie to sklejalem i wyszlo jak wyszlo z tym shift registerem. i juz chyba nie musze wysluchiwac "zenie wiem jak dziala shift register".
Awatar użytkownika
Mikrobi
Posty: 1210
Rejestracja: 08 paź 2003 00:00
Wersja środowiska: LabVIEW 2017

Re: problem z wczytywaniem pliku w sposob ciagly

Post autor: Mikrobi »

KaVciA pisze:po 3 dniach wracam do tematu. Panowie (moze tez i Panie) nie zadne while+event. jak zaczalem to studiowac mialem wiecej pytan, niz przed tym, ze wiedzialem iz istnieje takie cos jak while+event, zrobilem to po swojemu.
Jest takie powiedzenie: "kiedy jeden czlowiek mówi że jesteś koniem, to możesz go nie słuchać, ale kiedy to samo mówi więcej ludzi to może jednak powinieneś się zastanowić nad kupieniem siodła.."
Rada z while+event wynika z konwencji programowania w LabVIEW. W taki własnie sposób obsluguje sie programy, ktore dzialają interaktywnie z użytkownikiem, czyli najprościej ujmując: reagują na przyciski.
KaVciA pisze:gdy to przemyslalem na drugi dzien doszedlem do wniosku, ze jest to cos unikalnego i na pewno istnieje cos bardziej prostego, moze to zagmatwalem, ale wiem ze jest moje. baa powiem wiecej zamierzam ten fragment zamiescic w pracy inz-mag. a bronie sie za pare tygodni.
Zgodzę się z Tobą, ...trochę późno na naukę LabVIEW, rzeczywiście.
KaVciA pisze:jakby ktos nie zrozumial mojej intencji to krociutkie wyjasnienie w Case po lewej stronie jest false (czyli ciagle wczytuje tablice 1 wym z elem. 0) gdy wcisniemy "WCZYTAJ" wczytujemy plik - ciag probek, tez jako tablice) petla while ma za zadanie ciagle wczytywanie tablicy - na poczatku pustej - na wykresie nic nie ma, a gdy damy wczytaj, to bedzie ciagle wyswietlac wczytana tablice, gdy znowu damy wczytaj, wczyta kolejna tablice. czemu dalem zeby porownywal wczytywana tablice do 2 ? jako ze jest to program zwiazany z przetwarzaniem A/C to liczba probek w pliku bedzie min 32, 128 i w gore, dlatego tablice porownuje do 2, a ta "startowa ma jeden elemnet o wartosci 0), wiec tez sie sprawdza. A co jesli ktos wczyta plik w ktorym jest tyle samo probek co juz w wczytanym i aktualnie wykonywany pliku ? do tego jest to +3. jesli np. plik ma 128 i jest wczytany i wrzucany ciagle na shift register to dodaje do niego +3. ot tak sobie wymyslilem, wiec program mysli ze ma 131 probek, wiec wczyta 128 probek. na koncu (po prawej jest funkcja ktora usuwa "co nie co" z tablicy. bo potrzebuje wrzucac na wykres tab. 1 wym, a nie 2. wiec jest ta funkcja usuwajaca "co nie co". czekam na wasze opinie - pewnie mi troche pojedziecie, ale i sam sie czegos dowiem. moze doszukacie sie czegos czego owe wczytywanie pliku nie spelnia?
...pomijając to, że wytłumaczenie jest mało konkretne... Owszem:
1. pętla nie powinna ciagle odczytywać pliku ani tablicy, a tylko w sytuacji kiedy powinna to zrobić - albo nastąpi zmiana wartości w tablicy, albo użytkowniek naciśnie przycisk czyli zażyczy sobie ponownego/nowego odczytu <- to zdarzenia, które obsłuży struktura while+event.
2. Ciągle kręcenie pętla jest nadniernym obciązaniem procesora - nie jest istotne że masz lub miał będziesz PVI i 10GB RAM - to zła praktyka programowania.
3. "tak sobie wymyślilem" to bardzo mało inżynierskie stwierdzenie....wiesz mówiąc wprost - to nie jest rzeczowy argumet, a program tego typu nie jest dzielem sztuki, żeby stosować do niego twórcze kryteria.
KaVciA pisze:p.s. wiem, ze zamacilem z tym shift registerem - moje pierwsze zdjecie nie wiem jak to wyszlo, ale w paint-cie to sklejalem i wyszlo jak wyszlo z tym shift registerem. i juz chyba nie musze wysluchiwac "zenie wiem jak dziala shift register".
"że nie..." 8) i wybacz, ale nadal nas nie przekonałeś. 8)
pozdrawiam
Mikrobi

LabVIEW Champion, CLD, CPI
Awatar użytkownika
bartus
Posty: 141
Rejestracja: 07 maja 2007 00:00
Wersja środowiska: LabVIEW 2009
Lokalizacja: Wrocław/Żory

Re: problem z wczytywaniem pliku w sposob ciagly

Post autor: bartus »

wiem, ze moze troche nie na temat juz i po fakcie, ale zaciagnalem jezyka i ... :
dowiedzialem sie paru rzeczy na temat fglb :

rzeczywiście w prostych aplikacjach - czytaj z 1 petla rownolegla ich uzycie mija sie z celem,
- dwa : glowne cechy "dodatnie" tych konstrukcji to unikanie "race conditions" jakie maja miejsce z wykorzystaniem zmiennych globalnych

- i moze wazniejsze - dotyczy tylko duzych porcji dancyh : fglb rezerwuje pamiec tylko raz, dla danych (np tylko raz zarezerwuje 5 mb) a wykorzystanie np globali powoduje za kazdym razem utworzenie kopii.

- i potwierdzono, ze do przesylanie duzych porcji danych NIE uzywamy kolejek.
- fakt - functional global jest konstrukcja starsza od global variable (tak jak zostalo wspomniane)
zrodlo - dwaj inzynierowie, co to w LV siedza ok 10 lat kazdy.
ODPOWIEDZ