obia tematy wymagałyby napisania programu sterującego do PC jednak ten pierwszy byłby chyba prostszy i jednocześnie komplikowałby nieco oprogramowanie w samym sterowniku silników , natomiast drugi proporcjonalnie odwrotnie , niestety nie rozwiązuje to problemu adaptacji sterownika do jakiegoś już napisanego programu ... może się mylę bo nie znam ich wszystkich ...
Chyba że w przyszłości powsałby jakiś program OpenSource , gdzie implementacja kodu sterownika byłaby łatwiejsza ...
Bo może się okazać , że koszt sterownika byłby poza zasięgiem przeciętnego amatora CNC ...
Piszę to jako praktyk elektronik/informatyk , nie jako teoretyk idealista ...

anjak pisze:Co do RS teoretycznie wystarczą 3 kabelki do PC ale jeszcze jest 4 inne, które warto wykorzystać
Zakładając transmisje 8n1 (10 bit na znak) to przy 115200 / 10 mamy 11 520 bajtów na sekunde (teoretycznie).
RS jest ładnie opisany, prosty w obsłudze. Szybciej przez LPT tu można 100kB mieć na spoko a najmniej siły do włożenia kabelka wymaga USB ale soft do tego jest potrzebny a na tym forum jest cisza.
Program do obsługi, można z corela lub innego ze standardem hpgl, gcode
lub własny - a co !

Chyba nie zrozumieliśmy się co do RS232, to co opisujesz to definiuje niejako już sam standard i nie podlega to dyskusji , jednak chodzi mi o to jaki format danych ma być przesyłany po takim interface ... bo z tego co wiem to większa część programów CNC z obsługą RS budowana jest pod dedykowane sterowniki ... i tam są przesyłane konkretne rozkazy i dane do kontroli sterownika i cały cymes w tym aby wiedzieć jakie i co do czego ... a to nie jest już w większości przypadków opisane ...
A co do USB to są dostępne scale do obsługi tego standardu , nawet widziałem gdzieś zrobione coś takiego na tzw "piechotę" na jakimś AVR (konwerter USB -> RS232) , jednak problem pozostaje w napisaniu odpowiedniego sterownika (windows) pod USB ... a to już nie jest taka prosta sprawa ... chyba że pozostaniemy przy standardowym emulującym port szeregowy ...
Jeśli chodzi o własny program CNCOpenSource to jest już powołany osobny dział w tym celu - ZAPRASZAMY tam wszystkich programistów !!!

ottop pisze:Jak tylko zdecyduje jakie rozwiązania sastosować (przetworniki DAC czy PWM) zabieram się za schematy i soft (Eagle i BASCOM-AVR). Jeśli chodzi o procesor na początek myślę jednym procesorem sterować jedną oś sygnały step/dir. Jak się uda to można będzie pomyśleć nad bardziej zaawansowanym sterowaniem - RS, enkodety itp.

Wydaje mi się że sam projekt w eagle tutaj nie wystarczy , powinniśmy pomyśleć nad wersjami dokumentacji w PDF bo nie wszyscy na codzień stosują taki soft ...

Co do BASCOM'a to wydaje mi się że to moze być niewystarczające bo nie zapanujemy nad kodem optymalnym czasowo , chyba że zrobimy hybrydę ze wstawkami czasowo-krytycznych procedur w assemblerku ...

Co do RS232 to trzeba by się zastanowić z jakim oprogramowaniem taki sterownik miałby pracować , bo wydaje mi się że protokoły komunikacji szeregowej sterowników nie są zunifikowane i jeszcze dochodzi problem ich poznania ... bo nie wszystkie mogą być jawne (opisane) ...

ottop pisze:Faktycznie zamiast 2313 lepszy byłby ATtiny26 a może nawet ATmega8 – nie chodzi nawet o szybkość ale o ich generatory PWM – posiadając 2 kanały możemy pominąć przetworniki DAC.

zgadzam się z kolegą , jednak przetworniki D/A oparte na PWM mogą nam popłynąć w funkcji temp. i czasu , ale to może wystarczy do tych zastosowań ...
A co do szybkości to przy mikrokroku może to być istotny parametr .... nie powinno się go umniejszać ...

Mam pewne małe sugestie ...

Proponowałbym zastosować zamiast AT90S2313 nowszy procek ATTiny26 jest nieco szybszy (16MHz) oraz posiada przetwornik A/D (ten może się przydać)
Co do przetwornika (D/A) to może szkoda 8 pinów tak "małego" proca dla DAC08 (leciwy to scal) , może lepiej jakiś DA szeregowy np Maxim'a (np MAX500) lub inny odpowiedni do potrzeb ....