DRO DIY

Panowie mam złą wiadomość, okiełznałem ten wyświetlacz 8 segmentowy. I stwierdzam że to chiński badziew.
Chodzi o to że nie da sie jednocześnie wyświetlić więcej niż jednej cyfry. Trzeba wyświetlać każdą cyfrę po co najmniej o 0,05 sekundy. Zastanawiam się czy jest sens używać takiego wyświetlacza. Mocno obciąża Arduino i może się pomylić w liczeniu przy dużych prędkościach.
Jak nikt nie kupił takiego wyświetlacza, to może warto wybrać coś lepszego.
Piszcie co ma dalej robić.

Yogi_ pisze:
OK. W skrócie - każde połączenie gwintowane ma pewien luz. Śruba napędowa poruszy nakrętkę dopiero po obrocie o pewien kąt, od wartości bliskich zeru do nawet kilkuset stopni. liniał pomiarowy (o którym wspominał kol, upanie)umocowany do nakrętki omija luz śruby w nakrętce, DRO podłączone do liniału pokaże zmianę wartości niezależnie od kąta obrotu śruby bez ruchu nakrętki. DRO z enkoderem obrotowym zmieni wskazania jeszcze bez ruchu nakrętki.

To mogę załatwić, dodając parametr (do wpisania) który określa ile początkowych impulsów ma być pominięte przy zmianie kierunku. Oczywiście pociąga to pewne konsekwencje.
Po pierwsze enkoder musi dawać kilka impulsów na samym luzie, a więc musi być dokładny lub z dużą przekładnią bezluzową.
Po drugie na tym luzie można sobie latać w te i spowrotem. Więc trzeba dodatkowo ustalać pozycję gwintu w luzie nakrętki, ale to problem jedynie programistyczny. Może jednak mocno ograniczać szybkość DRO (chociaż zawsze można dać szybszy mikrokontroler).

Yogi_ pisze: Plik konfiguracyjny programu DRO. W nim wartości takie jak skok śruby, ilość impulsów na obrót enkodera, ilość impulsów na luz śruby - dla każdej osi osobno.
Oraz tryb pomiaru błędu na DRO tzn tryb wyświetlania liczby impulsów enkodera.
Wyobrażam to sobie tak:
1, DRO w tryb pomiaru błędu.
2. kilka obrotów śruby w np.lewo, wyzerowanie wyświetlacza.
3. Jakiś czujnik ruchu do elementu, którego przesunięcie ma być mierzone.
4. Obrót śruby w prawo do momentu wskazania przesunięcia przez czujnik ruchu.
5. Odczytanie i zapisanie do pliku konfiguracyjnego ilości impulsów - błędu luzu.
Gdzieś w programie coś w ten deseń:

Kod: Zaznacz cały

Jeśli oś zmienia kierunek to pomiń [i]błąd[/i] impulsów i dopiero zacznij przeliczać przesunięcie.

Cały czas mam wrażenie, że namotałem, ale jak coś to pytaj

Mniej więcej zrozumiałem, ale to już dużo bardziej skomplikowane rozwiązanie. Przypuszczam że czujnik elementu będzie kosztował majątek. Chyba że masz na myśli liniał(suwmiarkę) z wyjściem do transmisji danych.
Bardziej bym to widział na zasadzie że w pliku programu ustawia się różne parametry. A potem na nowo programuje Arduino z nowymi luzami. Arduino/mikrokontroler da sie programować przynajmniej 10.000 razy więc od tej strony to nie problem.

strikexp pisze: Panowie mam złą wiadomość, okiełznałem ten wyświetlacz 8 segmentowy. I stwierdzam że to chiński badziew.
Chodzi o to że nie da sie jednocześnie wyświetlić więcej niż jednej cyfry. Trzeba wyświetlać każdą cyfrę po co najmniej o 0,05 sekundy. Zastanawiam się czy jest sens używać takiego wyświetlacza. Mocno obciąża Arduino i może się pomylić w liczeniu przy dużych prędkościach.
Jak nikt nie kupił takiego wyświetlacza, to może warto wybrać coś lepszego

Patrz:

Jakoś działa, a w opisie:

... and using a 250 Hz update frequency, display driver uses 2% CPU because hardware SPI, bitch!

może wepchnij obsługę wyświetlacza w przerwanie?

Po pierwsze enkoder musi dawać kilka impulsów na samym luzie, a więc musi być dokładny lub z dużą przekładnią bezluzową.

Nie jest tak strasznie Śruba o skoku 5mm i enkoder 200 impulsów. Na jeden impuls przypada 0,025mm czyli max tyle zginie z pomiaru a luz może przekraczać połowę obrotu czyli ponad 100 impulsów. DRO odmierzy powiedzmy 2,5mm zanim narzędzie się zacznie przesuwać i trzeba by mieć w pamięci ten błąd. A pamięć zawodną jest

Po drugie na tym luzie można sobie latać w te i spowrotem. Więc trzeba dodatkowo ustalać pozycję gwintu w luzie nakrętki, ale to problem jedynie programistyczny. Może jednak mocno ograniczać szybkość DRO (chociaż zawsze można dać szybszy mikrokontroler).

To akurat można załatwić podkładką filcową na przykład.

Przypuszczam że czujnik elementu będzie kosztował majątek. Chyba że masz na myśli liniał(suwmiarkę)

Czujnik elementu może być poskładany z czegokolwiek, choć podejrzewam, że znakomita większość posiadaczy frezarek i tokarek takowy posiada. Jest to czujnik zegarowy na przykład taki:

albo bateria, żaróweczka i jakieś styki, albo wręcz jakaś dźwignia 1:10 lub więcej, to jest potrzebne jednorazowo aby zobaczyć ile impulsów potrzeba na jałowy obrót śruby. Wyżej wspomniana śruba 5mm przy 40° luzu gubi 22,2 impulsu.

Chodzi o to że nie da sie jednocześnie wyświetlić więcej niż jednej cyfry. Trzeba wyświetlać każdą cyfrę po co najmniej o 0,05 sekundy.

strikexp A możesz mi powiedzieć czego innego się spodziewałeś? Przecież wystarczy zerknąć na schemat. Sam napisałeś, że jesteś elektronikiem więc powinieneś coś wiedzieć o sterowaniu multipleksowym. Inaczej nikt rozsądny tego nie robi ze względu na liczbę połączeń układu z wyświetlaczami i prądem jaki by pobierały gdyby wszystkie wyświetlacze pracowały jednocześnie. Specjalizowane scalaki robią dokładnie tak samo tylko, że z punktu widzenia interfejsu do procka jest to niewidoczne bo same to ogarniają.
Jeśli chcecie zaprojektować płytkę to polecam kupić same wyświetlacze i np. taki sterownik. Może sterować sześcioma wyświetlaczami 7-mio segmentowymi z kropkami, 8-mioma diodami LED i obsługiwać klawiaturę do 8x2 kalwiszy (matryca). Pozwala na regulację jasności świecenia.
Jeśli nie chcecie robić swojej płytki to kupcie wyświetlacz ze sterownikiem np. takie coś albo takie
Nie nazywaj tego wyświetlacza chińskim badziewiem bo nie zasługuje na takie określenie.
Ciekawie się obserwuje Wasze zmagania.
Yogi_ luz można olać jak się odpowiednio rozwiąże połączenie enkodera z mechaniką.
W linku, od którego wszystko się zaczęło, koleś połączył enkoder z pinolą za pomocą paska zębatego. Tak samo można połączyć stolik frezarki z enkoderem. Można w zasadzie enkoder obrotowy wsadzić w jakiś profil alu, tam wsadzić dwa kółka zębate i pasek i z tego zrobić taki sobie enkoder liniowy.

Odnośnie wyświetlacza to wrócę do tematu jutro. Skoro miałby być użyty jedynie enkoder 200 imp/obrót to powinno dać radę.
Boję się ponieważ kiedyś symulowałem szybkie obroty enkodera generatorem. I przy kilkudziesięciu tysiącach impupsów na sekundę, Arduino nie nadążało robić prostych obliczeń. A tutaj trzeba jeszcze przeliczać po każdej zmianie pozycję na cyfry wyświetlacza, no i te luzy maszyny.
Ale mam też pomysł, skoro ludzkie oko ma bardzo ograniczoną spostrzegawczość. To na wspomnianym przerwaniu będę obliczał 2-4 razy na sekundę wynik i trzymał go w tzw cache. W ten sposób bardzo ograniczę obliczenia, wystarczyło przemyśleć problem na spokojnie.

Yogi_ pisze: To akurat można załatwić podkładką filcową na przykład.

Tu się chyba nie zrozumieliśmy, chodziło mi o to że DRO musi prowadzić też odrębne obliczenia na luzach. Ponieważ nie jest powiedziane że jak ruszysz to dojedziesz do końca luzu, równie dobrze możesz zawrócić kilkukrotnie na tym luzie.


Nie zrozumielismy się też z tym czujnikiem. Myślałem że piszesz o jakimś automatycznym odczytywaniu luzów i wysyłaniu ich do DRO. Takie pomiary czujnikiem zegarowym są jak najbardziej do zaakaceptowania. Tylko trzeba będzie zaprogramować DRO od nowa z odpowiednimi parametrami, bo robienie menu i przycisków zajmie trochę czasu A przy programowaniu to wystarczy wpisać z klawiatury w odpowiednie miejsca kodu źródłowego.

Yogi_ pisze: z jakiego jest to urządzenia?

Jeżeli chcesz całego PDF-a to wyszukaj pliku: L01H.2E.pdf , oraz: 17ht3154_01z_dfu_pol.pdf

Ponad tydzień temu ( 2017-04-14, 07:24 ) podałem link do fachowego opisu.
http://www.elektroda.pl/rtvforum/topic117391.html
( 2017-04-11, 05:13 ) pytałem o ten wyświetlacz, jednak jedyna odpowiedź jaka wtedy padła nie wyjaśniła niczego

Yogi_ pisze: Koncepcje co tym wyświetlaczem zegara (clock display z pdfa) zrobić:
1. Odłożyć na półkę jako dawcę organów.
2. Wyrzucić niepotrzebne części, dołożyć układ i kawałek płytki i mieć wyświetlacz oparty o SAA1064.
3. Przeprogramować PIC-a zwracając uwagę aby I²C było zgodne z arduinowym.

Jeżeli nie da się tego zastosować jako takiego zwyczajnego wyświetlacza to może można by mu wpisać czas i ustawić żeby pokazywał aktualną godzinę?

strikexp pisze:Odnośnie wyświetlacza to wrócę do tematu jutro.

Nie ucieszę Cię, ten wyświetlacz ma interfejs SPI (Arduino UNO ma sprzętowy SPI jeden) więc powinieneś postawić w szeregu 3 takie wyświetlacze i dopiero na nie wysyłać przetworzone dane.

Skoro miałby być użyty jedynie enkoder 200 imp/obrót to powinno dać radę.

To był przykład enkodera o "niskiej" rozdzielczości, niewiele droższe są enkodery od 2000 do 5000 imp/obr więc weź takie pod uwagę.

Boję się ponieważ kiedyś symulowałem szybkie obroty enkodera generatorem.

A używałeś jakiegokolwiek enkodera? w sensie jak wykrywać kierunek obrotów? Tak mi się wydaje, że do liczenia i sprawdzania kierunku będą potrzebne przerwania związane ze zmianą stanu pinów, których UNO posiada 2 (w sensie tych od przerwań).

Tu się chyba nie zrozumieliśmy, chodziło mi o to że DRO musi prowadzić też odrębne obliczenia na luzach.

Fakt, ale w tym momencie prowadzi obliczenia tylko na luzach.

Tylko trzeba będzie zaprogramować DRO od nowa z odpowiednimi parametrami, bo robienie menu i przycisków zajmie trochę czasu

Menu jak menu, ale przecież przynajmniej 3 przyciski do zerowania osi, a może jeszcze klawiatura do wprowadzania własnych wartości?

pioterek pisze:Jeżeli nie da się tego zastosować jako takiego zwyczajnego wyświetlacza to może można by mu wpisać czas i ustawić żeby pokazywał aktualną godzinę?

Też się (prosto) nie da. Potrzebujesz modułu zegara, który będzie wysyłał (po I²C) co chwila aktualny czas i co sekunda mrugał dwukropkiem. Niestety to jest tylko wyświetlacz .

Yogi_ pisze:

strikexp pisze:Odnośnie wyświetlacza to wrócę do tematu jutro.

Nie ucieszę Cię, ten wyświetlacz ma interfejs SPI (Arduino UNO ma sprzętowy SPI jeden) więc powinieneś postawić w szeregu 3 takie wyświetlacze i dopiero na nie wysyłać przetworzone dane.

Nie bardzo rozumiem w czym jest problem. Ja wczoraj podłączyłem ten wyświetlacz do pinów 2, 3, 4 i działa prawidłowo. Problem w tym że nie ma mechanizmu trzymającego wynik. Podliczyłem dziś objętość obliczeń i nie jest źle wbrew temu co mi się wydawało. Ale na korekcję luzów to może brakować mocy obliczeniowej.
Przysiadę do tego zaraz i zrobię. Tylko kto ma taki wyświetlacz i enkoder, bo pasowałoby potestować przy jakiej prędkości obrotowej powstaną błędy pomiaru.

@upanie
Podtrzymuję że ten wyświetlacz to chiński badziew. Powinien być jakiś układ zapamiętujący zawartość wyświetlacza. I z tego co się orientuję to są też takie wyświetlacze do Arduino, tylko ja trafiłem wersję bieda.

strikexp pisze:Nie bardzo rozumiem w czym jest problem. Ja wczoraj podłączyłem ten wyświetlacz do pinów 2, 3, 4 i działa prawidłowo. Problem w tym że nie ma mechanizmu trzymającego wynik.

Pisałem wcześniej:

Yogi_ pisze:
Jakoś działa, a w opisie:
Cytat:
... and using a 250 Hz update frequency, display driver uses 2% CPU because hardware SPI, bitch!

Trzy rzeczy z zacytowanego tekstu:
1. hardware SPI
2. 250 Hz update frequency

http://akademia.nettigo.pl/arduino_uno/ pisze:SPI
SPI to szybka synchroniczna magistrala szeregowa. W Arduino UNO jej zegar może pracować maksymalnie z prędkością 8 MHz. Wyprowadzenia magistrali mają oznaczenia "SCK" (sygnał zegara), "MOSI" (wyjście danych), "MISO" (wejście danych) i znajdują się w 6-pinowym wtyku ICSP z prawej strony płytki.

3. display driver uses 2% CPU

Podliczyłem dziś objętość obliczeń i nie jest źle wbrew temu co mi się wydawało. Ale na korekcję luzów to może brakować mocy obliczeniowej.

Także powinno ogarnąć.

Podtrzymuję że ten wyświetlacz to chiński badziew. Powinien być jakiś układ zapamiętujący zawartość wyświetlacza. I z tego co się orientuję to są też takie wyświetlacze do Arduino, tylko ja trafiłem wersję bieda.

To tak jakby mieć do malucha (Fiat 126p) pretensje, że nie ma ABS. Nie ma bo nie miał mieć. W danych technicznych samochodu nie ma słowa o tym, że ma ABS to nie można mieć do tego pretensji.
Wyświetlacz ten zbudowany jest na prostym rejestrze przesuwnym więc nie można mieć co do niego żadnych oczekiwań poza uproszczeniem interfejsu elektrycznego.

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.
Dlatego uważam że to badziew

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ą. I tutaj pasowałoby konkretnie określić ile ma być cyfr przed i za przecinkiem.
Nie będę sie rozpisywał o sprawach technicznych. Ale łatwo i szybko mogę wyświetlić liczbę jedynie z zakresu +/- 2.000.000.000. Gdzie postawić przecinek to już sami decydujcie. Im więcej przed przecinkiem, tym większy błąd liniowy wystąpi.

Jak się wkur**** to napiszę wam program na minikomputer jednopłytkowy za 70zł. Ale to temat w który dopiero wchodzę i wolałbym nie obiecywać