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
