Polskie Centrum LabVIEW

Jak zapisac taki typ danych do pliku??

Prosty przykład, który powinien Ci pomóc ....

Szybka korekta: a) warunek zatrzymania pętli while - przycisk czyli zmienna a nie stała ;) b) trzeba pamiętać że zapis realizowany w ten sposób powoduje tworzenie kolejnych datalogów, czyli petla w takiej postaci zapisuje co sekundę kolejną tablicę klastrów, a nie uzupełnia tablicy nastepnymi elementami.

Poradziłem sobie tak. Moim zdaniem całkiem dobre rozwiązanie jak na moje potrzeby

aaaaaargggghh...... więcej powiem:
aaarggghhhh....

Trzy sugestie 1. kod tylko od lewej do prawej strony, 2. nigdy nie zawijany 3. proste połączenia

Nie rozumiem?? Nie mialem miejsca zeby nie zawijać. Dziękuje za sugestie:)
Nie zawsze sie da zrobic proste połączenia. To tylko malutki fragment programu do pomiaru transmitancji czwórnika.

Z całym należnym szacunkiem - bzdury Waszmość prawisz.
Jeśli "nie ma miejsca" to znaczy że kod jest źle zorganizowany. Zapytam tak:
pisząc w C (bo zakładam że więcej niż raz pisałeś, zatem znasz i potrafisz): piszesz ciągłym tekstem, czy stosujesz formatowanie, wcięcia, właściwy układ tekstu czyli kodu?
przecież ekran jest taaaki mały, prościej pisać lanym tekstem, kompilator przecież i tak zrozumie...
:roll:

To może Waćpan mógłby udzielić mi wskazówek w jaki sposób organizować kod w Labview ponieważ jestem poczatkującym użytkownikiem tego środowiska i jeszcze mało wiem. Poniżej mój projekt.

Jesli bede pisal lanym tkstem w C to kompilator to zrozumie ale ja nie zrozumiem lub ktos kto bedzie chcial zrozumiec. Nie rozumiem dokad Waćpan zmierza.

Ostatnio konstruktor dokonal drobnej zmiany w jednym zespole i musialem przerobic tester. Pech chcial, ze byl to jeden z pierwszych ktore robilem i kod wygladal podobnie do tego powyzej. Po 2 minutach doszedlem do wniosku, ze prosciej bedzie napisac to od poczatku...

Mikrobi udzielił Ci trochę wyżej 3 wskazówek - a ja sugerowalbym jeszcze dodawanie opisow w co ciekawszych miejscach, tak zebys potem nie musial sie zastanawiac dlaczego np użyłeś warunku 'mniejsze niż' + negacja zamiast 'Większe lub równe' ;)

Ogólnie przyjęta zasada mówi, że diagram powinien mieścić się na jednym ekranie, ale to często niewykonalne. W labview nie ma czegoś takiego jak brak miejsca, tak samo jak nie może Ci braknąć wolnych linijek kiedy piszesz w C. Ja wolę diagramy większe, ale bardziej czytelne. Byle skrolowanie odbywało się tylko w jednej płaszczyźnie....

marian pisze:Jesli bede pisal lanym tkstem w C to kompilator to zrozumie ale ja nie zrozumiem lub ktos kto bedzie chcial zrozumiec. Nie rozumiem dokad Waćpan zmierza.

A imaginuj sobie Waszmość, że takowy diagram również czytelnym nie jest. A już zapewne nie będzie dla Ciebie czytelnym gdy zaglądniesz do niego miesiąc po zakończeniu pracy. Po co zaglądać? bo trzeba będzie coś dodać, poprawić, ulepszyć.
Pięknym mitem jest: potem będę miał czas na sprzątanie diagramu Rzeczywistość skrzeczy jak pisał Wieszcz - tego czasu nigdy nie ma w realnym świecie. Regułą jest, że gdy kończysz kod czeka kolejne zagadnienie. Wiedząc że coś czeka a mając "kod który działa" nie posprzatasz. "Przecież działa" 8)
Tak na prawdę gdy zostawisz nieczytelny diagram to narażasz się na wymierne straty finansowe (Twoje lub Twojej firmy) mogące uderzyć z dwóch stron:
1. Ktoś kiedyś zostanie wynajety do aktualizacji Twojego kodu, bo Ty już nie będziesz się zajmował tym tematem.
Godzina pracy programisty kosztuje wymierne pieniądze.
Słabo czytelny kod analizuje się wolniej i wolniej aktualizuje.
Zatem: trzeba bedzie zapłacić za aktualizację o wiele więcej niż przy aktualizacju czytelnego kodu. Wynika to stąd, że każdy rozsądny programista każe zapłacić za sprzątanie cudzego bałaganu, gdyz działanie takie nie jest produktywne, a nieczytelny kod przeszkadza w pracy. Trudno bedzie znaleźć kogoś kto zrobi to charytatywnie lub społecznie. 8)
2. Jeśli to Ty będziesz aktualizował własny kod, to stracisz swój czas, a zatem i pieniadze. Dlaczego? stracisz na odtwarzanie sposobu realizacji kodu, analizę, . A powinieneś kod : zobaczyć-zrozumieć-zaktualizować.
I iść na piwo czego Ci serdecznie życzę 8)

marian pisze:To może Waćpan mógłby udzielić mi wskazówek w jaki sposób organizować kod w Labview ponieważ jestem poczatkującym użytkownikiem tego środowiska i jeszcze mało wiem. Poniżej mój projekt.

To nie jest LabVIEW 8, tylko 7.1 lub starsze, zatem:
1. menu Tools>>Options>> kategoria Block Diagram: zaznacz checkbox "Show dots at wire junctions" Będzie widoczne w którym miejscu druty łaczą się ze sobą a w którym tylko krzyzują.
2. Niedopuszczalne jest wielokrotne łamanie przewodów i zawijanie ich tak, by dane biegły od prawej do lewej strony.
Jesteśmy w kulturze ktora czyta od lewej do prawej strony i tak realizowany jest diagram.
Na listwie narzędzi są przyciski Run (biała strzałka), Continious Run, Abort, Pause, Taext Settings i często zapominane:
- Align Objects wyrównanie zaznaczonych (Shift+LewyKM) obiektów do lini - Distribute Objects wyrównanie odstepów między zaznaczonymi obiektami - Resize Objects dopasowanie rozmiarów obiektów skkalowalnych (np. kontrolki panelu)
Zacznij od próby posprzątania diagramu. Ułożenia elementów liniowo, wyprostowania przewodów.
Daj znać jak o wynikach.
Tego warto się nauczyć.

Dziękuje za cenne uwagi

marian pisze:Dziękuje za cenne uwagi

Ja bym jeszcze dodal do tego uzywanie CTRL w przypadku gdy chcesz zrobic miejsce pomiedzy dwoma ikonami w LabVIEW. Najedz myszka na miejsce gdzie chcesz zrobic wiecej miejsca, nacisnij CTRL + lewy guzik myszki i przeciagnij kursor np. w lewo. Zrobisz w ten sposob wiecej miejsca na nowy kod, a reszta kodu sie automatycznie przesunie.