jarekk pisze:Ja to robię tak - na początku przerwania obsługuję piny z poprzedniego przeliczenia...

Bardzo sprytnie. Mogę spytać co jest źródłem przerwań? Pytam, bo STEP-y nie są sygnałem synchronicznym a ich generowanie np. dla 5 osi będzie chwilami wymagało przeliczenia wszystkich równocześnie (10us).

jarekk pisze:Ja używam tego sposobu. Tyle że faktycznie - obliczenia może nie są skomplikowane (tylko dodawanie), ale jak podzielić 16MHz na 100kHz kroku to nie ma wiele czasu .

Jak by nie liczyć wszelkie kalkulacje procesor musi wykonać najpóźniej w połowie okresu, jakieś 5us Jeśli w tym czasie uda się przeliczyć 3 czy nawet 4 osie, to sterowanie praktycznie gotowe

markcomp77 pisze:mi przyszedł do głowy taki prosty sposób:

Osobiście zakończył bym projekt na "-------śruba--------" z prostej przyczyny. Jeśli po wykonaniu ruchu przeciwnego oś wróci na tą samą pozycję, to niczego nie trzeba sprawdzać (zakładam, że programista wie co napisał)

pitsa pisze:Sposób ułożenia pinów w LPT jest nieciekawy.
W tym komputerku są ładniej ułożone i jest ich więcej.

No to mnie Kolega przekonał, kupię Cortexa... kiedyś, kiedy narzędzia będą darmowe

pitsa pisze:OK. Spróbuję z tą gotową płytką ARM. Wystają z niej piny, nie trzeba lutować,

Jak patrzę na mojego PC, to z portu LPT też wystają piny i nie trzeba lutować, procek 2,4G 1G ramu i 80G HDD, klawiatura a wyświetlacz 19". Twórcy TurboCNC, Macha, Stepa itd też zauważyli, że wystarczy tylko napisać program...

jarekk pisze:a jednak wciąż bym proponował coś takiego jak np.

Fajne, choć jakoś nie mogę znaleźć wydajności procka a powinna to być informacja nr 1.
Jest druga strona medalu - nie każdy będzie programistą i nie trzeba kupować drogich narzędzi, żeby się o tym przekonać.
W wypadku Atmela AVRStudio5 kosztuje 0pln, programator STK200/300 z wysyłką 15pln, płytka prototypowa ATMEGA8 40pln i to wszystko.

Yogi_ pisze:Coś takiego masz na myśli? :

To jest rampa prostoliniowa jak w Mach Motor tuning. Na początku filmiku nachylenie jest większe, na końcu - mniejsze.

Yogi_ pisze:te trafianie w cel to tak nie bardzo.

Nie bardzo rozumiem w jakim sensie?
W ten sposób działają wszystkie programy sterujące maszynami.

Yogi_ pisze:W stosunku do czego? I tego tyczyło się moje pytanie. Widać mętnie wyrażone.

Do jednostki czasu.

markcomp77 pisze:nie warto zniechęcać do arduino -- ono już się obroniło

Nikogo nie zniechęcam, wyraziłem tylko opinię.

Yogi_ pisze:Czy nie lepiej liczyć rampę w stosunku do masy poruszanej? Rampa dla max_speed (tej samej) będzie różna dla tras 1000 i 100 mm.

Rampa to nie masa ani droga, tylko zbocze (nachylenie) prędkości. Sprawa jest prosta przy ruchu jednostajnie przyśpieszonym. Znacznie trudniej kiedy dodajemy zrywy, bo program musi sprawdzić czy silnik osiągnął prędkość maksymalną, czy nie a wówczas trzeba skorygować krzywą zrywu podczas hamowania, żeby trafić w "cel".

markcomp77 pisze:zastanawiam się ile przerwań zegarowych na raz... ale ze 2 by się przydały, aby elegancko to ułożyć

Procesory jednordzeniowe nie mogą obsługiwać jednocześnie więcej niż 1 przerwania.

markcomp77 pisze:czy atmega8 ma możliwość wyzwalania 2 przerwań czasowych na raz?

Można wyzwolić wszystkie przerwania na raz (choć będzie trudno) jednak wykonane zostaną kolejno, zgodnie z priorytetem.

Jeśli chodzi o priorytety: najważniejszym jest generowanie impulsu STEP, więc najwyższy priorytet powinien otrzymać timer.

W kwestii ARDUINO uważam, że to podobna proteza jak BASIC STAMP Microchipa. Kolejny kompilator, kolejna płytka do kupienia.