Timer z resetem

[seyu]

Witam,
moje pytanie może okazać się banalne, ale nie mogę znaleźć na nie odpowiedzi w znalezionych tutorialach, a w labview jestem jeszcze początkujący. Mam problem, otóż potrzebuję użyć timera do opóźnienia wykonania operacji (przejścia do następnego stanu), ale takiego który można resetować. Czyli timer odlicza, a kiedy pojawia się sygnał (błąd) timer się resetuje i odlicza od nowa od momentu zniknięcia błędu. (Dokładnie chodzi o przypadek zamknięcia drzwi windy: otwarte>czujnik w drzwiach nikogo nie widzi to po 5 sekundach sie zamykaja, a jesli ktos wejdzie to drzwi zamkną się po 5 sekundach od wyłączenia czujnika) Robiłem coś takiego w PLC, a teraz w labview tego potrzebuję i nie mogę sobie poradzić.
Będę bardzo wdzięczny za pomoc:-)

[Zyga]

Proszę.

[may]

To co wrzucił Zyga to właśnie to czego potrzebujesz. To taka chytra struktura nazywająca się Functional Global Variable (FGV). Rzuć sobie okiem na: http://labviewwiki.org/Functional_global_variable oraz https://decibel.ni.com/content/docs/DOC-2143, jeżeli chcesz zrozumieć jak i dlaczego to działa a nie tylko wkleić kawałek kodu z komentarzem "działa, magia, nie dotykać"

[TMa]

Możesz uniknąć niejawnego rzutowania używając bloczek Tick Count (ms).

[czab]

Unikniecie niejawnego rzutowania nie jest celem samym w sobie . Jesli komus przeszkadzaja kropeczki mozna zastapic niejawne rzutowanie jawnym rzutowaniem, przy pomocy konwersji "to double precision float". Za to znacznie mniej mila sprawa jest to ze bloczek Tick Count ma reprezentacje U32, co moze generowac dwa czasem trudne do wytropienia problemy - po pierwsze w dlugich odcinkach czasu moze sie "przekrecic", po drugie trzeba bardzo uwazac przy odejmowaniu. Krotko mowiac wykorzystanie zmiennego przecinka i timestampa, ktore podal Zyga, jest znacznie lepsze i nie trzeba silic sie na udoskonalenia.

[TMa]

Chodzi o przejrzystość i czytelność kodu, a "kropeczki" w kodzie z pewnością nie należą do dobrej praktyki programistycznej. Zazwyczaj dąży się do prostoty... http://digital.ni.com/public.nsf/allkb/ ... 2800784764

"Kropeczkom" mówimy stanowcze NIE!

[seyu]

Dziękuję za wszystkie odpowiedzi. Mniej więcej rozumiem o co chodzi z tą FGV, jednak mam problem, ponieważ kiedy chcę podłączyć wszystko tak jak na załączonym przez Zygę obrazku wywala mi błąd, który widać na poniższym screen'ie. Możecie mi podpowiedzieć gdzie robię błąd? I jak wygląda stan resetujący timer? Jest to pusta pętla case z "przelatującym" sygnałem między rejestrami przesuwnymi?

[Mikrobi]

1. Zadeklaruj ShiftRegister - wyjściem funkcji Get Date/Time In Seconds albo stałą Time Stamp Constant podłączonym przed pętlą do rejestrów
2. Odepnij stałą, lub funkcję czyli wróć do funkcjonalności FGV
środowisko zapisze w pamięci co ma być na obu Shift Registerach

Inne rozwiązanie to korzystanie dla sterowania strukturą Case kontrolką enum zamiast przyciskami : można stworzyć stany Get, Set, Init, Increment, Decrement, Reset - w zależności od tego jak rozrysowany jest algorytm pracy tej części programu (tak, kartka i długopis nadal się przydają ;) ) - wtedy w stanie Init inicjalizujesz albo stała, albo aktualną wartością funkcji Get Date/Time In Seconds

[czab]

Dziękuję za wszystkie odpowiedzi. Mniej więcej rozumiem o co chodzi z tą FGV, jednak mam problem, ponieważ kiedy chcę podłączyć wszystko tak jak na załączonym przez Zygę obrazku wywala mi błąd, który widać na poniższym screen'ie. Możecie mi podpowiedzieć gdzie robię błąd? I jak wygląda stan resetujący timer? Jest to pusta pętla case z "przelatującym" sygnałem między rejestrami przesuwnymi?

Tak jak napisal Mikrobi, rejestr przesuwny "nie wie", jaka typ danych ma zostac podany. Zastanow sie spokojnie - chcesz skonstruowac stoper, czyli urzadzenie, ktore mierzy jakis przedzial czasu. Zeby zmierzyc odstep czasu, musisz miec jakis punkt odniesienia, od ktorego ten odstep bedziesz mierzyl - ten punkt odniesienia ustalasz przy resetowaniu stopera. Od razu wtedy poinformujesz LabVIEW, jaki typ danych jest obecny w tym rejestrze przesuwnym. Zastanow sie jak to najlepiej zrobic, zeby otrzymac taki efekt jaki chcesz. Jesli skoncza Ci sie pomysly zgraj sobie na kompa obrazek Zygi i "przeciagnij" go bezposrednio na diagram blokowy LabVIEW, dostaniesz caly kod w wersji do edytowania i bedziesz mogl "podejrzec" wnetrze struktury case.

Chodzi o przejrzystość i czytelność kodu, a "kropeczki" w kodzie z pewnością nie należą do dobrej praktyki programistycznej. Zazwyczaj dąży się do prostoty... http://digital.ni.com/public.nsf/allkb/ ... 2800784764

"Kropeczkom" mówimy stanowcze NIE!

To moja ostatnia odpowiedz w tej sprawie zeby nie robic offtopu. Poczytaj sobie http://labviewartisan.blogspot.be/2012/ ... -dots.html , ze szczegolnym naciskiem na fragment:

Now, the "coercion dots are bad!" crowd would tell you that, in order to avoid additional memory usage because of the different data types, you need to do something about that coercion dot, particularly if this loop is running a whole bunch of times (since the arrays might be very large). Well, it turns out that, no matter how I try to "optimize" this diagram to remove the coercion dot (a few things I tried included using a conversion bullet on the iteration count, a conversion bullet on the I32 array, and maintaining my own DBL iteration count in a shift register), all other approaches used more memory during execution than the simple coercion dot approach illustrated here. So before you go trying to get rid of every coercion dot on your diagrams because you're afraid they affect performance and memory, I'd recommend actually using the Profile Performance and Memory Window to see if any of the alternative approaches really are better.

"Zazwyczaj" dazy sie do tego by kod dzialal dobrze, a nie razil zmysl estetyczny czerwonymi kropami. Jak juz zaznaczylem, sprobuj zrobic eksperyment z "tick count", w ktorym przez nieuwage cos pomieszasz i odejmiesz wiekszy czas od mniejszego. Rezultat moze byc zaskakujacy. Oczywiscie nie dyskwalifikuje to kompletnie "tick count" w stoperach, chce tylko zaznaczyc ze sa momenty kiedy te rozwiazania sa rownowazne, ale sa takie kiedy timestamp jest zdecydowanie lepszy. Z kolei nie ma takich w ktorych tick count mialby nad timestampem przewage.

[seyu]

Niestety wszystko po staremu. Pomimo sterowania kontrolką enum, deklarowania rejestru funkcją Get Date/Time In Seconds i/lub podłączania Time Stamp Constant zawsze po jej odłączeniu wywala taki sam błąd. Próbowałem zbudować taki timer w projekcie i w oddzielnym VI, ale nic z tego. Mógłby ktoś podrzucić plik ze zbudowanym w ten sposób timerem? Pewnie robię jakiś głupi błąd i przez to to wszystko.

[czab]

No comments.

[TMa]

Z kolei nie ma takich w ktorych tick count mialby nad timestampem przewage.

polecam
http://forums.ni.com/t5/LabVIEW/tick-co ... -p/1072181

The timestamp (which is what the "Get Date/Time..." primitive returns) has (at least in Windows) a resolution of about 16 ms (which is pretty clear in this example). If you want ms accuracy, you should use the tick count primitive.

W tym "offtopie" nie mam już nic do dodania.