pitsa pisze: ↑

15 sie 2020, 23:06

tylko mały laptop odkurzony do testów z linuxcnc.

Dmuchnij sprężonym powietrzem w kratki laptopa. Ja od tego zaczynam jak kupie stary laptop. Czasami się można zdziwić jaka chmura kurzu wypadnie.

Jeśli kompilowales np. z mojego skryptu instalując linimeric-LPT to wykorzystywałes wszystkie rdzenie stąd dość duże obciążenie. Stare komputery czesto też są dość mocno zakurzone a element termoprzewodzacy (pasta czy mata) pomiędzy procesorem a radiatorem po latach również traci swoje właściwości. Dodatkowo komputery PC są raczej "mało przemysłowe". W komputerze przemysłowym badamy np. przez 24h z pełnym obciążeniem wszystkich rdzeni w temperaturze otoczenia 80 stopni.

Zastanawiam się co się stanie z silnikiem krokowym który dostaje kroki co 10us a tu nagle przez 100 albo 200us nic. Bezwładność rotora + wszystkiego co napędza będzie chciała go obrócić, sterownik będzie chciał go "zatrzymać" (no bo jest przerwa). Możliwe, że nic się nie stanie. Bardziej szkodliwa chyba jednak dla silnika krokowego (w sensie zagrożenia zgubienia kroku) jest nagła zmiana w drugą stronę, czyli nagłe zwiększenie częstotliwości kroków.

tuxcnc pisze: ↑

20 lip 2020, 20:31

Ja natomiast szukam prostego sposobu sprawdzenia w praktyce, co dany komputer może, a co jego możliwości przekracza.

I tu by się chyba przydał podgląd live folowing error. Nie trzeba by sprawdzać kiedy wywali błąd napędu ale widać by było tendencję do powstawania coraz większego błędu.

tuxcnc pisze: ↑

20 lip 2020, 19:53

Ad 1. To jest najzwyklejsze serwo, tylko zamiast impulsów z fizycznego enkodera są liczone wygenerowane faktycznie impulsy step.

Czyli jest ok
W taki sposób napisałeś ten artykuł, albo ja w taki sposób go zinterpretowałem że wywróciło mi do góry nogami moje pojęcie jak to działa. Po przykładzie z karabinem myślałem, że jeśli krok się nie wykona to przepada i słuch o nim ginie, co byłoby niedopuszczalne. Ale po burzliwym wyjaśnieniu okazuje się, że jednak jest trochę podobnie jak do tej pory byłem przekonany. Z tym, że ja myślałem, że po każdym opóźnieniu następuje kumulacja generowania tego co miało się wygenerować a nie zdążyło. Natomiast wychodzi na to, że jest jeszcze lepiej to rozwiązane.
Latency test ma znaczenie i nie tyle wartość jitteru co również częstotliwość występowania opóźnienia w stosunku do wydajności komputera. Pasuje przyglądać się latency-plot a nie latency-test chociaż samo przyglądanie się niewiele pomorze.
Jeśli mamy komputer który raz na kilkadziesiąt sekund wyrzuci nam opóźnienie 100 us a wydajność komputera pozwoli aby to nadrobić nic się strasznego nie dzieje.

Nie, ok jest, mój błąd.
Ale ciekawe to jest, nie przypuszczałem, że to tak działa.

Dodane 4 minuty 44 sekundy:

tuxcnc pisze: ↑

20 lip 2020, 19:27

Natomiast faktycznie, jeśli każesz jechać wolniej, to w następnym cyklu servo_period prędkość zostanie podbita aby nadgonić błąd.

Czyli jednak jest jakiś mechanizm "nadganiania" który jeśli czas procesora pozwoli to "nadgania" tak aby ferror zmniejszyć?
Szukałem czy gdzieś można na żywo podglądnąć wartość tego błędu ale nie znalazłem. Jest coś takiego do podglądu?

Dodane 10 minuty 9 sekundy:

tuxcnc pisze: ↑

20 lip 2020, 19:27

Przy wolnych przebiegach wygląda to ładnie, przy szybkich już nie, no bo jak przejść z 50 khz na 49,9 kHz ?
Można tylko wyciąć co któryś impuls.

Nie o to mi chodziło, wiem jak działa generowanie impulsów.
Przebieg wyglądał dziwnie bo miałem wyłączony double step co przy tej konfiguracji powodowało dziwne działanie.
Już pisałem, mój błąd, wszystko ok.

tuxcnc pisze: ↑

20 lip 2020, 18:51

Dzieje się tak, ponieważ NIE POJEDZIE SZYBCIEJ NIŻ MOŻE !
Czego tu można nie rozumieć ???

Ale kto powiedział, że komputer już szybciej nie może?
Poprawny przykład z samochodem.

Kierowca ma zawieźć towar Z miejscowości A do miejscowości B oddalonych od siebie o 50km. Nie może być ani za wcześnie ani za późno, Wyjeżdża o godzinie 1:00 a towar ma dostarczyć na godzine 2:00. Na tacho kończy mu się czas, może jechać jeszcze tylko godzinę. Obliczył, że musi jechać z prędkoscią 50km/h aby być punktualnie, Po drodze łapie gumę, traci 5 minut.
Jakie powinno być zachowanie kierowcy po naprawieniu gumy? Dalej ma jechać 50km/h i nie dojechać na miejsce zanim mu się skończy czas czy szybko nadrobić stratę i dalej jechać 50km/h?

Jeśli chodzi o linuxCNC chyba faktycznie jest tak jak mówisz, że jeśli nie wykona się zadanie bo jitter skoczy na wartość wyższą niż base-period to zadanie to przepada. Ale skoro system wie o tym że przepadło (bo liczy ferror) to czemu tego zadania nie wykona jeszcze raz? Wydaje mi się, że mniej szkodliwe byłoby chwilowe spowolnienie prędkosci niż zgubienie kroku.

Robię test, ustawiłem wszystko tak jak Ty i jest jakaś muka. czasem się wywala błąd pozycji, czasem nie. A ciekawie wygląda przebieg na pinie LPT. Sprawdzałeś?
Dam znać jak wyłapię o co chodzi.

tuxcnc pisze: ↑

20 lip 2020, 18:07

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 pisze: ↑

20 lip 2020, 13:15

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 pisze: ↑

20 lip 2020, 13:15

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.

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?