[dcristi]

Initial am vrut sa postez aici dupa ce termin proiectul. Vad ca treaba se complica asa ca o sa scriu pe masura ce mai termin cate o etapa.

Putina istorie: De cand am schimbat telescopul (12" cu 16") am fost incantat de sistemul goto. Tot sistemul mecanic e schimbat fata de cel de 12". Gasea obiectele perfect si le tinea in ocular chiar si 30 minute. Insa atunci cand folosesc puteri mari, caci asa vanezi planetele, am vazut ca imaginea are un tremur enervant cam de 10-20 arcsec/sec. Am dat vina pe seeing. La Jupiter nu m-a deranjat caci la 100fps mai scapi de problema. Dar, chiar si asa, parca ma asteptam la mai mult.
La Saturn, unde mergi cu fps mai mic, nu mi-a placut niciodata rezultatul final. Tot pe seeing am dat vina caci sezonul asta, si urmatoarele, Saturn o sa fie jos de tot.
Am zis ca incerc si M57 ca-i sus de tot si turbulenta ar trebui sa fie mica. Cu cel de 12" am avut un rezultat bunicel la expuneri de 1 sec. Foloseam cam 2 cadre din 3. Cu asta de 16" am folosit cam 1 cadru din 5 si nici ala parca nu era bun.
De atunci am inceput sa am banuieli ca ceva nu lucreaza bine. Am "ascultat" zgomotele facute de montura si nu parea ca miscarea ar fi uniforma pe axe.
Bun zic - hai sa ungem hardughia ca nu aluneca bine. O fac bucati, pun vaselina cat incape, si ies la produs. Daca incercam sa imping cu mana de tub, pe orice axa, nu parea sa aiba blocaje pe undeva. Parca ar fi urmarit ceva mai bine dar nici pe departe asa cum ma asteptam. Ca sa-l pot mentine in cadru pe Saturn trebuia sa filmez la 800x640 cand planeta ocupa cam 1/3.

Pun si un film demo cu un crop din film. Cam asa juca imaginea.

[dcristi]

Trec la pasul urmator si iau electronica la verificat.
Nu stiu de ce in capul meu eram convins modelul asta de montura are steppere. Din cauza aia am cazut si ca musca-n lapte pe threadul cu proiectul de montura a lui StarChild Culmea e ca o desfacusem de cateva ori dar nu am bagat de seama ca motoarele se alimenteaza prin doar doua fire - restul mergeau la encoder.
Pun montura pe masa de lucru, dau goto, si masor cu osciloscopul tensiunea pe motor. Semnal perfect dreptunghiular si uniform de aprox 20kHz si cu grad de umplere de 30%. Cam cum scrie la carte.
Trec pe tracking. Hopa! Gradul de umplere variaza atat de mult incat aproape ca osciloscopul nu se putea sincroniza. Pun mana pe roata melcata, deci dupa reductie, si simteam cum variaza turatia exact ca semnalul de pe osciloscop. Cam in ritmul ala misca si planeta in cadru cand filmam.
Ce concluzie trag de aici: la goto nu intereseaza precizia si deci nu intra in calcul encoderul. Controllerul face o aproximare cat ar trebui sa mearga si verifica la final cam pe unde a ajuns urmand sa mai faca niste pasi mici pana nimereste tinta. Apoi, cand trece pe tracking, porneste encoderul de pe motor urmand sa ajusteze viteza/tensiunea mai des.
Bun. Inseamna, zic eu, ca vaselina nu-i suficienta si montura tot are frecari neuniforme. Scot motorul, ii scot si reductia, si refac masuratoarea cu el functionand in gol. Daca il infranai putin cu mana se vedea clar cum se creste gradul de umplere (PWM), ca sa contreze frecarea, dar avea aceeasi variatie enervanta.
E groasa! Fara tensiune motorul se invarte foarte usor cu mana. Nu se simte vreo infranare. Daca il alimentez direct, cu tensiune constanta, atunci merge uns.
Ce sa fac? Sa pun un motor mai puternic? Nu, ca daca asta original face figuri cand merge in gol atunci cu ce m-ar ajuta ala puternic?
Am studiat cum comunica HC (hand controller synscan) cu MC (motor controller). Pe HC nu-l intereseaza felul in care MC isi gestioneaza motoarele. Ii trimite doar coordonate si/sau viteze dorite. Apoi din cand in cand, dupa caz, mai intreaba pe unde se afla axele sau status motor.
Deci problema mea e din MC si nu o pot depana.

Si cam pana aici a fost cu distractia ca e usor sa gasesti bube la altii dar cand te apuci de lucru apar durerile de cap.
O sa scriu maine despre calcule si despre arduino - de unde pleci si unde ajungi...

[nobody]

Au folosit motoare de CC cu perii, cu 5 poli daca e ca la mine.
Aceste motoare nu se rotesc uniform la turatii mici.
Au niste salturi cand comuta periile de pe o infasurare pe alta.
Encoderele sunt folosite tot timpul, altfel ar pierde alinierea.

Daca te uiti la motor (roata de la encoder), nu ti se misca in trepte ?
Adica se roteste un pic, mai sta, mai se roteste cativa pasi de encoder ...

Apropo, vezi ca sunt update-uri de firmware si pentru MC.
Stiu ca au mai facut tuning exact la felul cum se misca motoarele.
Poate te ajuta.

O solutie ar fi inlocuirea motoarelor cu ceva mai de calitate si cu mai multi poli (contacte). Dar alea costa ...

[catalin dumitru]

[dcristi]

Primul gand a fost sa caut pe net sa gasesc un proiect gata facut pentru inlocuire motor & MC. Din pacate majoritatea sunt doar pentru monturile EQ. Bine macar ca cei de la SW au facut public protocolul de comunicatie intre HC si MC.
Ca sa vad care e corespondenta intre viteza de tracking ceruta de HC si cea raportata de encoder am trecut toata comunicatia printr-un convertor serial si am comandat montura din calculator.
Pentru modul track, sa zicem pe ALT, HC face asa:
- cere status motor cu :f2. MC raspunde cu starea motorului (goto/track, rapid/lent, ultima directie de mers)
- cere pozitia encoderului cu :j2; MC raspunde cu =FDCC85, BCD pe 3 bytes, LDB e primul. Asta inseamna 8768765 in zecimal.
- seteaza motorul in mod track prin comanda de tipul :G210, unde 2 motorul tinta, 1 e modul track si 0 e directia
- seteaza viteza motorului. De ex :I28E0100, unde 2 e motorul tinta iar 8E0100 e viteza scrisa in BCD pe 3 bytes, LSB e primul. Valoarea asta inseamna 398 in zecimal.
- comanda start motor cu :J2
si tot asa la fiecare 10 secunde.

Viteza reala variaza invers cu valoarea trimisa prin comanda :I. Valori mici inseamna viteze mari.
Am facut un script cate trimite, pe rand, viteze track si am citit distanta parcursa intre secunda 1 si 11. Prima secunda am lasat-o deoparte ca sa accelereze linistit. Nu am trimis chiar toate vitezele caci ar fi durat prea mult (11 sec * 16 mil variante).

Au inceput sa curga valorile si le-am pus in tabel. Pun aici cateva doar pentru demo:

Comanda / Zecimal / pasi test_1 / pasi_test_2
:I2020000 2 101000 101604
:I2030000 3 67688 67186
:I2040000 4 51205 50786
:I2050000 5 39698 40572
.....
:I2BA0000 186 1293 1201
:I2BB0000 187 1076 1110
:I2BC0000 188 1324 1032

Pai ce treaba e asta? Sa apara diferente asa de mari intre teste diferite in toata plaja de viteze?
De unde ar putea sa apara erorile?
Am facut o evaluare ochiometrica a pasului PWM. Daca imi aduc aminte bine erau cam 57 de valori intre minim si maxim.
Cam putin. E clar. Trebuie sa fac MC-ul meu, care sa mearga brici, si sa dea 65535 valori pentru PWM. Asa as controla mult mai fin turatia. Il fac cu Arduino, ca tot am unul in sertar, si ma prind eu in timp cum merge treaba.

[dcristi]

[dcristi]

Ma apuc si citesc pe net despre PWM pe Arduino Uno, cat de precis poate fi la 20kHz.
Am inteles ca nu poti avea rezolutie maxima la toate frecventele caci esti limitat de frecventa procesorului si a ceasurilor interne.
Cea mai generoasa librarie pentru Arduino ar avea o rezolutie de 13 biti la 1Khz si 6 biti la 100kHz. Parca am masurat la vremea aia cat iesea la 20kHz si era pe la 8 biti. Pai daca pierd 1 bit in zona de PWM mare (n-am nevoie de viteza asa mare pentru tracking) mai raman cu 7. Asta inseamna 128 de valori.
Cifra asta seamana cu ce am vazut ca face MC original. Daca mai pui si ca trebuie sa numeri encoderul, faci calcule de ajustari PWM, si mai comunici si cu HC, mai poate procesorul ala sa respire si sa faca treaba corect?
In cazul asta am am decis ca nu pot sa rezolv problema cu Arduino & DC si am trecut pe stepper.

[dcristi]

Am, pentru teste, un NemaXX pe care-l cumparasem pentru motorizare focusser. Am pus pe o placa un L298N, cu tot ce-i trebuie, si m-am apucat sa programez arduino sa accepte comenzi din HC. Nu sunt eu programator dar nici nu ma sperie un float sau o clasa.
Ca librarie folosesc AccelStepper. E buna pentru ca permite viteze foarte mici si poate gestiona mai multe motoare in acelasi timp.
Initial am implementat comenzile de baza, care sa faca HC sa creada ca e legat la MC-urile originale.

Prima problema a fost cand a trebuit sa separ comunicatia seriala. HC-ul comunica cu MC-urile pe un singur fir, comun intre ALT si AZ. MC-urile nu vorbesc de capul lor si raspund doar la comenzile ce li se adreseaza.
Pe Arduino comunicatia seriala stie ca Rx si Tx sunt pe fire separate. Daca le pui in scurt iese varza in buffere.
Mare minune ca libraria SoftwareSerial e prost implementata si nu poate gestiona Rx si Tx in acelasi timp, prioritate avand Rx. Deci nu mai folosesc hardware serial ci o emulez software.
Viteza reala, in steps/sec, am vazut ca e raportul intre valoarea trimisa de MC in secventa de initializare la comanda :b (InquireTimerInterruptFreq = 19531.25) si valoarea parametrului I (track speed).
Am ignorat encoderele si am folosit pozitia motorului gestionata de librarie.

Motorul se invarte, la viteze mici, exact cum era comandat de HC. Parca se mai auzea cate un sughit din cand in cand, atunci cand HC interoga MC cam la 10 sec.
La viteze mari (goto) sughitul era stranut in toata regula. HC-ul interogheaza positia cam de 2 ori/sec. Motorul se oprea atunci cand pe seriala aparea orice comunicatie. Nu intepenea mult timp dar era inacceptabil. Adio acceleratie si viteza uniforma. Asta din cauza ca in Arduino intreruperile pentru comunicatie blocheaza procesorul si libraria pentru stepper e in pom atunci cand lucreaza seriala.
Cum nu puteam sa opresc HC-ul sa-si faca treaba am mai pus un Arduino pe post de proxy. El comunica cu HC si MC pe seriale separate. Aici emulez un motor care se misca sincron cu cel real si trimit catre HC pozitia lui. Catre MC trimit doar setupul de goto si semnal de start. Cand motorul virtual din proxy se opreste inseamna ca s-a oprit si cel din MC si atunci permit comunicatia transparenta.
Ce s-ar intampla cand motorul cand ar merge pe viteza maxima dar ar aparea ceva care-mi blocheaza procesorul? Nici nu vreau sa ma gandesc la ce ar face inertia tubului de 40Kg.
Pentru asta am mai tras 2 fire se semnal intre proxy si MC. Unul care cere motoarelor sa se opreasca si altul in care se raspunde daca viteza e zero si poate accepta comenzi pe serial. Nu e nevoie de intreruperi si am rezolvat-o usor cu semnale HIGH/LOW.

[dcristi]

Pana acum am viteze corecte si uniforme.
Trebuie sa scap de trepidatia inerenta motoarelor stepper. Microstepping e solutia evidenta.
Comand un big easy driver. Vad ca stie 16 microsteps. Merge din prima si trepidatia s-a redus aproape de minim.
Problema e ca libraria nu stie sa gestioneze micro. Il considera pas intreg. Eu as vrea sa folosesc pentru goto pas intreg si micro doar pentru tracking. Altfel ar merge prea incet si as astepta nu_stiu_cat pana cand ajunge la tinta.
Mai bag 3 fire intre Arduino si big_easy_driver prin care comand micro-ul si ma apuc sa modific libraria sa numere corect. Adica daca-i spun ca facem 16 microstep, sa trimita 16 impulsuri la driver, dar sa contorizeze doar 1 step.
Am ales sa merg pe valorile reale caci am citit pe net ca motoarele stepper nu au precizie/cuplu cine stie ce in interiorul pasului ci doar la capete. Chiar si asa sper sa respecte macar 1/2 din pozitiile de 1/16 comandate.

Caut pe net "stepper gearbox" si comand Nema17 cu reductie 14:1. As avea la o rotatie completa 200_pasi x 14_reductie x 220_dinti_pe_ax = 616.000 pasi. Daca micro merge asa cum ma astept atunci imi dublez numarul de pasi pentru o rotatie: 1.232.000.
Sky-Watcher zice ca pentru motor DC, asa cum vine din fabrica, ar avea 1.620.000 pasi. Hai sa zicem ca as putea sa traiesc cu asta sau, in cel mai rau caz, as comanda motoare cu reductia ceva mai mare.
Dar am vazut ca SW isi calculeaza rezolutia monturilor EQ luand in considerare toti pasii de micro. In cazul asta marketingul meu ar zice ca am 616.000 x 16 = 9.856.000 pasi pe rotatie.

Cam aici am ajuns. Pana saptamana viitoare, cand imi ajung motoarele, mai bibilesc pe la software. Apoi o sa inceapa distractia maxima caci trebuie sa le montez iar eu la partea mecanica sunt varza.

[nobody]

Cum adica ai comunicatia pe un singur fir ?
Tx si Rx sunt pe fire separate. Este adevarat ca sunt aceleasi la cele doua drivere, dar nu vad de ce ar trebui sa pui Tx si Rx in scurt.

Atmelul are PWM pe 16 biti implementat in hardware dar Arduino cred ca genereaza soft. Oricum nu te-ar ajuta la nimic, problema este cu motorul in sine, nu poti sa-l misti ca un stepper.

Daca tot mergi pe steppere, atunci mai bine folosesti un driver dedicat. Nu are rost sa reinventezi roata in Arduino. Incearca numai sa implementezi controlul curentului in timp real la motor si ai sa vezi unde ajungi ...

Vezi ca mai sunt si ceva comenzi ascunse la MC, Skywatcher nu a dat public protocolul complet. Sper sa nu te afecteze, dar cred ca e bine de stiut daca sunt folosite. N-am avut timp sa-mi bat capul ce fac sau ce reprezinta, poate-ti dai seama tu.

[dcristi]

[katran]

Ma bag si eu ca musca in lapte ...

Intrebare : a folosit vreodata cineva Mach3 ? Asta e un software
care controleaza motoare stepper si servo , prin intermediul driverelor respective . Poti
controla pana la 6 motoare ( 6 axe , 3 liniare si trei rotative ) , daca ai drivere bune , poti
merge la microstep 1/128 ... Controllerul se leaga la comp prin portul paralel , sau daca ai
smoothstepper mergi pe USB ... Singura problema este ca ai nevoie de 36V sa alimentezi
toata chestia ... Mach3 este extrem de configurabil , merge sub XP , poti sa faci motoarele alea
sa stea in 4 labe si sa ceara prajituri ...

Daca postarea e irelevanta , va rog sa ma scuzati ... ignorati-ma .

cheers.

[nobody]

@dcristi
Sincer, nu pot sa cred ca ai Tx legat cu Rx.
La montura mea Alt-Az, am verificat tot traseul de la plecarea din microcontrolerul HC-ului (PIC18F8520), pana la mufa, cablul dintre HC si MC, conectorul de la MC pana la pinii celor doua microcontrolere din MC (PIC16F886). Si peste tot, traseele sunt complet separate. Daca vrei iti pun si poze.
In plus, nu vad nici un avantaj sa fie asa. Nici macar din perspectiva aberanta a economisirii unui fir electric.
Singurele motive plauzibile ar fi ca ori si-au pierdut complet mintile, ori au probleme prea putine si se plictisesc ...
Daca nu-i prea mare deranj, poti pune niste poze cu MC-urile din varianta ta. Chiar sunt curios ce au putut face p'acolo.

Din secventa aia (comentata) de program, vad doar ca activeaza semnalul de Request To Send de la portul serial, semnal care nici nu este folosit in configuratia hardware existenta.

Despre PWM, incercam sa-ti explic ca nu te-ar ajuta la nimic precizia de 16 bit nici daca ai implementa-o cu DAC paralel la 1Gsps. Sunt alti factori greu controlabili sau chiar impredictibili (mecanici, inductivi/magnetici, contactele intre perii si colector, etc.) care spala pe jos cu precizia. Apropo, PIC-urile folosite de Skywatcher in MC au "10-bit PWM with 1, 2 or 4 output channels, programmable “dead time”, max. frequency 20 kHz".

Referitor la driverul "inteligent" de motor, iti ziceam ca esti pe calea cea buna daca nu incerci sa faci totul din Atmel/Arduino

Comenzile ascunse pot deveni un adevarat "showstopper" daca sunt folosite la un moment dat.

Spor la treaba !

[rdaq]

Imi permit sa vin cu cateva sugestii (plecand de la o montura EQ5 am motorizat-o, am proiectat o placa controller pentru motoare folosind un microcontroller Atmel ATmega162, am scris si firmware-ul pentru interfatare cu protocolul Skywatcher pomenit mai sus):
- recomand ca motoarele stepper sa aiba tensiunea nominala (specificata in datasheet) de 3-4 ori mai mica decat tensiunea de alimentare (de exemplu pentru 12V alimentare ar fi bune niste motoare de 3V); motivul: stepper-ele sunt comandate in curent, curentul creste prin bobine pana este limitat de driver, viteza de crester a curentului este mai mare daca tensiunea de alimentare este mai mare si se obtine un cuplu mai bun
- eu am folosit ca drivere DRV8825, asigura 32 microsteps, au curent mare, se gasesc si in tara (eu le-am luat din Germania cu 25 Eur 2 buc.) se interfateaza usor cu microcontrollerul
- cred ca ar fi bine ca demultiplicarea sa fie facuta cu curele dintate daca se poate pentru a reduce erorile de pozitionare generate de backslash
- notiunea PWM, modulatia in latime a impulsurilor este improprie pentru motoarele stepper; pentru acestea conteaza frecventa impulsurilor/micropasilor
Un microcontroller Atmel (fie si impachetat sub forma Arduino) este capabil sa asigure in timp real comanda a doua steppere precum si comunicatia cu hand-controllerul sau EQMOD fara probleme la 16MHz. Eu am folosit capabilitatea microcontrollerului Atmel de a genera impulsurile prin hardware.

Daca este nevoie pot ajuta la realizarea MC prin adaptarea firmware-ului meu la hardware-ul Arduino.
Eu m-am ferit de solutia Arduino - hardware si mediu de dezvoltare - pentru ca te departeaza de microcontroller si de "puterea" lui.
Desi initial am pornit de la ideea lui Thomas Carpenter "AstroEQ" si am folosit schema hardware si firmware-ul sau pentru testele initiale am reproiectat placa MC si am scris alt firmware care asigura GoTo 800x si 32 microsteps. Firmware-ul lui T.Carpenter avea GoTo 200x si 16 microsteps la data aceea.

[dcristi]