Opóźnienia inne niż milisekundowe

[fajfi]

Cześć,
od niedawna kręcę sobie silnikiem krokowym bipolarnym. Chodzi bardzo ładnie, ale jest pewna niedogodność co do ustawiania prędkości jego obrotów.
Otóż wykonanie kroku polega u mnie na wysyłaniu stanu wysokiego na określony pin w porcie LPT. Częstotliwość z jaka wysyłam te impulsy jest oczywiście proporcjonalna do prędkości obrotowej.
Między kolejnymi impulsami trzeba podać opóźnienie. Jak wiadomo wszelkie opóźnienia są podawane w milisekundach, ale powoduje to, że prędkości są że tak powiem skwantowane - pojawia się ogromna liczba prędkości, których nie jestem w stanie ustawić. Np. przy opóźnieniu 2 ms, otrzymuje prędkość ok. 1 obr/400 ms, zaś gdy opóźnienie zmienię na 3 ms, to otrzymam prędkość 1 obr/600 ms, a wszystko co pomiędzy znajduje się nimi jest dla mnie nieosiągalne.
Czy istnieje jakiś patent na to, żeby dostępne prędkości były w większym stopniu płynne. Jakieś opóźnienia podawane np. w dziesiątych lub setnych częściach milisekundy? A może jeszcze jakoś inaczej?
Fajfi

[smiga]

Na sprzęcie innym niż PC z Windows'em (np. systemy RT, cRIO z FPGA) można ustawić zegar Timed Loop MHz).
W palecie Real Time/ RT Timing są VI'e Tick Count, Wait i Wait Until Next Multiple, które można ustawić w us ... ale znowu Windows nie jest deterministyczny więc to nie zadziała.

Pod Windows'ami można kombinować wstawiając kawałek kodu, który coś będzie robił (np. wypełniaj tablicę w pętli) co zajmie jakiś kawałek czasu.
Niestety trzeba dla danego komputera eksperymentalnie dobrać ile czasu dana operacja zajmie - z powtarzalnością jest więc problem.

... chyba, że Koledzy mają fajniejsze pomysły...

[fajfi]

ale znowu Windows nie jest deterministyczny więc to nie zadziała.

Jak należy rozumieć powyższe zdanie, że windows nie jest deterministyczny?

[bogdani]

Windows zdecydowanie nie jest deterministyczny.
To znaczy że twój program może zwolnić, bo np. Windows zaczyna obsługiwać myszkę na USB, albo odczytywać CD. Wtedy twoje założenia dla deterministycznej aplikacji przestają być prawdziwe.
Można próbować z tym walczyć przez wyłączanie niepotrzebnych usług, priorytety aplikacji, itd. ale ciągle zostaje ziarenko niepewności czy to wystarczy.

bogdani

[finch18]

Witam,

Mam podobny problem więc podłącze się do tematu. Steruję silniczkami krokowymi za pomocą labVIEW. Impulsy step i dir przesyłam przez rejestr danych LPT, następnie przez płytkę izolująca do sterowników. Całe dogadywanie z I/O i petle jakie należy zastosować wydają się ok. Do ustawiania częstotliwości używam controlkę podpiętą do opóźnienia (Wait Until...). W Pętli while jest zrobiony kanał z zmienną typu boolean i negatorem. Czyli za każdym obiegiem pętli wartość zmienia się na przeciwną, to podpięte jest do case gdzie wpisywane są bity do rejestru danych itd....

Problem wygląda tak. U mnie na komputerze program działa bardzo dobrze ( 2*2,66Ghx 2gb ram) natomiast na uczelni przy procesorze podobnym i 512mb ram niemiłosiernie silnik szarpie (sprawdzane na 2 komputerach na uczelni). Widać to szczególnie przy max częstotliwości jaką mogę osiągnąć 500Hz i przy rozruchu +1Hz na obieg pętli. W domu mi rwie ale tylko wtedy jak wykonuje w tle inne operacje typu otwieranie programu. Ale tylko podczas otwierania. Np programem Prime95 obciążyłem procesor na 100% i zostawiłem go włączonego, następnie włączyłem program sterujący i dalej silniczki chodziły płynnie.

Może ktoś z Was spotkał się z takim problemem, albo wie jak to rozwiązać . Otwieranie czegoś w tle nie obciąża procka praktycznie w ogóle a mimo to rwie silnikiem. Zależy mi na stabilnym sterowaniu z LPT gdyż cały program sterujący jest praktycznie gotowy a zmiana sposobu sterowania w tym momencie skomplikuje sprawę projektu bardzo :/

finch18

[bogdani]

Zauważ, że problem jest w przypadku otwierania programy, więc zakładam podczas pracy dysku twardego.
Wtedy procesor zajęty jest operacjami we/wy dodatkowo magistrala PCI również zajmuje się przesyłaniem danych.

W przypadku komputer z Windows i 512 MB RAM sytuacja wygląda tak, iż zwykle (zależy od ilości uruchomionych usług) kończy się RAM i system zaczyna zapisywać informacje w pamięci wirtualnej i mocna korzysta z dysku twardego.
Zwróć uwagę czy momenty przycinania nie zbiegają się z pracą dysku.