cnc.info.pl - FORUM CNC

witam jestem nowym na tym forum i chcialem prosic o rade . Interesuje mnie tematyka cnc , pracuje nawet na jednej z takich maszyn jednak chcialbym wraz z kolega zbudowac wlasna maszyne , mamy juz plany . Jednak potrzebuje do tej maszynki programu sterujacego i chcialem go sam napisac w delphi , od czego zaczac najlepiej .

Witam.

Polecam Wam najpierw zbudowanie maszynki a potem programu.
Taka kolejnosc pozwoli na lepsze "poczucie" tego co program ma obslugiwac.

No i oczywiscie czekamy na forum na zamieszczenie postepow z prac.

Pozdrawiam.

michal22-1982 pisze:od czego zaczac najlepiej .

zacznij od zmiany jezyka programowania delphi sie nie nadaje, dlaczego ? ... poszukaj na forum bylo juz nascie postow na ten temat.

Witam.

No właśnie. To problem Delphi czy całego windowsa i jego przydziału dostępu do portu LPT ?
Może kolega rozwinąć swoją wypowiedź ?
Uprzedzając - czytałem na forum to co dotyczyło własnych programów. Może nie wszystko. Proszę o jakieś linki do jednoznacznych wniosków wykluczajacych użycie tego środowiska do oprogramowania obrabiarki cnc.
Język to język. Turbo Pascal czy Object Pascal wydaje się tak samo dobry jak każdy inny.
Mój kolega równolegle pracuje nad sterowaniem , które pisze w C++.
Oczywiście nie opracował własnego komponentu dla obsługi portu a jedynie korzysta ze znalezionego w necie gotowca.
Efekt : szarpany dostęp do poru i nierównomierna praca silników. ( oczywiście może to sprawa komponentu i trzeba poszukać innego )
A nie jest to DELPHI.

pozdrawiam

Piromarek

Problem lezy w Windowsach

Step2Cnc Piotra Rakowskiego został napisany w Delphi - działa ( na LPT ).
Proponuję poczytać na forum posty ludzi którzy mieli z nim problemy - czasami wystarczy mieć jakiś śmieć w Windowsach i można zapomnieć o stabilnej pracy ( nawet Mach tego nie zapewnia - proponuję poczytać instrukcję instalacji Macha - daje pojęcie co szkodzi płynnej pracy sterowników LPT ).

Mach działa tylko dzięki bardzo specjalistycznemu sterownikowi który przez system widziany jest jako softwerowa karta dźwiękowa - dzięki temu ma bardzo wysoki priorytet obsługi ( oraz dostęp do 44kHz przerwania - normalnie niedostępnego nawet dla innych sterowników kernelowych).


Właśnie uruchamiam dla pana Piotra sterownik USB do jego programu - ale tu mamy szybki procesor ARM z pamięcią do której ładowany jest plik z wektorami pracy. Po tej operacji ARM już sam przetwarza wektory i może działać nawet odłączony od PC.


Proponuje raczej użyć DOS'a

Bywają komponenty które pozwalają wymusić dostęp do portów na nieco lepszym poziomie niż zarządzanie przez Windows... w końcu sporo programów też pod Win pracuje...
Tak więc pozbędźcie się przesądów chyba że mówimy nie o programiście tylko jakimś skrypciaku...

zahoryzontem pisze:Bywają komponenty które pozwalają wymusić dostęp do portów na nieco lepszym poziomie niż zarządzanie przez Windows... w końcu sporo programów też pod Win pracuje...
Tak więc pozbędźcie się przesądów chyba że mówimy nie o programiście tylko jakimś skrypciaku...

dokładnie...
eee, jak się używa timera z api do generowania przebiegu na lpt, to się potem jęczy, że system zły, środowisko niedobre, rąbek u spódnicy nie taki, itp.
ARM oblicza wektory...zgadza się, ale każdy pecet ma procesor, który mocą bije na głowę 10 armów - trochę asemblera i znajomości architektury procesora i bardzo ładnie można taktować port nawet kilkadziesiąt kHz

jarekk pisze: Po tej operacji ARM już sam przetwarza wektory i może działać nawet odłączony od PC

a co w przypadku estop ?

olo_3 pisze:Po tej operacji ARM już sam przetwarza wektory i może działać nawet odłączony od PC

Napisalem takie oprogamowanie dla Atmegi i bez problemu jest w stanie obsluzyc sterowanie 3D na podstawie wektorow zapisanych w zewnetrzej pamieci ...

olo_3 pisze:a co w przypadku estop ?

Przycisk jest podlaczony pod przerwania procesora wiec moze w dowolnym momecie przerwac sterowanie silnkami a puzniej wznowic od miejsca gdzie zostal on przerzerwany. takich wejsc w procku jest wiecej wiec mozna podlaczyc i oprogramowac i inne zeczy.

vector11 pisze:dokładnie...
eee, jak się używa timera z api do generowania przebiegu na lpt, to się potem jęczy, że system zły, środowisko niedobre, rąbek u spódnicy nie taki, itp.
ARM oblicza wektory...zgadza się, ale każdy pecet ma procesor, który mocą bije na głowę 10 armów - trochę asemblera i znajomości architektury procesora i bardzo ładnie można taktować port nawet kilkadziesiąt kHz

Tak, ale go zmuś abyś dostał 1% jego mocy - w równych przedziałach co 10uS - w Windowsach to praktycznie niemożliwe. Dlatego programy CNC działające pod DOSem, mimo że funkcjonalnie ustępują windowsowym pracują stabilnie.

olo_3 pisze:jarekk napisał/a:
Po tej operacji ARM już sam przetwarza wektory i może działać nawet odłączony od PC
a co w przypadku estop ?

Procesor ma wektory w swojej pamięci flash. Cały proces mogę zatrzymać w dowolnym momencie - przy każdym pojedynczym kroku( 50kHz daje interwał 20uS) Mogę dodać proces hamowania - jeżeli będzie trzeba. Mogę uaktywnić hamulce.W dowolnym momencie mogę uruchomić program - wprzód lub nawet wstecz. Mogę zmienić dynamicznie prędkość.

webserver pisze:olo_3 napisał/a:
Po tej operacji ARM już sam przetwarza wektory i może działać nawet odłączony od PC


Napisalem takie oprogamowanie dla Atmegi i bez problemu jest w stanie obsluzyc sterowanie 3D na podstawie wektorow zapisanych w zewnetrzej pamieci ...

Do jakiej częstotliwości pracy daje radę Atmega ? Jeszcze nie uruchomiłem swojego algorytmu na ARMie ( działa na PC), ale z przeliczeń wyszło mi że 60MHz ARM ledwie to pociągnie ( 50kHz x 4 osie )

webserver pisze:takich wejsc w procku jest wiecej wiec mozna podlaczyc i oprogramowac i inne zeczy.

Mam do dyspozycji ( na razie, w prototypie)
- 4x osie ( step/dir)
- 8 wyjść binarnych ogólnego przeznaczenia
- 2 wyjścia PWM
- 6 wejść dedykowanych krańcówkom ( docelowo 8 )
- wejście e-stop
- 4 wejścia ogólnego przeznaczenia

Docelowo może być ich więcej - w wersji finalnej dojdzie małe FPGA aby buforować sterowanie osiami.