Jak tam budowa frezarki ?

Czy na takiej karcie jest procesor mocniejszy niz pececie ? :-)

Mozna sporo zsynchronizowac, i jest to wykonalne ... ale nie pod windows :-)

Owszem - pecet i port LPT przy naprawde szybkich sterowaniach moga sprawiac powazne klopoty. Troche zmian w architekturze, troche sprzetu i mamy motion control.

I np maksymalna predkosc silnika krokowego.

J.

NIe tylko coraz szybciej, ale i w odpowiedni sposob przyspieszac. Musisz uwzglednic tez przy sterowaniu rezonanse calego ukladu. Jesli Cie to interesuje to mozesz poczytasc sobie troche na

Jest to wykonalne. W koncu PC to nic innego jak przerosniety mikrokontroler *g*. Ale niestety, nie jest to proste. Do tego juz potrzebny bedzie system spelniajacy wymagania zblizone do hard RT. O desktopowych windowsach mozesz zapomniec, mozesz probowac bawic sie z RTAI albo RTlinuksem, idealnie do tego bedzie sie nadawac QNX (mozna sciagnac za darmo do celow niekomercyjnych), a ich tego nie chcesz to stary poczciwy dos (albo freedos jak nie chcesz piracic). Trzy pierwsze systemy maja te zalete, ze system docelowy bedzie tez systemem devel, co wyeliminuje zbedne rebooty maszyny. Jesli chodzi o same algorytmy zamiany linii z opisu wektorowego na sterowanie silnikami mozesz zainteresowac sie algorytmami Bresenhama. Wywodza sie z grafiki rastrowej, ale jesli tylko da sie przyjac ze silniki maja zawsze taki sam skok to nie powinno byc problemow z zaadaptowaniem ich do wyliczania sterowania frezarka (a nawet jesli nie to kilka godzin spedzonych z kartka i olowkiem powinno pomoc znalezc rozwiazanie). Niestety napisanie programu proste nie bedzie. I bedzie wymagalo "nieco" wiecej umiejetnosci niz posiada przecietny "programista" ktory potrafi narysowac jakies klikadelko w VB czy delphi.

pzdr. j.

Gola maszyna bedzie najlepsza. I wlasnie dlatego jest maly sens robic to na pececie, tzn. "pecetowosc" nie wniesie niczego do projektu (skoro z interfejsu graficznego i tak musimy zrezygnowac...). Szybszy mikrokontroler da rade, a bedzie mozna nim wygodnie sterowac z PC przez RS albo USB.

Nie ma takiej potrzeby. Najlepiej bedzie przechowywac krzywe ruchu w postaci parametrycznej i sobie z nich obliczac wpolrzedne narzedzia. Byc moze brzmi to skomplikowanie, ale jest znacznie lepsze oraz prostsze.

Tu nie ma co myslec, tu trzeba usiasc i to napisac. :-)

Tak, ze Tego co pamietam Leszek pisuje sobie w Bascomie, gdzie wszystko jest "na tacy".

Pozdrawiam Piotr Wyderski

No to (free)dos. Masz gola maszyne, system sie nie bedzie wtracac.

Z jednej strony jest to wygodniejsze, bo nie blokuje komputera, z drugiej sterowanie z peceta bedzie pewnie bardziej elastyczne, bo i zasoby nieco wieksze, i maszyna szybsza. A jak zechcesz robic optymalizacje ruchu narzedzia czy przetworzyc jakas bardziej skomplikowana krzywa to mipsow przyda sie sporo.

Ale wlasnie Bresenhamy do tego sluza. na wyjsciu dostajesz ciag sekwencji lewo/prawo/gora/dol (no dobra, nie na wyjsciu. ale jest to jeden z krokow posrednich)

ze tak sie niedyskretnie zapytam: jakie masz doswiadczenie w projektowaniu programow? :)

o, sa gotowe procedury zamiany dowolej krzywej na sekwencje sterowania silnikow krokowych? ciekawe... :)

pzdr. j.

Podczas dzialania system nie bedzie w ogole wykorzstywany, wiec wychodzi gola maszyna. :-) Z DOS zostanie uzyty w zasadzie tylko loader. Loader jest tez w m.in. GRUBie, wiec na jedno wyjdzie.

To nie potrzebuje duzej mocy obliczeniowej, tylko niezwykle krotkiego i bardzo powtarzalnego czasu reakcji. Jednym slowem: to nie pecet (w typowych dla sieble zastosowaniach).

Tak, tylko takie rzeczy mozna robic off-line na PC, a gotowe wyniki posylac glupiemu kontrolerowi. Przeciez ta plytka nie powinna sie zajmowac optymalizacja trasy narzedzia, ona ma umiec przesunac glowice z punktu A do punktu B po zadanej krzywej. Konstruowaniem tej krzywej powinno zajac sie osobne oprogramowanie.

Ale sa bardzo nieelastyczne. A co, jesli z jakiegos powodu bede chcial poruszac sie narzedziem po hiperboli, a nie prostej? Algorytmy operate na krzywych parametrycznych nie beda z tym mialy najmniejszych problemow.

Hm, ze tak niedyskretnie odpowiem: najpierw 8 lat hobbystycznie zajmowalem sie programowaniem niskopoziomowym oraz DSP, w tzw. miedzyczasie zajmujac pierwsze miejsce w konkursie Optimusa i wygrywajac swojego pierwszego peceta. Nastepnie przez 5 lat studiowalem informatyke na Uniwersytecie Wroclawskim, ktore ukonczylem z ocena 5. Podczas studiow zaliczylem 1,5 roku inzynierii oprogramowania; mam tez certyfikat MCP Microsoftu w dziedzinie projektowania oprogramowania dla Windows. O pracy podczas studiow nie wspominam. Obecnie jestem na studiach doktoranckich z informatyki w swoim macierzystym Instytucie. Czy to zaspokaja Twoja ciekawosc? :-)

Nie mam pojecia, bo nie korzystam z Bascoma. BTW, z tym "na tacy" nie mialem na mysli tego, ze tam sa takie procedury, tylko, ze Leszek bedzie mial zagwozdke, bo to trzeba zrobic samemu. :-)

Pozdrawiam Piotr Wyderski

Ale zeby napisac program ladowany prze GRUBa musisz dopisac sporo kodu przygotowujacego sprzet do pracy. Poza tym dos zapewnie ci obsluge takich upierdliwosci jak np. mysza czy klawiatura. No i przydalo by sie w jakis sposob wprowadzic projekt. wklepywanie z klawiatury wspolrzednych moze i jest niezlym cwiczneiem dla rak, ale raczej nudnym i malo rozwijajacym. W dosie masz zrobiona obsluge dyskow, ktora po prostu mozesz wykorzystac w swoim programie.

A pecet to przeciez procesor obudowany sterta dodatkowego zelaztwa. Ja na prawde nie widze wielkiej roznicy pomiedzy malym kontrolerkiem z dobudowanymi interfejsami i odpowienim oprogramowanie a pecetem z dobudowanymi interfejsami i odpowiednim oprotamowaniem. Moze poza tym drobiazgiem ze jak ktos juz mysli o cnc to peceta zwykle juz ma. BTW. wiele sterownikow robi sie na pecetach. Tylko ze plytka wyglada nieco inaczej i zamiast isa/pci jest pc104/pc104+.

NIe musi ale moze. A skoro juz piszemy oprogramowanie optymalizacyjne to mozemy dorzucic do niego sterowanie silnikami.

Bresenhamy to nie tylko proste ale i kolka i elipsy. Powinno dac sie opracowac dzialajacy na podobnej zasadzie algorytm dla krzywych wyzszego rzedu (o ile juz ktos tego nie zrobil, od dawna nie interesowalem sie tematem). A dla linii i elips bresenhamy raczej beda szybsze od algorytmow operujacych na zmiennym przecinku.

Zaspokaja. I tym bardziej nie moge zrozumiec dlaczego chcesz sie rzucac od razu na klawiature zamiast poswiecic troche czasu na projekt. Mi za kazdym razem ten czas zwraca sie z duuza nawiazka.

moze mam jakas awersje do basicow pozostala z czasow mlodosci, ale nawet przez mysl mi nie przeszlo ze ktos moze chciec pisac to w bascomie a nie np. w C albo asemblerze (albo pascalu na PC). Albo i Adzie :)

pzdr. j.

PS: a tak poza tym to wcale nie uwazam ze oddzielny sterownik silnikow to jest glupi pomysl. Jedynie nieco drozszy :)

Wcale nie tak duzo -- to akurat wiem z cala pewnoscia z "zerowej" reki, kiedys byl mi potrzebny taki kod, wiec go napisalem. On akurat robi za duzo, bo potrafi wykorzystac wieloprocesorowosc i hyperthreading oraz "sam" sie optymalizuje podczas dzialania -- taka zabawka. :-)

To prawda, tu DOS goruje.

Przez RS.

Ale procesor ogolnego przeznaczenia. Bardzo kiepsko sobie radzi z przerwaniami. Kontroler jest tu niezastapiony.

Bo koncepcyjnych roznic nie ma. Ale rozmiary, pobor mocy, pewnosc dzialania -- z kontrolerkiem nie ma szans. :-)

Nie wydaje mi sie to szczegolnie dobrym pomyslem. Skoro te dwa programy robia co innego, to naprawde nie ma sensu ich ze soba scalac. Mamy za darmo modularnosc, bedaca wynikiem samej specyfiki problemu, to po co ja odrzucac? Poza tym to nawet nie sa podobne programy, roznia je ze dwie--trzy "kategorie wagowe".

Nie mylisz sie, jest dosc ogolna metoda konstruowania takich algorytmow. Tylko problem polega na tym, ze przy zmianie strategii ruchu narzedzia trzeba przepisac kawalek programu. Router parametryczny nie wymaga jakichkolwiek modyfikacji.

Dla linii i elips tak, tylko:

a) co z pozostalymi krzywymi? b) po co Ci ta szybkosc? Przeciez i tak nie ma sensu liczyc szybciej, niz sie porusza narzedzie. Obie metody zmieszcza sie z zapasem w dostepnym oknie czasowym, wiec czemu nie zdecydowac sie na lepsza?

Poza tym myslalem raczej o stalym, niz o zmiennym przecinku (bo jest dokladniejszy niz ten ostatni, kosztem mniejszej dynamiki, ktorej i tak nam tutaj do niczego nie jest potrzebna; jest tez znacznie szybszy), ale to szczegol techniczny bez wielkiego znaczenia na tym etapie dyskusji.

Bo jesli chodzi o sam router, to tu nie ma czego projektowac. :-) System sterowania silnikami bedzie wymagal troche myslenia, ale obliczanie wartosci funkcji wymiernej wielu zmiennych w jakims punkcie to nie jest nawet dobre pierwsze zadanie programistyczne dla studentow pierwszego semestru.

I w ogolnym przypadku bardzo dobrze robisz, ale pewnych rzeczy sie nie projektuje, je sie po prostu robi. :-)

Sa ludzie, ktorzy znaja tylko Bascoma, bo jest prosty i widac do rozwiazywania typowych problemow swietnie sie nadaje (bo by go inaczej nie uzywali...). I co oni maja poczac? :-)

W asemblerze raczej nie ma potrzeby. Co do C -- warto sie go nauczyc, bo jest uniwersalny, mimo calej gamy dosc irytujacych cech tego jezyka.

Ada to dobra propozycja, ale czy dla mikrokontrolerow jest dostepny jej kompilator produkujacy kod akceptowalnej jakosci?

Moim zdaniem zwroci sie z nawiazka. Bedzie mozna na pececie robic rzeczy do ktorych pecet swietnie sie nadaje, np. optymalizowanie trasy, nie martwiac sie jednoczesnie o problemy z cyklowaniem i powtarzalnoscia czasu reakcji, bo od tego jest sterowniczek.

Pozdrawiam Piotr Wyderski

Ale to i tak wiecej niz jest wymagane do dzialania programu. Mnie na przyklad nie interesuje zawartosc crt0. Wole sie skupic na zasadniczym problemie, a nie na dodatkach. (chyba ze pisze sobie zabawke. Ale wtedy musze miec z tego jakas radoche:) BTW. co optymalizowales?

Do oddzielnego sterownika i owszem. Ale jesli chcialbys wykorzystac PC to dyski/flopki beda wygodniejsze.

Hm, nie wnikalem na tyle w x86, ale to moze byc dobry argument.

Ale my caly czas rozmawiamy o sterowniku dla cnc zbudowanej przez Jasia Amatora. Peceta ma, bo postuje z niego na grupe. Sterownik musi sobie zaprojektowac i zbudowac. Jasio bogaty nie jest, wiec liczy kazda zlotowke. Do peceta dolozy kilka tranzystorow sklejonych na sline, sterownik musi zaprojektowac i zbudowac inwestujac XY% swoich oszczednosci. Jasio swojej maszynki do produkcji przemyslowej uzywac nie bedzie, wiec warunki pracy dla sterownika nie beda ekstremalne, a przy wykorzystanu sprzetu przez, powiedzmy 1h/dzien niezawodnosc i pobor pradu nie sa parametrami kluczowymi dla przedsiewziecia. Poza tym jesli Jasio nie zainwestowal sporych pieniedzy w konstrukcje mechaniki, tylko zaopatrywal sie w firmie Szuflada&Strych, sam pecet moze okazac sie najmniej awaryjnym elementem.

Zgoda. Ma to w sobie cos z elegancji filozofii unixa. Ale jesli maszynka bedziemy sterowac z pc, ta elegancja zacznie byc upierdliwa, bo kazdy projekt trzeba bedzie przepuscic przez N aplikacji, nie majac nawet mozliwosci poklejenia ich rurkami (dos lub gola maszyna). Ale jesli sterownaie silnikami wyrzucimy do oddzielnego sterownika to nawet nie ma co dyskutowac nad rozdzielniem, bo '51 sie 10 razy spoci zanim wygeneruje jakies rozsadne rozwiazanie dla sensownej wielkosci projektu (przepelniajac w tym czasie klilkukrotnie pamiec).

Ale nie zapominaj ze Jasio amator do sterownika wrzuci jakies '51, program napisze z bascomie. Demonem szybkosci ten duet raczej nie bedzie. Wiec calosc bedzie sie zacinac albo dzialac z predkoscia srednio rozleniwionego zolwia. Wybor algorytmu ma wiec kluczowe znaczenie dla wydajnosci.

Nie wiem jak beda wygladac dane wejsciowe wiec nie odpowiem. Ale zestaw krzywych jakie moga sie pojawic w opisie chyba jest ograniczony.

"Lepszosc" jest pojeciem wzglednym. Jesli iteracja algorytmu bardziej uniwersalnego ma zajac .1s, to jest o co walczyc.

Staly przecinek to bardzo dobry pomysl, o ile wczesniej dobrze sie zastanowisz co zrobic z bledami zaokraglen. Jest to jedno z miejsc gdzie filozofia "siadam i pisze" moze okazac sie zgubna w skutkach. Nie wiem na ile pozwala bascom, ale chyba Jasio Amator moze miec klopoty z wykorzystaniem go w swoim programie.

Router w sensie wyliczenia i optymalizacji trasy narzedzia? Oj, nie bylbym taki pewien. przy frezowaniu 2d moze i jest to banalne, ale jesli chcesz tez uzywac trzecia os, problem robi sie ciekawy (parametryzacja powierzchni).

NIe ma takiego problemu ktorego nie dalo by sie komplikowac w nieskonczonosc:) Rozwiazanie zalezy od przyjetych zalozen, a te przydalo by sie przemyslec.

Projekt zawsze jest. Nie koniecznie formalny, jesli nie na papierze to w glowie. Musisz wiedziec co chcesz osiagnac i jak dojsc do celu. Pisac wg zasady "sie sieda i sie robi" zdarza mi sie dosc czesto, ale nie sa to duze projekty, a raczej male narzadka powstajace w okreslonym celu. CO nie znaczy ze z takich narzadek czasami nie wyrastaja wieksze programiki, ale one tylko utwierdzaja mnie w przekonaniu ze zrobienie nawet zgrubnego projektu przed napisaniem pierwszej linijki kodu nie jest glupim pomyslem:)

Nauczyc sie czegos nowego:) Mi programowanie zaczelo sprawiac ogromna przyjemnosc kiedy z basica na spectrum przesiadlem sie na pascala na xt (tp4.0 iirc).

Asembler sie przydaje do pisania wysoko wydajnych kawalkow kodu (np. jakies przerwanie ktore szybko trzeba obsluzyc)

Z C i C++ jest jak z demokracja. Bardzo kiepski wynalazek, ale do tej pory nikt nie wymyslil nic lepszego:)

NIe wiem, nie bawilem sie. Ale najnowszym zestawie gnunarzedzi dla avr chyba widzialem tez ade, wiec kiedys mozna by sprawdzic.

pzdr. j.

Ale pecet stoi gotowy :-) Troche duze bydle, ale jednak juz zrobione.

J.

W sporej czesci pisalem wlasnie dla radochy. :-)

Przelaczanie kontekstu koprocesora (na potrzeby SSE/SSE2) oraz inne male fragmenty czesto wykonywanego kodu. W zaleznosci od wlasciwosci sprzetu (tzn. czy to 486, czy Pentium 4, jedno-, czy wieloprocesor itd.), wykrytych podczas fazy startowej programu podsystem rozruchowy "pisal" krytyczne z punktu widzenia wydajnosci fragmenty programu.

Co do kosztu, to nie beda to jakies kosmiczne wydatki. Ile kosztuje jakis silniejszy kontroler, np. ATmega 128, mniej niz 50 zl? A poza kontrolerem tam niewiele potrzeba (oprocz elementow sterujacych silnikami, ale one w obu przypadkach beda, wiec sie nie licza). Projekt programu bedzie w obu przypadkach podobny. Jesli chodzi o przewage peceta polegajaca na tym, ze on juz jest, a plytke trzeba dopiero zbudowac, to jest ona bezdyskusyjna, tu nie mam kontrargumentu innego niz mala komplikacja plytki.

To prawda.

Tutaj aplikacje beda dwie: optymalizator i sterownik silnikow, nie trzeba wiec tworzyc kombinacji alpejskich z rurkami. Warto rozdzielic oba programy, przynajmniej na poziomie projektu. Optymalizator trasy nie wie nic o silnikach, a sterownik nic o optymalizacji, wiec dobrze, by tak zostalo. Jesli to ma byc maksymalnie szybkie, to mozna te programy umiescic w osobnych, niezaleznych modulach i scalac w jeden program na etapie linkowania. To chyba akceptowalny kompromis.

I wlasnie o to mi chodzi -- wlasciwe narzedzie do wlasciwych celow. Kontroler ma przyzerowy czas reakcji i mikroskopijne zasoby (z punktu widzenia PC), a pecet odwrotnie -- gigantyczny czas reakcji, pod zwyklymi systemami operacyjnymi liczony w dziesiatkach milisekund oraz praktycznie nieskonczone zasoby. Sterownik silnikow wymaga pierwszego zestawu cech, zaawansowane oprogramowanie optymalizujace drugiego. Stad w rachunku "zyskow i strat" kompletnie nie widze sensu robienia wszystkiego na PC. Tracimy w zasadzie wszystko, co potrafi dzisiejszy pecet (m.in. niezwykle wygodny okienkowy interfejs graficzny), a zyskujemy eliminacje jednego taniego ukladu scalonego.

No tu nie bede polemizowal -- przy odpowiedniej motywacji implementacje kazdego algorytmu mozna spieprzyc. :-) Hm, moze ja sie "asekurancko" z Toba zgodze... Jak sie nie potrafi dobrze programowac, to lepiej wybrac prostsze, choc znacznie bardziej ograniczone rozwiaznie. Tu faktycznie trzeba wiedziec jak to odpowiednio zrobic, wiec moze ja naduzywam slowa "proste"...

Ja rowniez nie wiem, ale gdyby to byla moja frezarka, to bym sie nie ograniczal bez istotnych powodow. :-)

Nie przesadajmy, az takich roznic w szybkosci dzialania nie bedzie. Jesli kontroler ma sprzetowe mnozenie 8x8, to dobra implementacja algorytmu parametrycznego bedzie max. kilkaset razy wolniejsza niz alg. Bresenhama dla prostej (przy nieporownywalnie wiekszej elastycznosci). Przy tych predkosciach ruchu narzedzia oba sie zmieszcza w dostepnym czasie. Pecet ma tu spora przewage, bo na nim mnozenie 32x32 trwa kilka taktow, wiec metoda parametryczna bedzie kilka--kilkanascie razy wolniejsza niz Bresenham. Czyli roznica bez znaczenia -- co kogo obchodzi, ze jeden algorytm potrzebuje 30 us, a inny 500 us, skoro i tak uruchamia sie je co milisekunde, wiec oba dadza rade?

Sciezki obliczen sa bardzo krotkie (nie liczymy "inkrementalnie", jak w algorytmach Bresenhama, tylko kazdy punkt niezaleznie), wiec blad nie bedzie mogl sie skumulowac do zauwazalnych w tym zastosowaniu wartosci. Ile konkretnie? -- no, tu juz trzeba znac dokladna postac danych i troche policzyc. Standardowe

Nie, tylko wyliczenia kolejnych punktow na gotowej krzywej otrzymanej od optymalizatora. To jest obliczenie wartosci funkcji wymiernej wielu zmiennych w punkcie. W szczegolnym przypadku wielomianu niskiego stopnia (dla prostej, elipsy, jakichs rozetek itd.) jesli nie chcemy sie poruszac po "dziwnych" krzywych (choc IMHO szkoda z tej mozliwosci rezygnowac, bo ona duzo nie kosztuje).

Jesli sie to chce zrobic naprawde porzadnie (np. z wybieraniem spojnych obszarow miedzi na plytce, do tego z optymalizacja), to nawet w 2D jest to bardzo trudny problem i tym sie nie zajmuje kontroler. Ale poki co problem polega na tym w jaki sposob w ogole sobie pojezdzic narzedziem, czyli zbudowanie kontrolera, a to jest akurat dosc latwe.

Oczywiscie.

Ale im jest z Bascomem dobrze, wiec musieliby miec silne powody, aby zaprzestac jego uzywania na rzecz prymitywniejszego (choc znacznie sliniejszego) narzedzia. :-)

Pozdrawiam Piotr Wyderski

Mirek snipped-for-privacy@wp.pl wrote: [...]

pzdr. j.