Date de mise à jour : 18 mai 2007
De très nombreux instruments d'astronomie sont pilotés par le port série des PC : Moteurs, codeurs, télescopes, roues à filtres, etc.
Audela permet de communiquer avec des systèmes extérieurs au PC en envoyant des ordres par le port série. Il s'agit simplement d'utiliser des fonctions Tcl adaptées. Après une rapide description des fonctions de communication du port série, nous étudierons un exemple concret : La programmation du protocole de la carte AudeCom qui se compose d'une carte électronique et de 3 moteurs pour l'entraînement horaire, la déclinaison et la focalisation.
Les fonctions décrites ici sont présentes dans le Tcl. Elles s'appliquent indifféremment sous Windows (Win 95, 98, NT, Me, 2000 et XP) et Linux, ce qui permet, avec un jeu de commandes Tcl communes, d'écrire un pilote d'instrument directement compatible pour Windows et Linux.
La fonction Tcl
openpermet d'ouvrir la communication avec un "flux" de données. Dans le cas du port série, ce flux de données se nomme comx (x = 1, 2, 3, 4, etc.) sous Windows et /dev/ttySx (x = 0, 1, 2, 3, etc.) sous Linux. Par exemple, pour ouvrir le port com2 sous Windows, on écrira :
open "com2" r+
Le r+ signifie que l'on ouvre en lecture (r comme read) et en écriture (le +). La fonction open, retourne un numéro d'identificateur. Il est important de garder ce numéro car il sera demandé à chaque opération d'entrée/sortie et aussi pour fermer la connexion. Ainsi, on préférera écrire :
set tty [open "com2" r+]
Dans cet exemple, tty est le nom de la variable qui contient l'identificateur du fichier. Par la suite, nous utiliserons toujours tty pour désigner cet identificateur.
De nombreux paramètres doivent être réglés lors de la communication avec le port série. Pour cela on utilise la fonction Tcl fconfigure :
fconfigure $tty -mode "9600,n,8,1"
Ici, on signifie qu'il faut une vitesse de 9600 bauds, aucun bit de parité, 8 bits de données et 1 bit de stop. Ces précisions vous sont données par la documentation du protocole de communication de l'instrument à piloter.
Il est souvent utile de vider le contenu du tampon du port série avant d'envoyer ou de recevoir des données. Pour cela, on utilise la commande Tcl flush :
flush $tty
Il s'agit évidemment d'une fonction fondamentale dans le pilotage de l'instrument. On utilise la fonction Tcl puts. L'exemple, ci-après, envoie les quatre caractères a, b, c et d au départ du port série :
puts -nonewline $tty "abcd"
L'option -nonewline de la fonction puts est souvent utilisée car elle empêche l'envoi du caractère de fin de ligne (\n) après les caractères envoyés.
La fonction Tcl read permet de lire un certain nombre de caractères sur le port série. Par exemple, pour lire 10 caractères :
read $tty 10
Si l'on ne connaît pas le nombre exact de caractères de retour, mieux vaut mettre une grande valeur pour s'assurer d'une réception complète.
Il s'agit simplement de la fonction Tcl close qui agit sur l'identificateur spécifié :
close $tty
Après avoir envoyé un ordre dans le port série, il faut parfois attendre quelques millisecondes avant que l'appareil commandé puisse en recevoir un autre. La fonction Tcl after attend le nombre le millisecondes spécifié :
after 50
Attend 50 millisecondes avant de continuer.
Nous allons programmer un script permettant d'ajouter des fonctions à Tcl pour piloter la carte AudeCom. Après un rapide tour de la description du protocole, nous tâcherons de décrire les fonctions essentielles pour motoriser un télescope.
Configuration du port :
Configuration ASCII :
Dans la suite de cette description, le mot <CR> signifie retour chariot (Carriage Return en anglais). Au niveau du langage Tcl, cela correspond au caractère défini par \r correspondant au code ASCII numéro 13 décimal (code CR).
Si on a choisi de commander la carte AudeCom via l'Hyperterminal de Windows (hors Audela), préciser "Envoyer les fins de ligne avec retour à la ligne" non coché. Si c'est coché, un code LF sera ajouté à chaque CR envoyé. Windows ne comprend pas spontanément qu'après un retour chariot on ne souhaite pas en général que le texte se réécrive sur la même ligne.
Attention : Pour la commande #:U# il s'agit d'une bascule, ce qui signifie qu'à chaque fois que la commande est activée on passe d'un mode à l'autre. Si au départ on n'était pas dans le mode supposé il faut s'attendre à des interprétations fausses des commandes. AudeCom démarre dans le format "court" (exigence pour la compatibilité avec le logiciel GUIDE).
N.B. : La commande <ACK>, correspond au code de contrôle ASCII "ACKnoledge" de valeur 6 en décimal. On peut l'obtenir sur un PC en activant simultanément les touches <CTRL> et F ou <ALT> et 6 (sur le pavé numérique uniquement). ° correspond en fait au caractère ASCII non imprimable 223.
Toutes ces commandes sont celles utilisées par la raquette virtuelle, c'est à dire la raquette que l'on peut faire apparaître dans les logiciels "planétarium".
Nous allons voir qu'il est tout à fait possible de piloter la carte AudeCom directement en mode natif, ce qui permet donc d'utiliser explicitement les secondes de temps et de degrés dans l'envoie des coordonnées à pointer.
Cette commande active automatiquement l'écho des commandes envoyées (cf. commandes natives) :
N.B. : <CR> correspond au code ASCII du ‘retour chariot’ qui correspond à la valeur 13 en décimal. On peut l'obtenir sur un PC en activant la touche ‘retour chariot’, ou simultanément les touches <CTRL> et M ou <ALT> et 1 puis 3 sur le pavé numérique (utile si le ‘retour chariot’ est interprété et non transmis par le logiciel utilisé). Si on utilise un langage de programmation qui respecte la syntaxe du C, il faut terminer la ligne de commande par ‘\r’ et pas par ‘\n’ qui provoque selon le système d'exploitation l'émission de ‘saut de ligne’ ou ‘saut de ligne’ et ‘retour chariot’, ce qui perturbe dans tous les cas la carte AudeCom.
Le rôle de uSNNNNNNNN et vSNNNNNNNN est de provoquer un déplacement lent par rapport au fond du ciel, en ascension droite et/ou en déclinaison pour :
Le rôle de kSNNNNNNNN est de provoquer un déplacement lent par rapport au suivi normal en ascension droite uniquement pour :
Il faut bien noter que « u » et « v » provoquent une variation lente des coordonnées du télescope, en même temps que ce dernier se déplace ; ce n'est pas le cas de « k » qui ne modifie pas les coordonnées du télescope. L'usage n'est donc pas du tout le même.
Sur une carte AudeCom programmée avec des valeurs standards, un coefficient de variation de 202 ; par exemple : u202, arrête le suivi stellaire (mais pendant ce temps les coordonnées en ascension droite évoluent doucement), alors que u-202 double la vitesse de suivi. u99999999 annule une correction de dérive antérieure (car la correction tend vers 0). k202 annule aussi le suivi stellaire, mais dans ce cas les coordonnées en ascension droite n'évoluent pas.
SNNNNNNNN est un nombre entier signé dont la valeur absolue doit être supérieure ou égale à 100, et de maximum huit chiffres. Cette valeur correspond au nombre de fois qu'il faudra attendre 329.1318892981 microsecondes avant que le télescope se déplace d'une seconde d'arc (la période donnée est valable dans le cas standard uniquement, car elle dépend du rapport de réduction utilisée par le télescope).
SHHMMSS correspond à un angle horaire défini par six chiffres en heures, minutes, secondes. Des « : » ou autres « grigris décoratifs » peuvent être ajoutés pour améliorer la lisibilité. Un signe négatif précédant la valeur de l'angle horaire provoque le déplacement selon le parcours le plus long au lieu du parcours le plus court. Ceci peut être utile avec certains télescopes dès que l'angle horaire de départ ou d'arrivée dépasse six heures et qu'on ne souhaite pas que le tube du télescope creuse une tranchée sous terre ou arrache un pied au passage par le méridien.
SDDMMSS correspond à un angle signé en degrés, minutes, secondes en 6 chiffres. Un signe - doit être ajouté si l'angle est négatif. Des « : » ou autres « grigris décoratifs », ainsi que le signe +, peuvent être ajoutés pour améliorer la lisibilité.
Lorsqu'on fournit une valeur à la carte, il est inutile de transmettre tous les zéros non significatifs ; toutefois il faut que le nombre de chiffres transmis soit pair.
Exemple : d05:20:40 correspond à 5° 20' 40" en déclinaison ; d5:20:40 est incorrect.
D'une façon générale, les signes autres que les chiffres 0 à 9 et le signe – sont totalement ignorés par la carte AudeCom dans les paramètres (ceci est valable également en mode LX200).
SNNNNN correspond à un nombre signé à cinq chiffres maximum dont la valeur absolue est inférieure à 32768.
NNN est un nombre non signé supérieur ou égal à 5 et inférieur à 256. Cette valeur correspond au nombre de fois qu'il faudra attendre 200 microsecondes avant que le moteur se déplace d'un pas ; pas qui correspond également à une incrémentation de 1 (ou une décrémentation de 1) de la position absolue de la focalisation.
P et p (pour pause) ont été créées pour stopper momentanément le suivi stellaire si on doit faire autre chose : Intervenir sur le télescope, sortir, fumer, boire, dormir, etc. et qu'on veut éviter que le télescope aille pointer vers un endroit à problème entre temps (butée, toiture, sol, etc.). Le programme prend évidemment en compte automatiquement l'évolution de la position du télescope par rapport au fond du ciel et il ne sera donc pas nécessaire de le réinitialiser.
N.B. : Ces commandes avaient un comportement différent dans les versions 1 et 2 du firmware, car e et p étaient des bascules.
Le but de s ou S va être expliqué par un exemple : En cours de pointage, une comète, supernovae ou autre objet miraculeux apparaît dans le viseur, on active alors s ou S. Le télescope continuera un peu sur son inertie, mais reviendra tout seul au point exact de l'instant ou s(top) a été activé. Cette commande est aussi utile en cas de changement d'avis. Elle peut aussi être utile si on s'aperçoit qu'on a pointé vers un endroit situé sous l'horizon.…
On peut noter d'une façon générale que les commandes en minuscule émettent un paramètre et/ou activent une action, tandis que les commandes en majuscule attendent un paramètre en retour et/ou inhibent une action.
Nous allons écrire ici le script minimum, qui ajoute les fonctions suivantes :
#--- acomdriv.tcl : script minimum
proc acom_create { port } {
#--- etablit la liaison
set tty [ open $port r+ ]
fconfigure $tty -mode "9600,n,8,1" -buffering none -blocking 0
after 150
#--- passe en mode natif
puts -nonewline $tty "#:Lx#"
after 150
#--- inihibe l'echo des commandes entrantes
puts -nonewline $tty "E\r"
after 150
#--- lit le port serie pour supprimer l'echo de E
read $tty 8
after 150
#--- deuxieme lecture -- supprime une anomalie lors
#--- du passage de E --> e --> E
read $tty 8
after 150
return $tty
}
proc acom_coord { tty } {
#--- lit les coordonnees
#--- demande ra
puts -nonewline $tty "A \r"
after 150
#--- lit ra sur le port serie
set ra [ read $tty 8 ]
after 150
#--- demande dec
puts -nonewline $tty "D \r"
after 150
#--- lit dec sur le port serie
set dec [ read $tty 8 ]
after 150
return [ list $ra $dec ]
}
proc acom_goto { tty radec { signe "" } } {
#--- $signe == "" --> plus court chemin
#--- $signe == "-" --> plus long chemin
#--- convertit les coordonnees au format AudeCom
set angle_ra [ lindex $radec 0 ]
set angle_dec [ lindex $radec 1 ]
set radeg [ mc_angle2deg $angle_ra ]
set rahms [ mc_angle2hms $radeg ]
set decdms [ mc_angle2dms $angle_dec dec ]
set ra [ format "%02d%02d%02.0f" [ lindex $rahms 0 ] [ lindex $rahms 1 ] [ lindex $rahms 2 ] ]
set signedec "+"
if { [ mc_angle2deg $angle_dec 90 ] < 0 } {
set signedec "-"
}
set dec [ format "%s%02d%02d%02.0f" $signedec [ expr abs( [ lindex $decdms 0 ] ) ] [ lindex $decdms 1 ] [ lindex $decdms 2 ] ]
#--- envoie l'ordre ra de ralliement au telescope
puts -nonewline $tty "a$signe$ra\r"
after 150
#--- envoie l'ordre dec de ralliement au telescope
puts -nonewline $tty "d$dec\r"
after 150
#--- boucle tant que le telescope n'est pas arrete
set radec0 [ acom_coord $tty ]
after 500
set radec1 [ acom_coord $tty ]
while { $radec0 != $radec1 } {
set radec0 $radec1
after 500
set radec1 [ acom_coord $tty ]
}
}
proc acom_delete { tty } {
close $tty
}
Ce script, doit être écrit dans le fichier acomdriv.tcl pour être utilisé avec les exemples ultérieurs.
L'exemple suivant montre comment pointer un objet avec le script minimal :
#--- acomtest.tcl : test du protocole de la carte AudeCom
source acomdriv.tcl
set tty [ acom_create com2 ]
::console::affiche_resultat [ acom_coord $tty ]
acom_goto $tty { 12h45m32s -12d28m43s }
::console::affiche_resultat [ acom_coord $tty ]
acom_delete $tty
Utilisé avec l'interface Audace, ce script permet de pointer le télescope aux coordonnées spécifiées puis renvoie ces coordonnées une fois le ralliement effectué. Pour faire les tests, on placera donc les scripts acomtest.tcl et acomdriv.tcl dans le dossier principal de Audela, c'est à dire celui juste un niveau au dessus du répertoire audace. On lancera donc le script acomtest.tcl depuis la ligne de commande par :
source acomtest.tcl
En vertu de la documentation du protocole, il est donc possible d'ajouter des fonctions au fichier du driver (acomdriv.tcl) de façon à donner la possibilité d'utiliser simplement l'ensemble des fonctions avec une syntaxe simplifiée. Il est aussi possible de programmer le PEC, la focalisation, etc.
Les scripts acomdriv.tcl et acomtest.tcl travaillent en coopération. Les commandes "utilisateur" sont écrites dans le fichier acomtest.tcl. On charge le driver (source acomdriv.tcl), ouvre le port série (set tty [ acom_create com2 ]), pointe le télescope (acom_goto $tty { 12h45m32s -12d28m43s }) puis ferme le port série (acom_delete $tty). La variable tty contient l'identificateur de fichier associé au port série. En effet, le port série est vu comme un simple fichier que l'on ouvre, dans lequel on écrit, puis que l'on ferme. La variable tty sert donc à indiquer à l'interpréteur Tcl que le fichier est en fait le port série.
Il est important d'utiliser une structure séparée en deux fichier : L'un (acomdriv.tcl) sert à définir les nouvelles fonctions associées au pilotage du port série et à la mise en forme des données selon le protocole, l'autre (acomtest.tcl) concerne l'exécution des fonctions du driver. Ainsi on évite de mélanger les ordres opérationnels et les mises en forme de la communication selon le protocole établi.
Nous venons de décrire le driver minimal : Pointage et lectures des coordonnées. Les lignes Tcl ci-dessous permettent d'accéder à d'autres fonctions (ici la commande du moteur de focalisation) si elles sont insérées dans le fichier acomdriv.tcl :
proc acom_foc_zero { tty } {
#--- met le compteur FOC a zero
puts -nonewline $tty "g\r"
after 150
return
}
proc acom_foc_goto { tty foc } {
#--- deplacement de la FOC
puts -nonewline $tty "f$foc\r"
after 150
#--- boucle tant que la FOC n'est pas arretee
set foc0 [ acom_foc_coord $tty ]
after 500
set foc1 [ acom_foc_coord $tty ]
while { $foc0 != $foc1 } {
set foc0 $foc1
after 500
set foc1 [ acom_foc_coord $tty ]
}
}
proc acom_foc_coord { tty } {
#--- lit la position courante de la FOC
#--- demande foc
puts -nonewline $tty "F\r"
after 150
#--- lit foc sur le port serie
set foc [ read $tty 8 ]
after 150
return $foc
}
proc kauf_foc_vit { tty vfoc } {
#--- vitesse moteur de focalisation
puts -nonewline $tty "h$vfoc\r"
after 150
}
Il est donc très facile d'ajouter les commandes d'initialisation, de vitesse du moteur, etc.
Après avoir écrit un script ajoutant les fonctions nécessaires à piloter un nouvel instrument, il vient naturellement à l'esprit de les transcrire dans les fonctions "objet" de pilotage de Audela. Par exemple, pour les télescopes, l'objet s'appelle tel (télescope). Reprenons l'exemple du driver de la carte AudeCom. Dans le fichier acomdriv.tcl, l'ouverture de la connexion est définie par la fonction :
acom_create com2L'équivalent "objet" de Audela serait :
tel::create audecom com2De même pour les autres fonctions :
|
|
set tty [ acom_create com2 ] |
set tty [ tel::create audecom com2 ] |
acom_goto $tty { 12h45m32s -12d28m43s } |
tel$tty goto { 12h45m32s -12d28m43s } |
acom_coord $tty |
tel$tty coord |
acom_delete $tty |
tel::delete $tty |
Dans le cas d'un instrument commercial, la conversion vers un objet Audela sera implantée dans les fonctions de "télescope" programmées dans une librairie spécifique à l'instrument (liblx200.dll par exemple). De cette façon, votre travail pourra être utilisé par les autres utilisateurs de l'instrument.
Il faut néanmoins respecter quelques règles dans le fichier driver Tcl. N'utiliser que des fonctions Tcl, Audela et de la librairie MC afin d'assurer une transcription "mot à mot" du driver Tcl vers un objet Audela.
Dans le cas d'un instrument à exemplaire unique, il n'est pas très utile d'implanter le driver dans la librairie standard de Audela ou dans une librairie spécifique. Dans ce cas, on préférera utiliser un autre méthode, certes moins universelle, mais répondant généralement aux besoins personnels : La surcharge des méthodes. On appelle méthode, une fonction associée à un objet. Dans notre cas, l'objet est un télescope et la méthode goto est une fonction qui rallie le télescope aux coordonnées spécifiées. Ce mode de programmation est réservé aux personnes qui maîtrisent bien le langage Tcl.
#--- acomtel.tcl : ajoute un driver perso a l'objet tel de Audela
#--- on renomme la fonction tel::create de Audela
proc ::tel::create_audela { type port { tty 0 } } {
if { $tty == 0 } {
::tel::create $type $port
} else {
::tel::create $type $port $tty
}
}
#--- on renomme la fonction tel::delete de Audela
proc ::tel::delete_audela { tty } {
::tel::delete $tty
}
#--- on renomme la fonction tel::list de Audela
proc ::tel::list_audela { tty } {
::tel::list $tty
}
#--- on charge le driver Tcl
source acomdriv.tcl
#--- on surcharge la fonction de creation du telescope
proc ::tel::create { type port {tty 0} } {
if { $type == "audecom" } {
set tty [ acom_create $port ]
} else {
::tel::create_audela $type $port $tty
}
return $tty
}
#--- on surcharge la fonction tel1
proc ::tel$tty { fonc listargv } {
global tty
set result "Fonction non reconnue"
switch $fonc {
coord {
set result [acom_coord $tty $listargv]
}
goto {
set result [acom_goto $tty $listargv]
}
}
return $result
}
#--- on surcharge la fonction de deconnexion du telescope
proc ::tel::delete { tty } {
if { [ string index $tty 0 ] == "f" } {
set tty [ acom_delete $tty ]
set tty 0
} else {
::tel::delete_audela $tty
}
}
#--- on surcharge la fonction de liste des telescopes
proc ::tel::list { } {
global tty
if { [ info exists tty ] == "0" } {
return
}
if { [ string index $tty 0 ] == "f" } {
return $tty
} else {
::tel::list_audela
}
}
#--- on deconnecte tous les telescopes presents autres que celui du nouveau driver
set listnum [ ::tel::list ]
foreach num $listnum {
if { [ string index $tty 0 ] == "f" } {
::tel::delete $num
}
}
Ce long script (à tester !) permet donc d'utiliser le driver acomdriv.tcl par l'intermédiaire des objets de Audela. Par exemple, le script d'utilisation du driver minimal, évoqué plus haut, s'écrit maintenant :
#--- acomtest2.tcl : test du protocole de la carte AudeCom
source acomtel.tcl
set tty [ tel::create acommann com2 ]
tel$tty goto { 12h45m32s -12d28m43s }
tel$tty coord
tel::delete $tty
Ainsi, il devient possible d'utiliser un instrument personnel en exécutant des scripts Audela ou Audace qui pilotent des télescopes.
Audela est riche d'autres exemples de scripts développés pour répondre à des protocoles et/ou des applications spécifiques. Vous accéderez à ces protocoles et/ou applications par le menu déroulant Configuration et ensuite Monture. Ce sont entre autres les objets télescope suivants :
Qui pilote l'interface spécifique Ouranos pour permettre de connaître, après initialisation, la position de votre télescope. Vous pouvez décortiquer les scripts conftel.tcl et ouranoscom.tcl pour en apprendre plus.
D'autres protocoles verront le jour en fonction des besoins de chaque utilisateur, déjà Temma, ASCOM et Celestron pointent le bout de leurs nez. Cette page a pour but de vous montrer qu'il n'est pas insurmontable de créer un script et une interface graphique pour un protocole particulier.
Ce protocole, défini par Philippe Kauffmann, est totalement implanté dans Audela par l'intermédiaire de panneaux de configuration et d'interfaces graphiques. Je vous recommande l'étude approfondie des fichiers conftel.tcl et audecom.tcl pour la définition et la prise en compte du protocole AudeCom, ainsi que les fichiers foc.tcl, tel.tcl, etc. pour comprendre la mise en oeuvre de ce protocole par l'intermédiaire d'interfaces graphiques spécifiques.