No bo jeśli wyświetla jitter rzędu miliona, no to wszystko jest jasne i komputer do Linuxcnc się po prostu nie nadaje. (Przynajmniej z danym kernelem współpracować nie będzie, co nie znaczy że z innym nie pójdzie, ale to inny temat).
Ale jeśli wyświetli 50 tysięcy, to co to właściwie znaczy ?
Latency-test wyświetla wartość najdłuższego zmierzonego opóźnienia, a może to znaczyć tyle, że komputer zgubi jeden impuls raz na kilka minut ...
Najpierw trochę teorii.
Mało kto sobie zdaje sprawę z tego, że Linuxcnc działa ZAWSZE w ZAMKNIĘTEJ PĘTLI sterowania, nawet jeśli używamy silników krokowych, które nie zwracają rzeczywistej pozycji. Działa to wtedy w ten sposób, że liczone są wygenerowane impulsy step, a wynik jest przeliczany i porównywany z zadaną pozycją.
Wynika z tego, że jeżeli komputer nie będzie się wyrabiał z generowaniem impulsów, to będzie rosła różnica pomiędzy pozycją zadaną a rzeczywistą, nawet jeśli do komputera nie będzie podłączona żadna maszyna, żaden napęd i żaden sterownik.
Ten błąd nazywa się folowing error, w skrócie ferror.
W pliku ini możemy ustalić wartość ferror przy której Linuxcnc przerwie pracę i wyświetli komunikat o błędzie.
No to już wszystko jasne - piszemy odpowiedni config, każemy niepodłączonej maszynie jechać w nieznane i czekamy kiedy wystąpi ferror ...
Zrobiłem pierwsze próby i wygląda na to, że bingo.
Config, a właściwie interesujący nas fragment, wygląda tak :
Kod: Zaznacz cały
[JOINT_0]
TYPE = LINEAR
HOME = 0.0
MIN_LIMIT = -0.001
MAX_LIMIT = 200000.0
MAX_VELOCITY = 1.0
MAX_ACCELERATION = 1000.0
STEPGEN_MAXACCEL = 1250.0
SCALE = 100000.0
FERROR = 0.01
MIN_FERROR = 0.01
HOME_OFFSET = 0.0
[AXIS_Y]
MAX_VELOCITY = 1.0
MAX_ACCELERATION = 1000.0
MIN_LIMIT = -0.001
MAX_LIMIT = 200.0
SCALE = 100000.0 przy MAX_VELOCITY = 1.0 to jest dokładnie 100 kHz, czyli wartość mocno przegięta, ale o to właśnie chodzi.
Natomiast FERROR = 0.01 przy SCALE = 100000.0 oznacza że program się zatrzyma gdy zgubi tysiąc kroków.
Oczywiście można te wartości zmienić.
No i oczywiście 1 mm/s to 60 mm/min ...
W praktyce wygląda to tak :
Może słabo widać, ale różnica jest w poleceniach MDI i przebytej drodze.
Chodzi o to, że im bardziej zadana prędkość przekracza prędkość krytyczną, czyli maksymalną jaką komputer jest w stanie obsłużyć, to tym szybciej program się wykrzaczy i tym mniejszy dystans zdąży przebyć.
Tutaj, dla tego konkretnie komputera i tych konkretnie ustawień, program przy prędkości 20,003 mm/min przebył drogę 69,811 mm zanim się wywalił, a przy prędkości 20,002 mm/min 84,871 mm, czyli dużo więcej niż po różnicy prędkości by wyglądało, ale tak właśnie ma być, bo zależność jest nieliniowa - schodząc poniżej prędkości krytycznej można jechać w nieskończoność ....
Biorąc pod uwagę, że testowany komputer można zostawić na wiele godzin, wygląda na to, że dla zadanego okresu base_period można bardzo precyzyjnie ustalić maksymalną częstotliwość generowanych impulsów.
Tak dla informacji, testowany był komputer Lenowo M78 (AMD A4) z moim kernelem 4.14.148-rtai, isolcpus=1 i base_period=30000. Spodziewam się po nim około 30 kHz i próby zdają się to potwierdzać. Jitter w latency-test potrafi skoczyć do 60000, ale to się zdarza raz na dwie minuty ...
