cnc.info.pl - FORUM CNC

Witam Szanownych Kolegów.

Sprawa wygląda następująco - własnie konfiguruje EMC2 poprzez edycję poszczególnych plików.
Mam jednak problem z ustaleniem długości impulsów sterujących pojawiajacych się bezpośrednio na porcie LPT. Innymi słowy sterownik nieczyta poprawnie impulsów sterujących . Wiadom im dalej w las tym więcej dzrzew.Częstotliwość ustawiam jako BASE_PERIOD=100000 ns ponieważ chcę osiągnąć długość impulsu jako 10us, gdzie dwa*BASE_PERIOD stanowi jedno przejscie (jeden step+dir). Natomiast kolejnym problemem jest gubienie kroków przy nawrocie. Może nie będe zbyt orginalny ale odwołam się do mach2 , gdzie w zakładce minimum PULSEWIDTH ustawiam długość impulsu sterującego (wiadomo) a w direction PreChange ustawiam własnie "sekwencje" przy nawrocie. Ma ktoś pomysł jak drugą pozycje wykonać w EMC2.
I tutaj proszę szanownych kolegów o zaopiniowanie tematu.Może robie coś całkiem pod wiatr i naprzeciw wszelkim zasadom.

I jeszcze jedno, czy pozycja FERROR i MIN_FERROR w momencie gdzy nie ma sprzeżenia zwrotnego do programu ma sens , inaczej mówiąc czy mają te dwa parametry bezpośredni wpływ na pojawiające się impulsy na porcie LPT. Ma ktoś jakieś jakieś opinie na podstawie doświadczeń ?



Pozdrawiam
HiTech

Hello

hitech pisze:Innymi słowy sterownik nieczyta poprawnie impulsów sterujących.

Przepraszam, za przyziemne pytanie, ale zakładam, że HAL (piny w LPT) jest poprawnie skonfigurowany, a maszyna z tym sterownikiem i kablem działa poprawnie z innym oprogramowaniem?

hitech pisze:Częstotliwość ustawiam jako BASE_PERIOD=100000 ns ponieważ chcę osiągnąć długość impulsu jako 10us, gdzie dwa*BASE_PERIOD stanowi jedno przejscie (jeden step+dir).

Nie wiem, czy 10us nie będzie za krótko. Wg opisów BASE_PERIOD musi uwzględniać możliwości portu LPT i 10us może być dla niego za krótko. Czy szanowny kolega próbował już ustawić np. 50us i sprawdzić czy nadal gubi impulsy?
Pozatym, wartość domyślna może być jak najbardziej OK, natomiast kalibracji (dobrania) może potrzebować maksymalna prędkość posuwu i przyspieszenie pposuwu. Jeżeli gubi impulsy przy wartościach standardowych, na początek w oprogramowaniu starującym "skręciłbym" parametr "override" do 5% i zobaczył czy przypadkiem mu to nie pomorze. Jeżeli mu się poprawi, to bym pogrzebał przy prędkości i przyspieszeniu (zakładając, że sama wielkość/skala posuwu już jest skalibrowana - można to zrobić bez grzebania w prędkościach i chyba nawet tak powinno się robić). Przy grzebaniu przy BASE_PERIOD warto zaznajomić się z p. 1.3 tutaj.

hitech pisze: Natomiast kolejnym problemem jest gubienie kroków przy nawrocie. Może nie będe zbyt orginalny ale odwołam się do mach2 , gdzie w zakładce minimum PULSEWIDTH ustawiam długość impulsu sterującego (wiadomo) a w direction PreChange ustawiam własnie "sekwencje" przy nawrocie. Ma ktoś pomysł jak drugą pozycje wykonać w EMC2.

Tzn. gubi impulsy, czy raczej maszyna ma luzy? Jeżeli to drugie (zakładam, że to drugie), to jest parametr "BACKLASH", który jest równy luzowi do wybrania przy nawrocie maszyny (podawany w mm, a nie krokach).

hitech pisze:I jeszcze jedno, czy pozycja FERROR i MIN_FERROR w momencie gdzy nie ma sprzeżenia zwrotnego do programu ma sens , inaczej mówiąc czy mają te dwa parametry bezpośredni wpływ na pojawiające się impulsy na porcie LPT. Ma ktoś jakieś jakieś opinie na podstawie doświadczeń ?

Moim zdaniem, przy braku sprzężenia zwrotnego te parametry nie mają znaczenia* oraz, nawet przy sprzężeniu zwrotnym nie mają wpływu na parametry impulsów na porcie LPT.

szdowk

*Tzn. nie mają znaczenia, ale mogą generować błędy. W razie wystąpienia związanych z nimi problemów może istnieć konieczność zwiększenia wartości tych parametrów.

Witam wszystkich.

Koledze szdowk dziękuje za wypowiedzenie się na interesujące mnie zagadnienia.
A teraz do meritum .

Tak port (piny) poprzez plik standard_pinout.hal jest skonfigurowany.

Niezmiernie przydatna okazała się informacja poniżej.

Przy grzebaniu przy BASE_PERIOD warto zaznajomić się z p. 1.3 tutaj.

Po zapozananiu się z dokumentacją sprawa ruszyła z miejsca.

hitech napisał/a:
Natomiast kolejnym problemem jest gubienie kroków przy nawrocie. Może nie będe zbyt orginalny ale odwołam się do mach2 , gdzie w zakładce minimum PULSEWIDTH ustawiam długość impulsu sterującego (wiadomo) a w direction PreChange ustawiam własnie "sekwencje" przy nawrocie. Ma ktoś pomysł jak drugą pozycje wykonać w EMC2.


Tzn. gubi impulsy, czy raczej maszyna ma luzy? Jeżeli to drugie (zakładam, że to drugie), to jest parametr "BACKLASH", który jest równy luzowi do wybrania przy nawrocie maszyny (podawany w mm, a nie krokach).

Niestety niechodzi mi o backslash (wiadomo wystarczy wpisać tylko odpowiednią wartość i załatwione)
W moim przypadku i tutaj posluże się cytatem dla jaśniejszego przedstawienia problemu:

The problem with the G202 is the 20uS hold time requirement. That plus the 11uS latency is what forces us to use a slow 31uS period. But the EMC2 software step generator has some parameters that let you increase the various time from one period to several. For example, if steplen is changed from 1 to 2, then it there will be two periods between the beginning and end of the step pulse. Likewise, if dirhold is changed from 1 to 3, there will be at least three periods between the step pulse and a change of the direction pin.

If we can use dirhold to meet the 20uS hold time requirement, then the next longest time is the 4.5uS high time. Add the 11uS latency to the 4.5uS high time, and you get a minimum period of 15.5uS. When you try 15.5uS, you find that the computer is sluggish, so you settle on 16uS. If we leave dirhold at 1 (the default), then the minimum time between step and direction is the 16uS period minus the 11uS latency = 5uS, which is not enough. We need another 15uS. Since the period is 16uS, we need one more period. So we change dirhold from 1 to 2. Now the minimum time from the end of the step pulse to the changing direction pin is 5+16=21uS, and we don't have to worry about the Gecko stepping the wrong direction because of latency.

Reasumując DRIHOLD rozwiązuje problem przynajmniej w moim przypadku.
Mogłem oczywiście zostawić go w spokoju. W tedy dla lacenty + czas reakcji sterownika na zmiane kierunku maszyna chodzi tempem ślimaka za żówiem. Natomiast po zastosowaniu drihold tworzy się przestrzeń czasowa która pozwoli na spokojne zweryfikowanie sygnału kierunku przez sterownik.


Natomiast FERROR i MIN_FERROR jest dlamnie nadal niejasne . W momencie gdy wyskakuje bład pozycjonowania w programie, zwiększam te dwa parametry. Jak dlamnie są to dość spore wartości (powyżej jeden) i w tym momencie pozycjonowanie maszyny (dokładność) wydaje się być tragiczna. Czy ma ktoś koncepcje jak sprawdzić , czy program idzie po wyznaczonej ścieżce czy może odjeżdza od niej o FERROR.


Jeszcze jedno pytanie do znawców tematu, czy oprócz pliku hal oraz ini występuje potzreba konfiguracji jeszcze inych plików?


Pozdrawiam
HiTech

Hello

hitech pisze: Natomiast FERROR i MIN_FERROR jest dlamnie nadal niejasne . W momencie gdy wyskakuje bład pozycjonowania w programie, zwiększam te dwa parametry. Jak dlamnie są to dość spore wartości (powyżej jeden) i w tym momencie pozycjonowanie maszyny (dokładność) wydaje się być tragiczna.

Tzn. wydaje się, czy tak wyszło z praktycznych testów?

hitech pisze: Czy ma ktoś koncepcje jak sprawdzić , czy program idzie po wyznaczonej ścieżce czy może odjeżdza od niej o FERROR.

Mówiąc szczerze koncepcji nie mam, ale zawsze mogę poradzić, aby poczytać o "Following error" (niestety rysunek jest niedostępny, ale pozostał jego opis). Osobiście zmniejszył bym prędkość maksymalną i przyspieszenie, ale jako że kolegi problemy są względnie specyficzne, to może wymagać dalszego tuningu podstawowych parametrów.

Jaki kolega używa sterownik, ew. w jakiej konfiguracji jest PC'et, który tym steruje i jaka dystrybucja Linuxa jest użyta?

hitech pisze: Jeszcze jedno pytanie do znawców tematu, czy oprócz pliku hal oraz ini występuje potzreba konfiguracji jeszcze inych plików?

Podstawowa dokumentacja mówi, że nie. Nie miałem tak drastycznie zaawansowanych problemów, więc szczerze mówiąc innym plikom nigdy się nie przyglądałem.

szdowk

Witam.

Względem lektury , zmniejszenie przyśpieszenia ,prędkości maksymalnej , zwiększeniu ferror, min_ferror jest lekiem na Joint 0 following error.
Ja bardziej kładłem nacisk na zmniejszenie przyśpieszenia a ferror zwiekszałem jak naj mnie.
Wiadomo , każdy zrobi według własnego uznania i efektów jakie chce osiągnąć.

Co do dystrybucji to obecnie wykorzystuje emc2-ubuntu6.06
Teraz po wstępej konfiguracji EMC2 myślę , że warto "skroić" oprogramowanie(linux , EMC) na własne potrzeby.
Myślę żeby zrobić coś "optymalnego" (jak dlamnie coś pomiedzy coolcnc a ubuntu-emc2) .
Koledzy mają jakieś sugestie, co do pakietów jakimi w wolnej chwili warto się zająć i sobie przekompilaować.




Pozdrawiam
HiTech

Czy kolega widział te opcje? Znalazłem w dokumencie HAL_Documentation.pdf (rozdział 7.1.4):

7.1.4 Parameters

( ... )

· (F L O A T) stepgen.<chan>.steplen ­ Length of a step pulse (step type 0 only).
· (F L O A T) stepgen.<chan>.stepspace ­ Minimum spacing between two step pulses (step type
0 only).
· (F L O A T) stepgen.<chan>.dirsetup ­ Minimum time from a direction change to the begin-
ning of the next step pulse (step type 0 only).
· (F L O A T) stepgen.<chan>.dirhold ­ Minmum time from the end of a step pulse to a direction
change (step type 0 only).

Może to Koledze pomoże. Niestety nie mam oscyloskopu, żeby sprawdzić jak wygląda rezultat.

Co do "optymalizacji" Linuksa, to radzę zacząć od wyłączenia niepotrzebnych usług, sterowników, programów (trzeba przetrzepać skrypty startowe), i zmienić środowisko graficzne na jakieś lekkie (w Ubuntu to chyba będzie problem - więc przynajmniej wyłączyc bajery w Gnome).

Sam właśnie próbuję uruchomić emc pod Slackware 11. EMC2 jest chyba testowane głównie pod Ubuntu - podczas kompilacji pojawiają się problemy z includowaniem plików nagłówkowych, później nie można załadować modułów. To samo jest też z wersją, która dała się uruchomić pod Slackware 10.2. Samo RTAI nie sprawia problemów przy własnoręcznej kompilacji - tylko te opcje są słabo opisane.

Witam.

Czy kolega widział te opcje? Znalazłem w dokumencie HAL_Documentation.pdf (rozdział 7.1.4):

Dokladnie , jak widać w manualu da się to edytować, czyli dopasować idealnie "impulsy" z EMC2 do wymagań naszego sterowania.

Wydaje się jednak być sensowne edytować te parametry przy podglądzie na przebiegi czasowe impulsów.

Niestety nie mam oscyloskopu, żeby sprawdzić jak wygląda rezultat.

Ja również nie posiadam oscyloskopu , żeby zobaczyć przebiegi.
Tak sobie myślałem , żeby podłaczyć wyjścia sygnałów(lpt) do karty muzycznej innego komputera i poprzez jakiś program emulujący działanie oscyloskopu podrażnić się trochę z tematem. Ale jak narazie dla mnie to czysta abstrakcja.

Narazie pozostaje przy obecnej konfiguracji i myślę o skrjeniu oprogramowania na własne potrzeby.

Sam właśnie próbuję uruchomić emc pod Slackware 11. EMC2 jest chyba testowane głównie pod Ubuntu - podczas kompilacji pojawiają się problemy z includowaniem plików nagłówkowych, później nie można załadować modułów. To samo jest też z wersją, która dała się uruchomić pod Slackware 10.2. Samo RTAI nie sprawia problemów przy własnoręcznej kompilacji - tylko te opcje są słabo opisane.

Oprócz doświadczeń kolegi może przyda się komuś ten link:
http://www.cnczone.com/forums/archive/i ... 22969.html


Pozdrawiam
HiTech

Witam szanownych forumowiczów
Pozwolę podpiąć sie do tematu, gdyż mam problem z chińskim sterownikiem na TB6560 polega on na tym ze po stepconf. Poprzez wizarda wg ustawień Morgan`s config oczywiście z moim Jitterem. Konfiguracja przebiegała pomyślnie do momentu testowania poszczególnych osi. Na jednej z osi mam sytuacje następująca: uzwojenia piszczą, ale silnik nie chce zakręcic po dobraniu odpowiedniej prędkości i ruszeniu ręką utrzymuje prędkość, ale o bardzo niskim momencie byle dotkniecie zatrzymuje silnik

Nie będę ukrywał tez faktu ze sterownik ten jest po zwarciu "wypadek z przeszłości" jednak chciałbym się dowiedzieć czy takie działanie jest wynikiem błędnej konfiguracji czy tez następstwem zwarcia oczywiście układ został przelutowany. Podejrzewam ze sterownik mógł zostać uszkodzony o wiele mocniej i nastawiam sie na jego wymianę na nowy, na pozostałych osiach nie dzieje sie nic i to pewnie jest wynikiem zwarcia. Chciałbym sie dowiedzieć się czy jest możliwe ze jakiś parametr jest źle ustawiony.
Proszę o pomoc z góry dziękuję za każdą informacje