Witam,
Dostałem z firmy drivery do mojego urządzenia pod Labview. Wrzuciłem je w pętle while ale mam problem z czasem dla pętli. Tzn. Chciałbym wysyłać dane do urządzenia z przedziałem czasowym 2-5ms. Normalnie prosta sprawa ale jak wrzucę drivery minimalny czas jaki mogę otrzymać jest 10-20ms. Okres dla jednej iteracji wydłuża się. Labview/komputer nie potrafi wykonać to szybciej niż ok 20ms. A jak poruszę myszką to czas jest nawet większy. Nie wiem czy idzie coś ustawić w Labview czy to wina sterowników czy może mojego kompa. Mam Duo Core 2 1.8 GHz oraz 1 Gb ramu. Drivery są w postaci Sub'Vi-ów. Nic więcej nie robie tylko wrzucam do pętli while. Może ktoś wie jak to przyspieszyć? Dzięki za jakąkolwiek odpowiedź.
Czas dla pętli
-
Tutenhamon
- Posty: 30
- Rejestracja: 23 lut 2007 00:00
Czas dla pętli
Engineering is the art of making what you want from things you can get
Re: Czas dla pętli
...i pewnie masz Windows...? Pamietaj że to system operacyjny do ogólnego zastosowania.
Nie wyciągniesz z niego szybszej powtarzalności - obrotu pętli - niż 10 (hahahaha
) a raczej 20 ms.
...z calym Należnym Wszytkim Szacunkiem 8)
Przyśpieszysz jeśli pracować będziesz w systemie czasu rzeczywistego.
Nie wyciągniesz z niego szybszej powtarzalności - obrotu pętli - niż 10 (hahahaha
) a raczej 20 ms....z calym Należnym Wszytkim Szacunkiem 8)
Przyśpieszysz jeśli pracować będziesz w systemie czasu rzeczywistego.
-
Tutenhamon
- Posty: 30
- Rejestracja: 23 lut 2007 00:00
Re: Czas dla pętli
No to super:/ Dzięki za odpowiedź. Muszę coś wymyśleć bo mi wszystko w tym momencie padło:/ Urządzenie zachowuję się jakby się zacinało:) A jak się ma sprawa pod Linuxem? Może ktoś próbował?
Engineering is the art of making what you want from things you can get
-
Tutenhamon
- Posty: 30
- Rejestracja: 23 lut 2007 00:00
Re: Czas dla pętli
Coś tam poczytałem i znalazłem, że możliwość istnieje taka w środowisku Windows i Linux Embedded. Ktoś może to już ruszał? Trudne jest postawienie takiego systemu i później jego zarządzanie? Jest możliwość ściągnięcia wersji próbnej ze strony Microsftu ale chciałbym wiedzieć wpierw czy jest sens.
Engineering is the art of making what you want from things you can get
Re: Czas dla pętli
system czasu rzeczywistego kosztuje.
w zależności jakiego typu dane wysyłasz i czy zmieniasz je w pętli sprzężenia zwrotnego, pomyśl czy nie dałoby się napisać prosty (dla niektórych) program na mikrokontroler albo procek, który wysyłałby komendy co określony czas. takie małe ustrojstwo poradziło by sobie z czasem rzędu 2ms, a Ty będziesz miał kontrole nad jego wejściami (w rezultacie wyjściami) w czasie rzędu 20ms
w zależności jakiego typu dane wysyłasz i czy zmieniasz je w pętli sprzężenia zwrotnego, pomyśl czy nie dałoby się napisać prosty (dla niektórych) program na mikrokontroler albo procek, który wysyłałby komendy co określony czas. takie małe ustrojstwo poradziło by sobie z czasem rzędu 2ms, a Ty będziesz miał kontrole nad jego wejściami (w rezultacie wyjściami) w czasie rzędu 20ms
-
Tutenhamon
- Posty: 30
- Rejestracja: 23 lut 2007 00:00
Re: Czas dla pętli
Wiesz, używam coś takiego:
http://www.linmot.com/lm_typo/fileadmin ... recent.pdf
Potrzebuje pętle rzędu 2-5mS. A mam 20mS i mój silnik liniowy skacze a nie się rusza:/ Czas reakcji jest za mały i dla okresu 1s mam za mało punktów:( Dlatego staram się coś znaleźć rozsądnego.
http://www.linmot.com/lm_typo/fileadmin ... recent.pdf
Potrzebuje pętle rzędu 2-5mS. A mam 20mS i mój silnik liniowy skacze a nie się rusza:/ Czas reakcji jest za mały i dla okresu 1s mam za mało punktów:( Dlatego staram się coś znaleźć rozsądnego.
Engineering is the art of making what you want from things you can get
Re: Czas dla pętli
silnik krokowy, to już coś więcej wiemy.
może da się wysłać mu sekwencje - najlepiej poczekaj teraz na wypowiedź kogoś, kto bawił się z silnikami krokowymi.
pozdro
może da się wysłać mu sekwencje - najlepiej poczekaj teraz na wypowiedź kogoś, kto bawił się z silnikami krokowymi.
pozdro
-
Tutenhamon
- Posty: 30
- Rejestracja: 23 lut 2007 00:00
Re: Czas dla pętli
Można użyć też modułu real - time. tylko, że trzeba go mieć wcześniej. Na stronie Labview są tutoriale jak oni to robią. pozdro
Engineering is the art of making what you want from things you can get
-
kapitan7
- Posty: 114
- Rejestracja: 31 paź 2005 00:00
- Wersja środowiska: LabVIEW 8.2
- Lokalizacja: Cz-wa / Wa-wa
Re: Czas dla pętli
Witam!
A może warto by było zastosować jakąś kartę NI do sterowania ( można tam uzyskać dużo lepsze czasy komunikacji)
A może warto by było zastosować jakąś kartę NI do sterowania ( można tam uzyskać dużo lepsze czasy komunikacji)
kapitan7
-
Tutenhamon
- Posty: 30
- Rejestracja: 23 lut 2007 00:00
Re: Czas dla pętli
Możliwe ale trzeba mieć taką kartę albo pieniądze na nią 
Ściągnąłem ze strony Microsoftu system Windows Xp Embedded 120 dni wolnego użytkowania. Staram się coś znaleźć jak go postawić. Jak coś mi się uda to dam znać. Podobno jest to system czasu rzeczywistego. Pozdro.
Ściągnąłem ze strony Microsoftu system Windows Xp Embedded 120 dni wolnego użytkowania. Staram się coś znaleźć jak go postawić. Jak coś mi się uda to dam znać. Podobno jest to system czasu rzeczywistego. Pozdro.Engineering is the art of making what you want from things you can get
-
vugie
- Posty: 383
- Rejestracja: 17 lis 2006 00:00
- Wersja środowiska: LabVIEW 2009
- Lokalizacja: Warszawa
Re: Czas dla pętli
Też używam silnika liniowego LinMot, kontroler E100 - rewelacyjna zabawka 
Napisałem program do jego obsługi korzystając z protokołu ASCII i RS232. Normalnie cykl pytanie-odpowiedź trwał koło kilkunastu ms (łącznie z konwersją stringa na dbl) - było to ograniczenie spowodowane przez 9600 bodów - domyślne i niezmienialne. Na szczęście okazało się, że nie takie znowu niezmienialne - Szwajcarzy przysłali mi dodatek do firmwaru i uzyskuję czasy cykli 2-3 ms (chyba, że kręcę kółkiem myszy - wtedy 50...). Mam normalny Windows, komputer 1.4. Problem z tym jest tylko taki, że kontrolel działa z bardzo nietypowymi prędkościami, a każdy model i seria z innymi. Jest niby do tego tabelka, ale jak się potem okazało mój kontroler i tak działał ze swoimi prędkościami. Po pierwsze trzeba obsłuzyć COMa z nietypową prędkością (VISA odpada, ale jest alternatywna biblioteka), poza tym musiałem napisać aplikację, która skanuje po wszystkich prędkościach i znajduje te, gdzie jest odpowiedź.
Więc służę pomocą odnośnie LinMota
----------------
W praktyce najlepiej sprawdza mi się nauczenie go całego cyklu pracy za pomocą ich softu (LinMot Commander czy jakoś tak), a potem tylko uruchamianie cyklu w pracy ciągłej.
Poza tym nawet jak masz tylko kilka punktów w okresie, to silnik może ładnie, gładko działać jeżeli zmniejszysz maksymalne przyspieszenie i prędkość - są na to komendy w protokole, mozna też z panelu.
Napisałem program do jego obsługi korzystając z protokołu ASCII i RS232. Normalnie cykl pytanie-odpowiedź trwał koło kilkunastu ms (łącznie z konwersją stringa na dbl) - było to ograniczenie spowodowane przez 9600 bodów - domyślne i niezmienialne. Na szczęście okazało się, że nie takie znowu niezmienialne - Szwajcarzy przysłali mi dodatek do firmwaru i uzyskuję czasy cykli 2-3 ms (chyba, że kręcę kółkiem myszy - wtedy 50...). Mam normalny Windows, komputer 1.4. Problem z tym jest tylko taki, że kontrolel działa z bardzo nietypowymi prędkościami, a każdy model i seria z innymi. Jest niby do tego tabelka, ale jak się potem okazało mój kontroler i tak działał ze swoimi prędkościami. Po pierwsze trzeba obsłuzyć COMa z nietypową prędkością (VISA odpada, ale jest alternatywna biblioteka), poza tym musiałem napisać aplikację, która skanuje po wszystkich prędkościach i znajduje te, gdzie jest odpowiedź.
Więc służę pomocą odnośnie LinMota
----------------
W praktyce najlepiej sprawdza mi się nauczenie go całego cyklu pracy za pomocą ich softu (LinMot Commander czy jakoś tak), a potem tylko uruchamianie cyklu w pracy ciągłej.
Poza tym nawet jak masz tylko kilka punktów w okresie, to silnik może ładnie, gładko działać jeżeli zmniejszysz maksymalne przyspieszenie i prędkość - są na to komendy w protokole, mozna też z panelu.