----------------------------------- dcristi 14 Aug 2014 00:38 Proiect - DOB SW / stepper ----------------------------------- 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 14 Aug 2014 00:48 ----------------------------------- 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 14 Aug 2014 04:26 ----------------------------------- 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 14 Aug 2014 09:58 ----------------------------------- O solutie ar fi inlocuirea motoarelor cu ceva mai de calitate si cu mai multi poli (contacte). Dar alea costa ... Iar daca motoarele nu au rotor 'ironless' probabil ca au si o anumita inertie magnetica , in salturi egale cu produsul dintre numarul de poli ai rotorului si cel (probabil doar doi) al statorului. ----------------------------------- dcristi 14 Aug 2014 10:47 ----------------------------------- 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 14 Aug 2014 11:43 ----------------------------------- Apropo, vezi ca sunt update-uri de firmware si pentru MC. Stiu ca au mai facut tuning exact la felul cum se misca motoarele. Pentru DOB nu am vazut ca ar fi facut update-uri. Cel putin nu pentru modelul meu. O sa ma interesez de motoarele de care zici doar daca esuez in proiectul cu stepper. Motoarele le-am comandat deja si le primesc saptamana viitoare. ----------------------------------- dcristi 14 Aug 2014 11:46 ----------------------------------- 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 14 Aug 2014 13:07 ----------------------------------- 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 14 Aug 2014 13:56 ----------------------------------- 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 14 Aug 2014 19:42 ----------------------------------- 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 15 Aug 2014 11:36 ----------------------------------- 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. Nu fac eu asta ca nu-mi bat singur cuie in talpa :) Asa face synscan, se pare, pentru monturile care au motoare DC. In MC original Rx si Tx sunt in scurt. Vad ca si API-ul publicat de Sky-Watcher trateaza problema diferit, adica opreste Tx dupa ce trimite o comanda catre MC. Dau aici doar o parte din cod: // Test if connect to DC motor board. private bool CheckIfDCMotor() .... //// Enable TX driver. //EscapeCommFunction(hCom, SETRTS); //// Wait TX enabled //Sleep(20); .... //// Disable TX driver. //// EscapeCommFunction(hCom, CLRRTS); .... // IsDCMotor = TRUE; // // Disable TX driver if it is a DC motor controller. // EscapeCommFunction(hCom, CLRRTS); Atmelul are PWM pe 16 biti implementat in hardware dar Arduino cred ca genereaza soft. Asa e. Dar atunci cand folosesti frecvente mari, 20kHz in cazul asta, nu-ti mai ajunge frecventa procesorului ca sa beneficiezi de toti cei 16 biti. Mi-ar trebui ca pentru fiecare pas al PWM sa am inca 65535 perioade de ceas pe care sa le numar. 20.000 (PWM) x 65.535 (rezolutie) = 1.310.700.000 Hz. Cam greu de obtinut asta. Ca sa am rezolutia pe 16 bit trebuie sa micsorez frecventa PWM pana la 16 MHz / 65.535 = 800 Hz. cam putin. Calculul e facut pentru un procesor ce ruleaza la 16 MHz indiferent de producator. 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 ... Poate m-am exprimat gresit. Eu arunc tot si pastrez doar Synscan. Un fel de EQMod pe invers :) Am cate un Arduino pentru fiecare motor cu care generez pasii si cate un driver pentru stepper, care stie 16 microstep, si evident putere mai mare. Driverului ii spui directia, cati micropasi vrei, si impulsul de step. El face singur balansul de curent. Daca stau sa ma gandesc bine pot folosi setupul asta sa motorizez orice montura, cu orice reductie, dar sa am controller Synscan. Vezi ca mai sunt si ceva comenzi ascunse la MC, Skywatcher nu a dat public protocolul complet. Or fi dar nu stiu daca ma mai intereseaza in momentul asta. Eu am interceptat conversatia intre Synscan si MC-ul original si am reimplementat toate comenzile. Nu am programat comenzile de PEC sau pacare telescop pentru ca nu le folosesc acum. ----------------------------------- katran 15 Aug 2014 15:34 ----------------------------------- 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 15 Aug 2014 22:36 ----------------------------------- @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 ... :lol: 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 :wink: Comenzile ascunse pot deveni un adevarat "showstopper" daca sunt folosite la un moment dat. Spor la treaba ! ----------------------------------- rdaq 15 Aug 2014 22:55 ----------------------------------- 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 17 Aug 2014 15:30 ----------------------------------- 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. Pozele sunt aici: http://www.astronomy.ro/forum/viewtopic.php?p=129781 Eu asa imi aduc aminte. Ca erau in scurt si asa le identificam usor cand faceam cablul. Mai fac o verificare maine. Daca sunt separate inseamna ca m-am ramolit. Daca sunt legate doar in MC iar m-am ramolit ca ar fi trebuit sa le folosesc separat, asa cum vin din HC. Sunt alti factori greu controlabili sau chiar impredictibili (mecanici, inductivi/magnetici, contactele intre perii si colector, etc.) care spala pe jos cu precizia. Asa e. Eu eram convins ca e fix pe dos. Adica mecanica ar raspunde bine si electronica e inghesuita. Comenzile ascunse pot deveni un adevarat "showstopper" daca sunt folosite la un moment dat. Sa vezi de nu fac un brute-force pe MC. Iau tot alfabetul, caps & normal, si-l trimit pe post de comanda, in cele 3 combinatii posibile. Vad unde raspunde cu eroare si inseamna ca aia e comanda valida. ----------------------------------- dcristi 17 Aug 2014 17:45 ----------------------------------- 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 Ai dreptate. Dar asta ar insemna sa intru pe un teren minat pentru mine. Hai sa vad intai cum se descurca motoarele astea pe care le-am cumparat. In datele tehnice scrie ca au un backlash sub 1% dupa reductie, adica 8 pasi sau 16 asec pe ax telescop. Ce apare dupa melc e alta mancare de peste. notiunea PWM, modulatia in latime a impulsurilor este improprie pentru motoarele stepper Asa e. Eu vreau, acum, sa inlocuiesc DC cu stepper. Initial am vrut sa merg tot pe DC dar cu un alt controller. 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. Si eu am crezut acelasi lucru. Poate ca ori din cauza ca nu am programat eu eficient, ori din cauza intreruperilor generate de comunicatia seriala, impulsurile generate pentru stepper nu curgeau uniform. Daca este nevoie pot ajuta la realizarea MC prin adaptarea firmware-ului meu la hardware-ul Arduino. Multumesc frumos pentru oferta! Nu cred ca e vorba doar de o simpla adaptare. La EQ, pentru tracking, ai o singura viteza - siderala. Aici, la Alt/Az, vitezele se schimba permanent. Probabil ca la goto e ca la EQ. Trebuie doar sa ai grija de acelerare, sa nu sari calul, si sa pierzi pasi. Sunt in stadiul in care mai am de programat citirea encoderului de pe ax ca sa implementez si push & track. Hai sa vad cum merge treaba si daca ma blochez am sa-ti cer ajutorul :) ----------------------------------- dcristi 19 Aug 2014 18:35 ----------------------------------- 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. Scuze. Stiam eu ca am vazut pe undeva comentat in API-ul original. Iata aici cum le zic ei: private bool IsDCMotor; // Ture: The motor controller is a DC motor controller. It uses TX/RX line is bus topology. // False: The motor controller is a stepper motor controller. TX/RX lines are seperated. ----------------------------------- dcristi 20 Aug 2014 16:30 ----------------------------------- Am facut testele de viteza punand cele doua motoare unul langa celalalt, fiecare pe controllerul lui. Cel original, DC, are 180 pasi ai encoderului pe revolutie si 50x reductie. Stepperul are 200 pasi pe revolutie si reductia am facut-o din soft, adica am impartit viteza ceruta la 45. Cifra asta a iesit din regula de 3 simpla: 180x50/200 La orice viteza de tracking motoarele se invart identic. Asta inseamna ca nu am gresit la calcule. La goto stepperul pierde pasi din cauza rezonantei aparute in timpul acceleratiei. Daca-i pun o sarcina merge perfect si se intoarce mereu in aceeasi pozitie cand fac goto-back. Sper ca pe telescop, unde am o sarcina serioasa, sa nu am probleme. ----------------------------------- valy 20 Aug 2014 23:52 ----------------------------------- La goto stepperul pierde pasi din cauza rezonantei aparute in timpul acceleratiei.Daca il controlezi tu redu-i viteza din soft dar tine minte cati pasi ti-a comandat gotoul, ii faci dar mai domol. ----------------------------------- dcristi 21 Aug 2014 10:48 ----------------------------------- Daca il controlezi tu redu-i viteza din soft dar tine minte cati pasi ti-a comandat gotoul, ii faci dar mai domol. Rezonanta apare, garantat, la mersul in gol cam la 90-100 pasi pe sec. Ca sa merg pe o viteza inferioara m-am plictisi pana cand ar ajunge la tinta. Sau nu ar gasi-o niciodata cu precizie caci tinta s-ar misca prea mult cat timp motorul o cauta. Presupun ca-mi trebuie cam 1000 pasi pe sec. O sa vad precis cand oi pune motoarele pe montura. Poate ma ajuta cineva ca nu stiu cum se intampla asta: GOTO-ul te trimite la coordonatele in care va fi obiectul dupa cele X secunde de slew sau la coordonatele la care se afla obiectul cand se da da comanda? Probabil are si o toleranta programata si daca e la o distanta suficient de mica de obiect atunci considera ca ajuns la destinatie. Revenind. Am cateva variante: - sa folosesc o accelerarie mai mare astfel incat sa treaca repede peste viteza de rezonanta, dar nu prea mare ca sa nu piarda pasi si la alte viteze. Tot as pierde pasi; - sa nu fac nimic sperand ca in sarcina nu mai apara rezonanta. Inertia monturii ar opri dansul aleatoriu al rezonantei. Atunci ce ma fac cu backlash-ul din cutia de viteze care poate fi de pana la 8 pasi? - sa pun encoder pe ax motor ca numar pasii reali; - sa micsorez curentul in motor ca sa am cuplu mai mic si atunci rotorul nu mai zboara peste pozitie. Deocamdata raman pe varianta 2 plus 4 :) ----------------------------------- Erwin 21 Aug 2014 19:05 ----------------------------------- Cred ca ai nevoie de un driver mai destept care detecteaza singur rezonanta si corecteaza panta de curent la fiecare pas, cred ca A3966 are asa ceva inclus, daca tin minte... Stiu ca exista si posibilitatea numararii pasilor prin detectia variatiilor de curent prin bobinele motorului. ----------------------------------- cmatei 21 Aug 2014 20:17 ----------------------------------- Poate ma ajuta cineva ca nu stiu cum se intampla asta: GOTO-ul te trimite la coordonatele in care va fi obiectul dupa cele X secunde de slew sau la coordonatele la care se afla obiectul cand se da da comanda? Probabil are si o toleranta programata si daca e la o distanta suficient de mica de obiect atunci considera ca ajuns la destinatie. Cred ca la coordonatele calculate pentru momentul comenzii, pentru ca daca slew-ul dureaza mult mai face o repozitionare la viteza mica (eq6). ----------------------------------- dcristi 03 Sep 2014 16:19 ----------------------------------- In noptile senine de saptamana trecuta am tot testat motoarele. Totul a functionat perfect din prima incercare. GOTO are aceeasi precizie ca atunci cand Synscanul folosea encoderele. Deci nu pierd prea multi pasi. Pun aici un test pe stea, cred ca e Altair, tras in aceleasi conditii ca Saturn pus in primul post. Adica am redus imaginea la 2x si am facut acelasi crop. Trackingul arata mult mai uman. Focala originala e 7.2m iar rezolutia in poza asta e de 0.2 arcsec/pixel si gamma crescut mult. Ce vreau sa fac mai departe: - incerc si un driver cu L6470 care vad ca stie 128 micropasi si am vazut in documentatie poate sa faca niste optimizari pentru viteze mici. - nu sunt multumit de cum se actualizeaza vitezele de track din Synscan. Se modifica la fiecare 3 interogari de pozitie adica la 30 secunde. In live imaginea sta nemiscata 30 sec, apoi pleaca usor intr-o parte pentru alte 30 sec, apoi inapoi 30 sec si tot asa. Distanta pe care se plimba e cam de 50 arcsec. Am sa fac track tot din arduino si am sa actualizez vitezele mult mai des. Apoi pot lucra chiar si fara Synscan daca nu vreau GOTO. ----------------------------------- dcristi 05 Sep 2014 15:11 ----------------------------------- Am gasit si formulele pentru track ALT/AZ - doar sideral. Le pun aici ca poate or mai fi utile cuiva. Le-am cautat mult pentru ca mi-a fost lene sa-mi bat capul cu trigonometria. Credit: Mel Bartels Valorile scoase de ecuatii, in arcsec/sec, sunt apropiate de cele scoase de Synscan. AZ_Rate = 15 * sidereal * (sin(LAT) + cot(pi/2 - ALT) * cos(pi - AZ) * cos(LAT)); ALT_Rate = 15 * sidereal * sin(pi - AZ) * cos(LAT); sidereal e clasicul 1.002737909. Poate reusesc sa le implementez in weekendul asta impreuna cu noul controller. Daca totul merge bine o sa le imbunatatesc cu Lunar_Rate si cu King_Rate. ----------------------------------- Erwin 05 Sep 2014 16:02 ----------------------------------- Dacă le bagi în Arduino m-ar interesa și pe mine rutina de comandă a motoarelor pentru a finaliza astrotrac-ul mioritic al lui StarChild, desigur l-aș adapta pentru un singur motor, trebuie să aibă doar urmărire pe cele 3 viteze: siderală, lunară și solară și eventual retur la zero cu viteză mare. ----------------------------------- nobody 05 Sep 2014 19:50 ----------------------------------- Pun si cateva link-uri utile, sper sa nu deranjeze: Scope To Sky Calculator: http://www.bbastrodesigns.com/scopeToSky.html Code: http://www.bbastrodesigns.com/lib/coordLib.js Equatorial Mount Tracking Rates Calculator, Includes Refraction: http://www.bbastrodesigns.com/equatTrackingRatesCalc.html Polar alignment, refraction and the King tracking rate: http://canburytech.net/DriftAlign/DriftAlign_3.html Drift alignment equations: http://canburytech.net/DriftAlign/Equations.html Iar daca tot te-ai apucat de treaba la modul serios, ar fi interesant daca ai face un profiling la rutinele matematice, in sensul de cat poate duce Arduino si la ce precizie. Apropo, ATmega-urile normale de 16Mhz merg lejer la 20MHz. Testat de ani de zile. Iar cele mai noi de 20MHz rated (ATmega328 de pe Arduino Uno) ar putea duce chiar mai mult daca suporta Arduino din soft. Despre comenzile ascunse: "Sa vezi de nu fac un brute-force pe MC. Iau tot alfabetul, caps & normal, si-l trimit pe post de comanda, in cele 3 combinatii posibile. Vad unde raspunde cu eroare si inseamna ca aia e comanda valida." ... exact asa le-am descoperit, din curiozitate :wink: Spor !