Realna ocena mozliwości komputera do Linuxcnc.

[tuxcnc]

Od pewnego czasu uważam latency-test za pomysł idiotyczny, a jego wynik za niemiarodajny.
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

Wszystko da się przeliczyć, tylko trzeba uważać na jednostki.
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 ...

[grg12]

Interesujące. Nie sądziłem ze program może "zgubić" impuls - myślałem że przy dużym jitterze czas trwania kroku jest zmienny i mechanika nie wyrabia z przyśpieszeniami...

[drzasiek90]

Czy jeśli jitter skacze np do 200us a okres bazowy jest 50us to oznacza, że za każdym razem kiedy wystąpi opóźnienie 200us to oprogramowanie zgubi 3 wywołania obsługi generowania sygnałów? Przecież to bez sensu.
A nie jest tak, że "żądanie obsługi" trafia do kolejki FIFO i następnie jeśli starczy czasu procesora to generowanie jest "nadrabiane" czyli wywoła się 3 razy pod rząd?

[tuxcnc]

A nie jest tak, że "żądanie obsługi" trafia do kolejki FIFO i następnie jeśli starczy czasu procesora to generowanie jest "nadrabiane" czyli wywoła się 3 razy pod rząd?

Nie jest.
Jeśli karabin maszynowy strzela np. 600 strzałów na minutę i się zatnie, to wystrzeli np. 400 przez pierwszą minutę, potem znowu będzie strzelał 600 strzałów na minutę, więc tych dwustu nie nadrobi i po dwóch minutach wystrzeli 1000 a nie 1200. Jeśli wystąpią kolejne zacięcia, to ilość brakujących strzałów będzie rosła.
Test polega na ustaleniu właśnie takich, granicznych warunków, żeby program nie miał kiedy nadrobić straconego czasu.

[drzasiek90]

Jeśli karabin maszynowy strzela np. 600 strzałów na minutę i się zatnie, to wystrzeli np. 400 przez pierwszą minutę, potem znowu będzie strzelał 600 strzałów na minutę, więc tych dwustu nie nadrobi i po dwóch minutach wystrzeli 1000 a nie 1200. Jeśli wystąpią kolejne zacięcia, to ilość brakujących strzałów będzie rosła.

Skąd wogóle to porównanie?
Karabin maszynowy to urządzenie całkowicie mechaniczne. Jeśli karabin maszynowy się zatnie to przestanie strzelać aż do momentu usunięcia zacięcia i ponownego przeładowania przy użyciu zewnętrznej siły. Zacięcie karabinu w żadnej sposób nie zmienia szybkostrzelności.
Tu jest system operacyjny który to wszystko kontroluje. Muszę się temu dokładnie przyjrzeć bo to burzy mój pogląd na temat działania tego oprogramowania. Robiłem testy na komputerze z jitterem dochodzącym do 50us. Base period ustawiłem na 7.5us (double step wyłączone). Po godzinie pracy mechaniczny pomiar zgubienia kroku nie wykazał żadnego błędu (powrót na pozycję startową z czujnikiem zegarowym). Linuxcnc też nie wyrzucił żadnego błędu pozycji.
Jedynie nie wiem jaką wartość miałem FERROR bo pozostała domyślna z wizarda.
Błąd pozycji pojawiał się tylko w sytuacji, gdy wprowadziłem za niską wartość base_period a komputer był za słaby. Obciążenie procesora było zbyt duże i się nie wyrobił.
I jeszcze dodam, zanim zaraz zostanę osądzony o pisanie bredni lub spamowanie:
Nie twierdzę, że nie masz racji... Jedynie wyrażam swoje zdziwienie i chęć zweryfikowania.

[tuxcnc]

Zacięcie karabinu w żadnej sposób nie zmienia szybkostrzelności.

Ale zmienia ilość wystrzelonych naboi.
Ilość niewystrzelonych naboi to ferror.
Dopóki nie zrozumiesz tego przykładu, nie mamy o czym rozmawiać.

[drzasiek90]

Jeśli karabin maszynowy strzela np. 600 strzałów na minutę i się zatnie, to wystrzeli np. 400 przez pierwszą minutę, potem znowu będzie strzelał 600 strzałów na minutę, więc tych dwustu nie nadrobi i po dwóch minutach wystrzeli 1000 a nie 1200.

Albo nie widziałeś nigdy obsługi i strzelania z karabinu maszynowego albo coś jest nie tak z Twoim rozumowaniem.
Tak się składa, że ja akurat strzelałem nie raz z karabinu maszynowego i gwarantuję Ci, że jeśli karabin z szybkostrzelnośćią 600 strzałów na minutę zatnie się po 400 strzałach to z pewnością po 2 minutach nie wystrzelisz 1000 pocisków. Zainteresuj się tematem to zrozumiesz o co chodzi. Póki co przykład z karabinem jest do bani bo nie pasuje do tego zadania.

Mimo kiepskiego przykładu rozumiem o co chodzi ale się dziwię że tak się dzieje.

[tuxcnc]

gwarantuję Ci, że jeśli karabin z szybkostrzelnośćią 600 strzałów na minutę zatnie się po 400 strzałach to z pewnością po 2 minutach nie wystrzelisz 1000 pocisków.

Czepiasz się szczegułów bez znaczenia, ale niech Ci będzie że masz rację.
No to teraz, jako specjalista od karabinów maszynowych odpowiedz na następujące pytanie :
Karabin o szybkostrzelności 600 strzałów na minutę strzela dokładnie pięć minut, z tym że w tym czasie się zaciął, ile pocisków wystrzelił ? 3000 (5*600=3000), czy mniej ?

[drzasiek90]

Czepiasz się szczegułów bez znaczenia, ale niech Ci będzie że masz rację.

Dokładnie tak jak Ty to robisz w każdej mojej wypowiedzi.
Co do zadania, nie odpowiem Ci bo nie podałeś wszystkich danych. Od tego ile pocisków karabin wystrzeli zależy wiele czynników. Szybkostrzelność to pewien parametr który nie jest stały w czasie i warunkach. Poszukaj, poczytaj, może czegoś się dowiesz. Człowiek całe życie się uczy.

I nie jestem specjalistą od karabinów maszynowych ale pracuję od niemal 8 lat w zakładzie zbrojeniowym jako konstruktor. Zbudowałem lub uczestniczyłem w budowie kilku systemów, bywałem na poligonach, testowałem nasze rozwiązania i setki pocisków wystrzeliłem. Ja karabinów nie projektuję bo jestem elektronikiem, ale pracuję z ludźmi którzy karabiny projektują i badają. Zacięcie zataśmowanego karabinu to poważna i niebezpieczna sprawa i nijak ma się to do omawianego tutaj problemu. Wykorzystałem okazję, żeby się uczepić. Ale proponuje zawieszenie broni, chociaż obstawiam że Tobie to zwisa. Z mojej strony tyle, sory za OT.

[tuxcnc]

Zacięcie zataśmowanego karabinu to poważna i niebezpieczna sprawa i nijak ma się to do omawianego tutaj problemu.

Jak najbardziej ma się.
Zaczynam podejrzewać, że doskonale wiesz o czym mówię, tylko głupio Ci się przyznać.
Przykład z karabinem maszynowym jest idealnym przykładem, ale mogę podać inny :
Samochód o prędkości maksymalnej 100 km/h ma do przejechania 100 km, ale po drodze łapie gumę.
Chyba jest oczywiste, że po godzinie ma przejechane mniej niż 100 km ?
Po prostu żeby nadrobić stracony czas musiałby się poruszać szybciej niż może !
No to teraz z innej strony :
Samochód o prędkości maksymalnej 100 km/h ma do przejechania 100 km, ale każesz kierowcy jechać 110 km/h.
Po pierwszej godzinie brakuje Ci przejechanych 10 km, po drugiej 20 km itd.
Dzieje się tak, ponieważ NIE POJEDZIE SZYBCIEJ NIŻ MOŻE !
Czego tu można nie rozumieć ???