Ciao JohnHardening,data la mia ignoranza,per cercare di rispondere alla tua INTERESSANTE domanda,ho interpellato la persona con la quale sto sviluppando il progetto dal punto di vista motorizzazione/software,queste è quanto mi ha risposto,magari poi ci ragioniamo insieme:
Onestamente non capisco la domanda su come controllare i motori come se fossero dei veri e propri servo.
I motori possono essere controllati in mille maniere, ma alla fine è sempre il software che gestisce la cosa.
In astronomia la maniera migliore e più precisa di controllare un motore è con il sistema degli step, sconsiglierei a chiunque di fare diversamente.
Mi spiego: i driver dei motori non sono altro che un circuito che traduce una serie di comandi in impulsi elettrici che fanno muovere il motore.
Si può ad esempio scegliere di muovere il motore a velocità costante inviando un apposito comando. In questo caso l’elettronica calcolerà il numero di commutazioni delle fasi da fare in un secondo per ottenere la velocità richiesta.
Stesso identico risultato lo ottengo se invio una frequenza di step costante che realizza la velocità richiesta, cosa che in realtà fa il driver quando gli chiedi una velocità costante.
Stesso ragionamento per altre soluzioni di movimento (tipicamente il controllo avviene per controllo di posizione, velocità, accelerazione o coppia).
In Astronomia quando faccio un goto la situazione è semplice: il software calcola la distanza tra i due oggetti in AR ed in DEC.
Supponiamo di essere puntati su VEGA: 18h 36m 56s AR e 38° 47’ 06” in DEC e di voler puntare DENEB: 20h 42m 04s AR e 45° 09’ 53” in DEC.
La distanza angolare in AR è di 108.308 secondi di arco, quella in DEC è di 22.967 secondi di arco
Pensando alla tua montatura dove il motore di AR ha 6400 microstep e poi viene ridotto 4 volte dalla puleggia e 360 dalla vite/corona so che dovrò muovere il motore di 7.11 step per spostarmi di un secondo di arco, dovrò quindi spostarmi di 770.190 step in AR per muovermi da VEGA a DENEB.
Il motore in DEC ha invece sempre 6400 microstep e riduzione di 4 volte ma solo una di 300 dalla vite/corona e quindi dovrò muovere il motore di 5.92 step per spostarmi di un secondo di arco, dovrò quindi spostarmi di 136.100 step in DEC per muovermi da VEGA a DENEB.
L’elettronica di controllo, che sia OnStep o PrimeTCS o altro non farà quindi altro che inviare 770.190 step in AR e 136.100 in DEC.
La velocità di spostamento sarà decisa dalla frequenza con cui gli step vengono inviati al driver del motore (sia esso montato sul motore o esterno), nei limiti elettronici e meccanici del sistema.
Sarebbe assurdo invece, ancorché possibile, dare un comando di spostarsi ad una data velocità per un periodo di tempo calcolato in maniera da arrivare a spostarsi del numero di step appena calcolato, utilizzando la funzione controllo della velocità.
Utilizzando il controllo di posizione di fatto facciamo la stessa cosa che con un step/direction. Ovvero diciamo al driver a quale posizione vogliamo spostarci (quanti step fare da una posizione all’altra li calcola il driver avendolo configurato con i vari rapporti di cui sopra).
Per inseguire a velocità siderale potrei tranquillamente impostare una velocità di 15.04107 secondi di arco al secondo. Il driver non farebbe altro che tradurre questa istruzione in una commutazione delle fasi che generasse un movimento di 106,958 step al secondo, ovvero la stessa cosa che ottengo comandando in step/direction e generando una frequenza di 106,958Hz al pin dello step.
Quindi le varie opzioni di movimento possibili con motori servo (che sono null’altro che dei normalissimi motori con ciclo chiuso sull’encoder) risultano piuttosto inutili in astronomia.
Ciò detto i motori Teknic sono realizzati in 3 versioni: serie SD, serie MC e serie SC, secondo come si vuole controllarli.
Ciò che cambia è il firmware dell’elettronica, tutto il resto (motore ed encoder e unità di potenza che commuta le fasi del motore) è uguale.
Non ho mai verificato ma credo in linea di principio sia possibile aggiornare il firmware e passare da una modalità all’altra, cosa che comunque ritengo inutile, a meno di dover utilizzare il motore in altra applicazione.
Per quanto riguarda il software open source ce ne sono molti. Ad esempio per la guida io uso PHD2 e ne sono molto soddisfatto (testato anche con OnStep)
Come planetario CarteDuCiel
Per le correzioni tipo Tpoint o Maxpoint non ne conosco, ma non vuol dire che non ci siano, avendo Tpoint non mi sono mai dannato a cercarlo.
Per eventuale CCD di solito un software base lo danno assieme alla camera. Io non ho un CCD ed uso la reflex con DEEP SLY STACKER e poi eventualmente fotoritocco (Photoshop che si paga ma ci sono valide alternative open source)
Aggiunge poi:
I motori NON possono essere controllati da un altro DRIVER, in quanto il DRIVER è integrato.
Ma qualunque altro controller in commercio che io ho visto non fa altro che inviare al DRIVER, eventualmente integrato, la frequenza di step.
Quindi potrebbe essere possibile usare un altro controller tipo quello americano, (qui parla di sitech)collegando i motori all’uscita dello stesso A MONTE dei driver.
Di fatto OnStep nasce con i DRIVER integrati (quelli delle stampanti 3d) e quello che ho fatto io è stato esattamente di collegarmi A MONTE e poi di eliminarli, visto che non venivano usati (oltre ad altre modifiche varie secondo il mio gusto ed esperienza).
La versione del “mio” OnStep che utilizziamo sulle B230 ed Omega mantiene i driver, utilizzandone però di più performanti (i telescopi pesano parecchio di più delle testine di stampa…)
Mi studio per bene le risposte,come sempre aspetto le vostre considerazioni!