DRO DIY
-
- ELITA FORUM (min. 1000)
- Posty w temacie: 69
- Posty: 1724
- Rejestracja: 27 gru 2012, 02:40
- Lokalizacja: kujawsko-pomorskie
Przecinek postaw za czwartą cyfrą od lewej strony na stałe, żeby nie zmieniał swej pozycji nigdy. To dało by zakres -999,9999 9999,9999 mm. Gdy komuś był by potrzebny większy zakres ujemny, to niech wyświetla ten zakres bez minusa. Myślę, że każdy będzie w stanie ogarnąć fakt, że jest ponad metr na minusie chociażby po kierunku zliczania.
-
- Lider FORUM (min. 2000)
- Posty w temacie: 105
- Posty: 4690
- Rejestracja: 31 mar 2017, 19:47
- Lokalizacja: Warszawa
Ok, miałem wątpliwości bo niedawno czytałem o 4 metrowej tokarce znalezionej na złomie. I zastanawiałem się jak długie są standardowe modele.
Zwróć tylko uwagę co ja napisałem, podałem liczbę +/-2 000 000 000 jako możliwy zakres. To oznacza że chcąc mieć zakres 999mm to muszę postawić przecinek w ten sposób: 2000,000000. To oznacza że przynajmniej na plusie (bo minus zje jedną cyfrę) będzie zakres 2000mm a na minusie 999mm.
I o to mi właśnie chodziło, czy uprościć i wyświetlić tylko 3 cyfry po przecinku na wyświetlaczu. Czy może 4 cyfry po przecinku kosztem większego błędu liniowego?
Zwróć tylko uwagę co ja napisałem, podałem liczbę +/-2 000 000 000 jako możliwy zakres. To oznacza że chcąc mieć zakres 999mm to muszę postawić przecinek w ten sposób: 2000,000000. To oznacza że przynajmniej na plusie (bo minus zje jedną cyfrę) będzie zakres 2000mm a na minusie 999mm.
I o to mi właśnie chodziło, czy uprościć i wyświetlić tylko 3 cyfry po przecinku na wyświetlaczu. Czy może 4 cyfry po przecinku kosztem większego błędu liniowego?
-
- Specjalista poziom 3 (min. 600)
- Posty w temacie: 25
- Posty: 759
- Rejestracja: 13 sty 2010, 08:07
- Lokalizacja: Braniewo
Dodatkowe kilka złotych chciałeś powiedzieć. Wyprodukuj milion takich wyświetlaczy i okaże się, że koszty programowania to popierdułka. Kol. upanie podał inne rozwiązania wyświetlaczy m.in. oparty o Max7219, który w zasadzie jest dwoma 74HC595 w jednej obudowie, a do MAX'a jest biblioteka i to obsługująca do ośmiu (8) wyświetlaczy ośmiocyfrowych i to przez sprzętowe SPI.strikexp pisze:Tyle tylko że porządny sterownik takiego wyświetlacza kosztuje kilka złotych. A godzina pracy programisty więcej niż cały ten wyświetlacz z dobry sterownikiem.
Coś mieszasz. Dla enkodera na śrubie jest to skok śruby/ilość impulsów enkodera np. 5mm/200=0,025mm czyli maksymalny błąd niezależnie od długości pomiaru wyniesie prawie 0,05mm. Weźmy niewiele droższy enkoder 2000imp/obr czyli 5/2000=0,0025×2≈0,005 czyli ok pół przysłowiowej "setki".strikexp pisze:Dobra wróćmy do tematu DRO. Zrobiłem już jakieś tam liczenie z ustawianiem odległości na każdy impuls.
Problemy:
Dokładność określania odległości pomiędzy impulsami.
Wyszło że ustawia się ją poprzez określenie z dokładnością 0,0001 odległości pomiędzy kolejnymi impulsami. Jednak w przypadku długiego zakresu mierzenia, może to spowodować błąd liniowy np 0,00009 na impuls. Przy jednym obrocie enkodera będzie to już np 200x0,00009=0,018mm(!!!). Tego nie przewidziałem
Aby temu zaradzić trzeba obliczyć jaki odcinek przypada na jeden impuls i podać go z większą dokładnością.
W przypadku budowy pomiaru "liniowego" główną wartością od której zależy dokładność pomiaru jest średnica koła pasowego na enkoderze. Najmniejsze, które na szybko znalazłem ma średnicę Dp=9,55mm czyli obwód to 29,987mm i tu już mus stosować albo lepszy enkoder albo jakieś cwane przełożenia
.
Weź się rozpiszstrikexp pisze: Nie będę sie rozpisywał o sprawach technicznych. Ale łatwo i szybko mogę wyświetlić liczbę jedynie z zakresu +/- 2.000.000.000.


Przesadzasz... wyświetlanie dla samego wyświetlania? Wystarczyłoby do setki ale nie jestem kłótliwy więc krakowskim targiem niech będą trzy miejsca po przecinku. Jednej tysięcznej milimetra i tak nie dasz rady ukręcić na posuwie wzdłużnympioterek pisze: Przecinek postaw za czwartą cyfrą od lewej strony na stałe, żeby nie zmieniał swej pozycji nigdy. To dało by zakres -999,9999 9999,9999 mm. Gdy komuś był by potrzebny większy zakres ujemny, to niech wyświetla ten zakres bez minusa. Myślę, że każdy będzie w stanie ogarnąć fakt, że jest ponad metr na minusie chociażby po kierunku zliczania.

[ Dodano: 2017-04-24, 09:20 ]
strikexp masz tą tokarkę, o której pisałeś w innym poście?
Pozdrawiam
Krzysiek
Krzysiek
-
- ELITA FORUM (min. 1000)
- Posty w temacie: 48
- Posty: 1962
- Rejestracja: 15 sty 2011, 09:26
- Lokalizacja: Wyszków
Albo nie rozumiem o co Ci chodzi albo źle kombinujesz. Obsługując enkoder nie zliczasz żadnych metrów, milimetrów czy innych cali. Liczysz tylko impulsy. Cały czas impuls. No i wtedy nie masz żadnych błędów. Zamieniasz to na milimetry tylko w razie potrzeby np. wyświetlenia. Wtedy mnożysz liczbę impulsów przez odległość per jeden impuls i nie ma żadnych błędów kumulacyjnych.Wyszło że ustawia się ją poprzez określenie z dokładnością 0,0001 odległości pomiędzy kolejnymi impulsami. Jednak w przypadku długiego zakresu mierzenia, może to spowodować błąd liniowy np 0,00009 na impuls. Przy jednym obrocie enkodera będzie to już np 200x0,00009=0,018mm(!!!). Tego nie przewidziałem
Otóż nie nie takie same. Fakt, że mają często I2C, SPI i UART ale już GPIO to coś zupełnie innego niż w ARDUINO czy innych mikrokontrolerach. SBC (Single Board Computer) to już procesor aplikacyjny gdzie nie ważne jest sterowanie pinami a obsługa systemu operacyjnego. A to pociąga za sobą konsekwencje wolnego sterowania i wolnego odczytu GPIO. Nie da się za ich pomocą odczytywać stanu enkodera. Potrzebujesz do tego jakiegoś układu zewnętrznego np. mikrokontroler albo jakiś układ programowalny jak PLD czy FPGA z interfejsem do procesora, który jest dla niego łatwostrawny, np. SPI.A dlaczego mam nie obsłużyć? On posiada takie same interfejsy cyfrowe jak Arduino, jedynie z układami analogowymi mógłby być problem.
czilałt...
-
- Lider FORUM (min. 2000)
- Posty w temacie: 8
- Posty: 7739
- Rejestracja: 23 lis 2004, 22:41
- Lokalizacja: kraków
hej.
co do spraw elektroniczno / programowych się nie wypowiem - za cienki jestem
chodzi o sprawę podstawową.
do czego to ma być ?
jak do tokarki to dlaczego mówimy o jakiś dziesiątkach mikronów ?
już to widzę - luzy na śrubie , nierównomierny skok ( a są różne klasy wykonania śrub ) , itp.
generalnie - telepanie się całości.
pzd.
co do spraw elektroniczno / programowych się nie wypowiem - za cienki jestem

chodzi o sprawę podstawową.
do czego to ma być ?
jak do tokarki to dlaczego mówimy o jakiś dziesiątkach mikronów ?

już to widzę - luzy na śrubie , nierównomierny skok ( a są różne klasy wykonania śrub ) , itp.
generalnie - telepanie się całości.
pzd.
Mane Tekel Fares
-
- Lider FORUM (min. 2000)
- Posty w temacie: 22
- Posty: 2437
- Rejestracja: 29 lis 2015, 00:38
- Lokalizacja: Bielsko-Biała
Albo czegoś nie kumam, albo tutaj jest jałowa dyskusja trochę.
Komputera za 70zł nie zaprogramujesz, bo nie masz w nim przerwań, musiałbyś zejść do poziomu modyfikacji systemu operacyjnego, albo napisać własny, żeby je obsłużyć. Nie wspominając o paru innych kwestiach. Jesteś podobno programistą, więc myślałby kto, że takie rzeczy wiesz. No chyba, że to arduinowy programista
Przepraszam, ale jak czytam te wypowiedzi to mam wrażenie, że o programowaniu mikrokontrolerów nie masz za bardzo pojęcia (ja zresztą też wielkim szpecem nie jestem). Pomysł z programowaniem od nowa arduino za każdym razem to jest w ogóle kuriozalna sprawa i to nie dlatego, że pamięć flash ma ograniczoną ilość zapisów. Na arduino Ci braknie mocy obliczeniowej do wyświetlania kilku cyferek i zapamiętywania kilku wartości? Bez żartów proszę, to może superkomputery nie są, ale nie takie rzeczy potrafią robić.
Kasowanie luzów programowe nie jest takie idealne, jakby się mogło wydawać. Mówię tutaj z doświadczenia, bo próbowałem, ale o tym więcej się rozpiszę jak już skończę całą zabawę. Ogólnie, to nie da się dobrać takiej wartości, żeby zawsze była dobra i dawała maksymalną dokładność. Przy sterowaniu silnikiem krokowym wartości się zmieniają w dość znacznym zakresie (kilka setek na pewno) w zależności od prędkości, obecnego położenia itd.
I jeszcze pytanie, bo może mi coś umyka, ale po co dziesięciotysięczne na wyświetlaczu? Jakby takie domowe DRO na enkoderach miało dokładność 0.01 to już by było super. Ale moim zdaniem nie ma szans na taką dokładność, może o jakieś 0.05 by się można pokusić.
Komputera za 70zł nie zaprogramujesz, bo nie masz w nim przerwań, musiałbyś zejść do poziomu modyfikacji systemu operacyjnego, albo napisać własny, żeby je obsłużyć. Nie wspominając o paru innych kwestiach. Jesteś podobno programistą, więc myślałby kto, że takie rzeczy wiesz. No chyba, że to arduinowy programista

Kasowanie luzów programowe nie jest takie idealne, jakby się mogło wydawać. Mówię tutaj z doświadczenia, bo próbowałem, ale o tym więcej się rozpiszę jak już skończę całą zabawę. Ogólnie, to nie da się dobrać takiej wartości, żeby zawsze była dobra i dawała maksymalną dokładność. Przy sterowaniu silnikiem krokowym wartości się zmieniają w dość znacznym zakresie (kilka setek na pewno) w zależności od prędkości, obecnego położenia itd.
I jeszcze pytanie, bo może mi coś umyka, ale po co dziesięciotysięczne na wyświetlaczu? Jakby takie domowe DRO na enkoderach miało dokładność 0.01 to już by było super. Ale moim zdaniem nie ma szans na taką dokładność, może o jakieś 0.05 by się można pokusić.
-
- Lider FORUM (min. 2000)
- Posty w temacie: 105
- Posty: 4690
- Rejestracja: 31 mar 2017, 19:47
- Lokalizacja: Warszawa
@upanie
Nie rozumiesz że chodzi o dokładność obliczeń? Gdy pomnożysz te impulsy przez odległość to dostaniesz identyczny wynik. Trzeba robić tak dokładne obliczenia że ten błąd nazwijmy zaokrąglania, przestaje mieć znaczenie.
Masz jedynie rację że powinienem liczyć impulsy a nie od razu odległość. Operując na typie int zamiast long, zuzywam prawdopodobnie 1 cykl ALU zamiast 2 cykli. Chociaż i tak instrukcje warunkowe obsługi enkodera zeżrą znacznie więcej
W sumie to bez większej różnicy.
Odnośnie komputerów jednopłytkowych, o czym Ty gadasz. Jak prędkość Arduino itp? Przecież Arduino ma śmieszne 20Mhz i jest jednowątkowe. Ja zakupiłem jakiś czas temu NanoPi NEO za około 70zł (z kartą SD). To co prawda komputer jednopłytkowy ale ma 4 rdzeniowy procesor z taktowaniem 1,2Ghz. Tak 4 razy 1,2GHz jeżeli mnie pamięć nie myli!!! Do tego przypuszczam że możnaby wydzierżawić konkretny rdzeń na tylko jeden program. Owszem GPIO są wolniejsze, ale to jest uzasadnione tym że w razie potrzeby wiele portów GPIO może być obsłużonych przez tylko jeden rdzeń.
A jeśli już czepiamy się szybkości GPIO, to wyczytałem przed chwilą że w Raspberry Pi da sie uzyskać "square wave 22MHz". I warto tutaj zauważyć że po wykresie widać, że prawdopodobnie prąd jest za niski i pojemność ogranicza prędkość.
http://codeandlife.com/2012/07/03/bench ... pio-speed/
A to daje tak przynajmniej kilkukrotnie większą prędkość od Arduino UNO.
@pukury
Obliczenia w mikronach wynikają z przyczyn matematycznych. Wyjaśnie to prosto w ten sposób:
Jesli chcemy uzyskać dokładność 0,001mm, to na całej długości pracy DRO. Bład liniowy musi wynieść mniejszą wartość, a właściwie na tyle małą że nie jest w stanie zaburzyć tego wyniku. I tutaj są krzaczki typu:
odległość 1,001 + błąd 0,0001 = 1,001 na wyświetlaczu
odległość 1,001 - błąd 0,0001 = 1,000 na wyświetlaczu
odległość 1,009999999999 + błąd 0,000000000001 = 1,010 na wyświetlaczu
A niestety błąd liniowy wynosi ilość obrotów enkodera razy niedokładność obliczeń. Natomiast sam błąd wynika z zaokrąglenia realnej odległości na obrót np do konkretnego miejsca po przecinku
Przykład dla 50cm łoża tokarki, śruby o skoku 2mm i enkodera bez przekładni 200 imp/obr wyniesie maksymalnie:
Odległość na impuls 2mm/200 = 0,01 czyli liczba wymierna(ale mogła by być niewymierna przy przekładni np 3x)
Więc dla uproszczenia przyjmijmy że to śruba jest niedokładna i realnie wychodzi np 0,010001mm na impuls.
500mm/2mm*200 = 500 000 impulsów
500 000 * (niedokładność obliczeń)0,000001mm = 0,05mm
O taką wartość 0,05mm suport przesunie się dalej po przejechaniu 500mm na DRO. I pomimo że suport przejechał w praktyce 500.05mm to DRO wskaże tylko 500mm.
Przy przekładni lub znacznie dokładniejszym enkoderze, to już spowoduje konkretny błąd liniowy. Liczba niewymierna przypadająca na impuls spowoduje błąd liniowy już z samej matematyki.
Jest jeszcze kilka innych haczyków, ale nie mam dziś czasu na wykłady. Luzy na maszynie zrobią więcej szkody dla wyniku niż te haczyki elektroniczno-fizyczne.
A luzy nakrętki będą korygowane w ostatecznej wersji DRO. Ale to muszę chyba poczekać do niedzieli żeby to ogarnąć. Inne luzy to już niestety skutek używania rozwiazań które się rozkalibrowują (ścieranie elementów).
@Avalyah
Jak nie wiesz czym się różni mikrokontroler 8 bitowy od komputera 32 lub 64 bitowego. To lepiej nie przedstawiaj swoich teorii. Podobnie w odniesieniu do systemu operacyjnego jak Linux.
Naprawdę więcej wiary w komputery jednopłytkowe.
Nie rozumiesz że chodzi o dokładność obliczeń? Gdy pomnożysz te impulsy przez odległość to dostaniesz identyczny wynik. Trzeba robić tak dokładne obliczenia że ten błąd nazwijmy zaokrąglania, przestaje mieć znaczenie.
Masz jedynie rację że powinienem liczyć impulsy a nie od razu odległość. Operując na typie int zamiast long, zuzywam prawdopodobnie 1 cykl ALU zamiast 2 cykli. Chociaż i tak instrukcje warunkowe obsługi enkodera zeżrą znacznie więcej

Odnośnie komputerów jednopłytkowych, o czym Ty gadasz. Jak prędkość Arduino itp? Przecież Arduino ma śmieszne 20Mhz i jest jednowątkowe. Ja zakupiłem jakiś czas temu NanoPi NEO za około 70zł (z kartą SD). To co prawda komputer jednopłytkowy ale ma 4 rdzeniowy procesor z taktowaniem 1,2Ghz. Tak 4 razy 1,2GHz jeżeli mnie pamięć nie myli!!! Do tego przypuszczam że możnaby wydzierżawić konkretny rdzeń na tylko jeden program. Owszem GPIO są wolniejsze, ale to jest uzasadnione tym że w razie potrzeby wiele portów GPIO może być obsłużonych przez tylko jeden rdzeń.
A jeśli już czepiamy się szybkości GPIO, to wyczytałem przed chwilą że w Raspberry Pi da sie uzyskać "square wave 22MHz". I warto tutaj zauważyć że po wykresie widać, że prawdopodobnie prąd jest za niski i pojemność ogranicza prędkość.
http://codeandlife.com/2012/07/03/bench ... pio-speed/
A to daje tak przynajmniej kilkukrotnie większą prędkość od Arduino UNO.
@pukury
Obliczenia w mikronach wynikają z przyczyn matematycznych. Wyjaśnie to prosto w ten sposób:
Jesli chcemy uzyskać dokładność 0,001mm, to na całej długości pracy DRO. Bład liniowy musi wynieść mniejszą wartość, a właściwie na tyle małą że nie jest w stanie zaburzyć tego wyniku. I tutaj są krzaczki typu:
odległość 1,001 + błąd 0,0001 = 1,001 na wyświetlaczu
odległość 1,001 - błąd 0,0001 = 1,000 na wyświetlaczu
odległość 1,009999999999 + błąd 0,000000000001 = 1,010 na wyświetlaczu
A niestety błąd liniowy wynosi ilość obrotów enkodera razy niedokładność obliczeń. Natomiast sam błąd wynika z zaokrąglenia realnej odległości na obrót np do konkretnego miejsca po przecinku
Przykład dla 50cm łoża tokarki, śruby o skoku 2mm i enkodera bez przekładni 200 imp/obr wyniesie maksymalnie:
Odległość na impuls 2mm/200 = 0,01 czyli liczba wymierna(ale mogła by być niewymierna przy przekładni np 3x)
Więc dla uproszczenia przyjmijmy że to śruba jest niedokładna i realnie wychodzi np 0,010001mm na impuls.
500mm/2mm*200 = 500 000 impulsów
500 000 * (niedokładność obliczeń)0,000001mm = 0,05mm
O taką wartość 0,05mm suport przesunie się dalej po przejechaniu 500mm na DRO. I pomimo że suport przejechał w praktyce 500.05mm to DRO wskaże tylko 500mm.
Przy przekładni lub znacznie dokładniejszym enkoderze, to już spowoduje konkretny błąd liniowy. Liczba niewymierna przypadająca na impuls spowoduje błąd liniowy już z samej matematyki.
Jest jeszcze kilka innych haczyków, ale nie mam dziś czasu na wykłady. Luzy na maszynie zrobią więcej szkody dla wyniku niż te haczyki elektroniczno-fizyczne.
A luzy nakrętki będą korygowane w ostatecznej wersji DRO. Ale to muszę chyba poczekać do niedzieli żeby to ogarnąć. Inne luzy to już niestety skutek używania rozwiazań które się rozkalibrowują (ścieranie elementów).
@Avalyah
Jak nie wiesz czym się różni mikrokontroler 8 bitowy od komputera 32 lub 64 bitowego. To lepiej nie przedstawiaj swoich teorii. Podobnie w odniesieniu do systemu operacyjnego jak Linux.
Naprawdę więcej wiary w komputery jednopłytkowe.
-
- Lider FORUM (min. 2000)
- Posty w temacie: 22
- Posty: 2437
- Rejestracja: 29 lis 2015, 00:38
- Lokalizacja: Bielsko-Biała
Zrób i wtedy pogadamy. Nawet prosta matematyka najwyraźniej Ci umyka.
"500mm/2mm*200 = 500 000 impulsów"
Nie wiem, jakim cudem Ci wyszło tutaj 500 000 impulsów, skoro przejechałeś 500mm, na śrubie o skoku 2mm z enkoderem 200 impulsów na obrót.
Nic Ci po taktowaniu, jak nie jesteś w stanie timera sobie nawet ustawić na takim komputerku, w przeciwieństwie do mcu. Myślisz, że dlaczego w niektórych modułach dodatkowo jest właśnie jakaś atmega dodana do komputerka?
Spuść trochę z tonu Kolego, bo rozmowa z Tobą staje się coraz trudniejsza. Jeżeli chcesz otrzymać na tym forum pomoc, to nie powinieneś się zbytnio wywyższać, zwłaszcza w tematach, gdzie jest to po prostu śmieszne, bo nie wiesz, o czym mówisz, ale innych chcesz uczyć.
Walczysz z problemami, których nie ma, wykorzystując teoretyczne metody, które nie zadziałają, zamiast przysiąść na 3h i napisać prościutki programik na arduino, który obsłuży takie enkoderowe DRO. I nie zrobisz dokładności 0.01mm w ten sposób, bo się po prostu nie da. Jak mi nie wierzysz, to poświęć trochę czasu, sprawdź sam i przyznasz mi rację. Jak nawet uda się uzyskać wynik o błędzie kilku setek, to przejedziesz 50mm dalej, wykonasz gwałtowniejszy ruch i Twoja programowa wartość (zmieniana poprzez przeprogramowywanie procesora (!)) okaże się przestarzała.
Myślisz, że inżynierowie robiący prawdziwe maszyny CNC nie są w stanie tego zaprogramować porządnie i dlatego stosują zupełnie inne rozwiązania?
Moje rady masz z pozycji osoby, która w zasadzie zrobiła już takie DRO w praktyce. Idealne nie było i może da się to rozwiązać lepiej, ale pewnych rzeczy się nie przeskoczy i tyle. Luzy maszyny, niedokładność śruby, siły przy skrawaniu. Tego programowo nie skasujesz, za to liniał cyfrowy właśnie do tego celu jest zbudowany, że omija większość tych niedokładności.
"500mm/2mm*200 = 500 000 impulsów"
Nie wiem, jakim cudem Ci wyszło tutaj 500 000 impulsów, skoro przejechałeś 500mm, na śrubie o skoku 2mm z enkoderem 200 impulsów na obrót.
Nic Ci po taktowaniu, jak nie jesteś w stanie timera sobie nawet ustawić na takim komputerku, w przeciwieństwie do mcu. Myślisz, że dlaczego w niektórych modułach dodatkowo jest właśnie jakaś atmega dodana do komputerka?
Spuść trochę z tonu Kolego, bo rozmowa z Tobą staje się coraz trudniejsza. Jeżeli chcesz otrzymać na tym forum pomoc, to nie powinieneś się zbytnio wywyższać, zwłaszcza w tematach, gdzie jest to po prostu śmieszne, bo nie wiesz, o czym mówisz, ale innych chcesz uczyć.
Walczysz z problemami, których nie ma, wykorzystując teoretyczne metody, które nie zadziałają, zamiast przysiąść na 3h i napisać prościutki programik na arduino, który obsłuży takie enkoderowe DRO. I nie zrobisz dokładności 0.01mm w ten sposób, bo się po prostu nie da. Jak mi nie wierzysz, to poświęć trochę czasu, sprawdź sam i przyznasz mi rację. Jak nawet uda się uzyskać wynik o błędzie kilku setek, to przejedziesz 50mm dalej, wykonasz gwałtowniejszy ruch i Twoja programowa wartość (zmieniana poprzez przeprogramowywanie procesora (!)) okaże się przestarzała.
Myślisz, że inżynierowie robiący prawdziwe maszyny CNC nie są w stanie tego zaprogramować porządnie i dlatego stosują zupełnie inne rozwiązania?
Moje rady masz z pozycji osoby, która w zasadzie zrobiła już takie DRO w praktyce. Idealne nie było i może da się to rozwiązać lepiej, ale pewnych rzeczy się nie przeskoczy i tyle. Luzy maszyny, niedokładność śruby, siły przy skrawaniu. Tego programowo nie skasujesz, za to liniał cyfrowy właśnie do tego celu jest zbudowany, że omija większość tych niedokładności.