PikoCNC Sterownik maszyny CNC via USB

Dyskusje dotyczące działania obsługi programu PikoCNC

jarekk
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 50
Posty: 1701
Rejestracja: 17 mar 2006, 08:57
Lokalizacja: Gdańsk

#81

Post napisał: jarekk » 10 sty 2011, 14:19

Co do USB - jest znacznie lepiej jak jest optoizolacja. ADUM4160 spełnia swoje zadanie - będziemy go niedługo sprawdzać na plaźmie ( miałęm już nawet płytkę z Ethernetem - na razie leży w szufladzie póki nie ma problemów z USB). ADUM na tę zaletę, że FTDI jest zasilany lokalnie (ze sterownika) i nie jest narażony na zakłócenia zewnętrzne.

To wciąż nie jest tak odporne jak ethernet, ale na razie wygląda na akceptowalne.


Co do algorytmów - moje mają małe ograniczenia co do rozmiaru pola maszyny, poza tym pisałem je z myślą o FPGA i krzywych Beziera które docelowo też się tam pojawią. Również z myślą o plug-inie do Macha. Dlatego arytmetyka jest tak pokrętna :-)



Tagi:


prokopcio
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 13
Posty: 1126
Rejestracja: 11 sty 2005, 13:03
Lokalizacja: Grodków
Kontakt:

#82

Post napisał: prokopcio » 10 sty 2011, 14:22

jarekk pisze:Dlatego arytmetyka jest tak pokrętna
Delikatnie rzecz ujmując ;)

Awatar użytkownika

Autor tematu
cosimo
Specjalista poziom 3 (min. 600)
Specjalista poziom 3 (min. 600)
Posty w temacie: 253
Posty: 637
Rejestracja: 21 maja 2008, 10:02
Lokalizacja: Damasławek

#83

Post napisał: cosimo » 10 sty 2011, 15:43

Co do algorytmów - moje mają małe ograniczenia co do rozmiaru pola maszyny, poza tym pisałem je z myślą o FPGA i krzywych Beziera które docelowo też się tam pojawią. Również z myślą o plug-inie do Macha. Dlatego arytmetyka jest tak pokrętna
Rzeczywiście z taką arytmetyką maszyna może mieć pole pracy wielkości Drogi Mlecznej ;-)

Jarek nie ma znaczenia czy chcesz jeszcze zimplementować jakieś beziery czy nie – na końcu i tak zawsze jest do wykonania jeden wektor – dlatego tylko o tym warto mówić.

Jestem przywiązany do mojej metody. Poza tym jest przygotowana aby implementować ją tanim kosztem w FPGA ( mam schemat mojego sterownika w takiej wersji - na razie jednak Cortex-M3 ze 120Mhz zegarem wystarcza na wszystko).
Skoro tak zakręcona arytmetyka dała się zaimplementować to tym bardziej da się 10x prostsza i szybsza.
Mój bardzo skromny programik operuje również na bardzo skromniutkich liczbach 8 bitowych (taki mam procesor) ale z żadnymi wektorami x=3 y=65535 ( UPS tutaj zdradzam czemu zakres pracy jest 600mm przy dokładności 0,01mm ) nie mam problemów - te dwubajtowe liczby + 1 bit na znak i tak przetwarzam wg swoich algorytmów (pochodnych od alg. Bresenhama), które od samego początku działają mi bez najmniejszych problemów i co najważniejsze dla mojego AVR'ka - wyliczenie kroku zajmuje kilkadziesiąt cykli co pozwala generować sygały step do 200kHz na prostych odcinkach przy tak "słabym" procesorze.
No faktycznie Prokopcio się trochę wygadał (do KGB się nie nadaje ;-)) ale „mądrej głowie dość w dwie słowie” –czy jakoś tak ;-)


jarekk
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 50
Posty: 1701
Rejestracja: 17 mar 2006, 08:57
Lokalizacja: Gdańsk

#84

Post napisał: jarekk » 10 sty 2011, 15:58

To nie pole pracy jest czynnikiem który mnie "zmusił" do użycia takiej a nie innej metody.

Po prostu brutalna rzeczywistość i błędy zaokrągleń ( zarówno w interpolacji jak i samym poźniejszym "wykonywaniu" wektorów).

Nie wiem jak Wy - ja rozkładam ostateczny ruch na składowe ( X,Y,Z,A ) i potem dla każdej liczę niezależnie prędkości i przyspieszenia ( dane wejściowe mojej maszynki na procku).
I muszę mieć gwarancję że w punkcie końcowym te składowe się "spotkają" w jednym momencie czasu - inaczej trzęsie maszyną ( jeżeli składowe "skończą ruch" w różnym czasie).

Aha - sama "maszyna licząca" jest już bardzo szybka. 4 osie, 64 bitowa arytmetyka i 120MHz procesor daje częstotliwość pracy do około 100kHz ( przy obciążeniu procesora na poziomie 55% ). Gdyby mi zależało to by się dało wszystko wyżyłować do 200kHz ( używając assemblera w kilku miejscach) - na razie nie mam tego jednak w planach.

Awatar użytkownika

Autor tematu
cosimo
Specjalista poziom 3 (min. 600)
Specjalista poziom 3 (min. 600)
Posty w temacie: 253
Posty: 637
Rejestracja: 21 maja 2008, 10:02
Lokalizacja: Damasławek

#85

Post napisał: cosimo » 10 sty 2011, 19:02

Przypuszczam, że 90% spraw mamy rozwiązane podobnie – różnica jest w sposobie liczenia interpolacji - dosłownie kilkanaście linijek programu. Pierwsza, którą napisałem (na liczbach całkowitych) rozjeżdżała mi się chyba 2mm na dwu metrowym odcinku (wektor pod kątem gdzieś 47 stopni) - zachodziło takie zjawisko jak opisałeś:jedna oś szła wolniej, druga wersja (na floatach) była znacznie lepsza (choć nie idealna) ale za to pożerała dużo więcej czasu procesora. Trzecia (na liczbach całkowitych) – gwarantuje, że nie rozjedzie się nawet jak wektor ma 1km. Wszystko kwestia metody liczenia – kilkanaście linijek kodu.
Aha - sama "maszyna licząca" jest już bardzo szybka. 4 osie, 64 bitowa arytmetyka i 120MHz procesor daje częstotliwość pracy do około 100kHz ( przy obciążeniu procesora na poziomie 55% ). Gdyby mi zależało to by się dało wszystko wyżyłować do 200kHz ( używając assemblera w kilku miejscach) - na razie nie mam tego jednak w planach.
U mnie "na MAX" też chodzi 200khz choć procek taktowany jest tylko 72MHz ;-)


jarekk
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 50
Posty: 1701
Rejestracja: 17 mar 2006, 08:57
Lokalizacja: Gdańsk

#86

Post napisał: jarekk » 10 sty 2011, 21:39

cosimo pisze:Wszystko kwestia metody liczenia – kilkanaście linijek kodu.
Dokładnie - obecnie wybieram oś nadrzędną ( najdłuższą ) i reszta podlega kompensacji błędów tak że mam 100% gwarancji że się nie rozjedzie. Dla każdego wektora liczę błąd jak mi wyjdzie na procku ( procek chodzi na stałym przecinku - kombinacja 64 i 32 bitowego dodawania). Tak, dojście do takiego działającego algorytmu zajęło trochę czasu oraz prób.

72Mhz ? Jakiś ARM7 - polecam przejście na Cortexa - z tych samych MHz wyciąga około 1.3 wydajności ARMa-7 ( przynajmniej na moim kodzie).

U mnie procedura obsługi generacji kroków zajmuje około 50% czasu - reszta to logika maszyny stanów, obsługa wejść/wyjść komunikacji - etc. Poza tym jestem leniwy i piszę głównie w C - rzadko assembler.

Awatar użytkownika

Autor tematu
cosimo
Specjalista poziom 3 (min. 600)
Specjalista poziom 3 (min. 600)
Posty w temacie: 253
Posty: 637
Rejestracja: 21 maja 2008, 10:02
Lokalizacja: Damasławek

#87

Post napisał: cosimo » 10 sty 2011, 22:31

Dokładnie - obecnie wybieram oś nadrzędną ( najdłuższą ) i reszta podlega kompensacji błędów tak że mam 100% gwarancji że się nie rozjedzie. Dla każdego wektora liczę błąd jak mi wyjdzie na procku ( procek chodzi na stałym przecinku - kombinacja 64 i 32 bitowego dodawania). Tak, dojście do takiego działającego algorytmu zajęło trochę czasu oraz prób.
Dobra niech Ci będzie – najważniejsze, że działa i jesteś zadowolony ;-) Chciałem Ci tylko uzmysłowić, że strzelasz z armaty do muchy ;-)
72Mhz ? Jakiś ARM7 - polecam przejście na Cortexa - z tych samych MHz wyciąga około 1.3 wydajności ARMa-7 ( przynajmniej na moim kodzie).
Właśnie mój projekt oparty jest o CORTEXA M3 a dokładnie LPC1343 ;-) Programy na uC też piszę wyłącznie w C (i też jestem leniwy –przynajmniej tak twierdzi moja żona) ;-)


jarekk
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 50
Posty: 1701
Rejestracja: 17 mar 2006, 08:57
Lokalizacja: Gdańsk

#88

Post napisał: jarekk » 10 sty 2011, 23:04

cosimo pisze:Chciałem Ci tylko uzmysłowić, że strzelasz z armaty do muchy ;-)
To fakt - ja mam LPC1768 lub LPC1769. Wolę mieć jak najwięcej SRAMu.

Awatar użytkownika

Autor tematu
cosimo
Specjalista poziom 3 (min. 600)
Specjalista poziom 3 (min. 600)
Posty w temacie: 253
Posty: 637
Rejestracja: 21 maja 2008, 10:02
Lokalizacja: Damasławek

#89

Post napisał: cosimo » 12 sty 2011, 09:38

prokopcio napisał/a:
Jedyne co mnie denerwuje to interfejs USB, który z chęcią bym zmienił na coś konkretniejszego. Już nie mam kłopotów ale po przejściach wiem, że do zastosowań w przemyśle się nie nadaje (chyba, że tak jak u Jarka -> wysłać wszystko i zapomnieć ! ).
Prokopcio a w jakiej formie teraz sprzedajesz swój sterownik –z optoizolacją? Jest sporo sterowników w oparciu o USB (np. CncGraf) i jakoś nikt ni narzeka. Poza tym w warunkach przemysłowych nie odważyłbym się (teraz – gdyż kiedyś się odważałem ;-)) podłączyć coś do wyjścia uC bez optoizolacji (np. kabel z krańcówką).

Na koniec jeszcze link przejściówka ethernet->COM - w Twoim (i moim) przypadku do wykorzystania chyba bez większych problemów.
http://www.shop.kristech.eu/product_inf ... anguage=pl


prokopcio
ELITA FORUM (min. 1000)
ELITA FORUM (min. 1000)
Posty w temacie: 13
Posty: 1126
Rejestracja: 11 sty 2005, 13:03
Lokalizacja: Grodków
Kontakt:

#90

Post napisał: prokopcio » 12 sty 2011, 10:46

cosimo pisze:w jakiej formie teraz sprzedajesz swój sterownik –z optoizolacją?
Bez optoizolacji...
cosimo pisze:Jest sporo sterowników w oparciu o USB (np. CncGraf) i jakoś nikt ni narzeka.
Nikt nie narzeka teraz, Pierwsze wersje CncGraf wieszały się nagminnie ale od kiedy stosują emi filtry to jest ok. Na moje też nie narzekają (już :) )
cosimo pisze:nie odważyłbym się (teraz – gdyż kiedyś się odważałem ) podłączyć coś do wyjścia uC bez optoizolacji (np. kabel z krańcówką).
Ja mam na odwrót... kiedyś się nie odważałem (miałem o dziwo identyczny układ optoizolacji z Twoim) a teraz się odważam :) nie uszkodzisz komputera tylko kontroler ale na to nie pomoże nawet optoizolacja w Twoim (Naszym) wykonaniu. Rezygnacja z oproizolacji była podyktowana brakiem miejsca a uparłem się na zwartą metalową obudowę do bezpośredniego podpięcia zamiast kabla LPT. Jak miałem kiedyś problem z zakłóceniami na USB to optoizolacja nie pomagała, teraz to już niema znaczenia.

Planuję wrócić do optoizolacji (klient lepiej na to patrzy) ale muszę zaprojektować jakąś mądrą obudowę...
cosimo pisze:przejściówka ethernet->COM
Tak, znam, myślałem, to dobry pomysł ale psuje mi plany zwartej i bardzo prostej (taniej) konstrukcji wraz z obudową.

ODPOWIEDZ Poprzedni tematNastępny temat

Wróć do „PikoCNC”