moteur cc + encodeur

[michel2001]

Bonjour à tous.

Je possède un télescope comprenant 3 moteurs CC (tension d'alimentation = 5V) couplés à un encodeur US-DIGItAL de ce type :

https://www.usdigital.com/products/e...ental/kit/e4t/

qui servent à la focalisation et la collimation de l'optique.

La commande originelle de ces moteurs est HS.

Existe t il un (des) circuit(s) permettant - au moyen d'un boîtier présentant des boutons poussoir et un contacteur rotatif à plusieurs positions (que je peux fabriquer moi même) - de :

* commander ces 3 moteurs simultanément de manière à ce qu'ils effectuent exactement le même nombre de tours à chaque pression sur un bouton (focalisation).

* commander chaque moteur indépendamment des deux autres (collimation).

* agir simultanément sur la vitesse et le sens de rotation des 3 moteurs (focalisation).

* agir sur la vitesse et le sens de rotation de l'un ou l'autre des 3 moteurs (collimation).

J'ai des connaissances de base en électronique et suis capable de me servir d'un fer à souder pour installer des composants sur une carte.
J'ai une petite expérience avec Arduino, ayant fabriqué pour mon petit-fils un système de commande train miniature HO trouvé sur le site :
http://udelmas.e-monsite.com/pages/c...-wifi-d17.html

Si quelqu'un peut me fournir un schéma, ou me dire quels circuits acheter, ou m'indiquer un site ou je trouverais de l'aide pour résoudre ce problème, ou simplement me conseiller sur ce projet, je lui en serais très reconnaissant.
-----

[Murayama]

Bonjour!


Ext-ce que vous êtes certain que la commande uniquement est HS?
Parce que les encodeurs peuvent l'être aussi. Dans ce cas, ce serait bête
de créer quelque chose qui ne pourra pas fonctionner.
Donc une première chose serait de vérifier les encodeurs:
- Alim de labo 5V
- Ocilloscope sur A/B
Vous faites tourner à la main et vous regarder si A/B sont ce que l'on attend
de ce genre de signal. Vous devez avoir ceci:




NB: je disais alim de labo. Vous pouvez évidemment prendre à peu près n'importe
quoi, mais faites attention tout de même, ce serait bête de griller l'encodeur
parce que l'adapteur DC fabriqué en Chine a de vague-à-l'âme au démarrage.


Ensuite, un telescope, ça ne tourne jamais vite (je n'y connais pas grand chose,
mais j'imagine). Donc Arduino devrait pouvoir suivre. Les AB sont souvent en RS422,
alors il faut les transformer en "single end" avant Arduino.


Il existe des cartes de pilotage de moteurs DC pour Arduino, précisément.


Pendant que nous y sommes: la résolution des encodeurs me semble extrêmement basse.
Sur le lien ci-dessus, on parle de 4000 pulses par tour.
J'aurais imaginé que pour un télescope on aie besoin de beaucoup mieux. Encore une fois,
je n'y connais pas grand chose en télescopes, mais j'aurais choisi mieux.
Juste pour info: même en magnétique on peut avoir 18 bits sur un diamètre de disque similaire.
Donc 250 000 pas par tour.


Pascal

[michel2001]

Bonjour Pascal.

Merci pour votre réponse très documentée.

Quelques précisions.

Il s'agit d'un instrument Meade, le RCX400 (photo 0).00.jpg

Une raquette de commande permet de gérer toutes les fonctions du télescope qui est installé en altazimutal :
Deux gros moteurs permettent d'orienter le tube (pointage) : celui logé dans la base horizontale le fait pivoter selon un axe vertical (réglage de l'azimut), celui logé dans la fourche permet d'abaisser ou de relever le tube optique (réglage de l'altitude), plusieurs vitesses étant disponibles.
Un processeur intégré et programmé associé à une mémoire permet de pointer automatiquement n'importe quel objet du ciel (planètes, galaxies, amas globulaires, nébuleuses, etc) et d'en assurer le suivi.

Tout ceci fonctionne parfaitement.

La raquette permet également la focalisation (autrement dit : la mise au point) - comme sur un objectif d'appareil photo - de manière à obtenir une image nette.

Elle permet également la collimation, c'est à dire l'alignement optique du miroir parabolique - qui se trouve au fond du tube - et de la lame de fermeture (sorte de grosse lentille) qui se trouve à l'autre bout du tube.

Le miroir parabolique est fixe
Seule la lame de fermeture se déplace en avant ou en arrière pour permettre la focalisation.

Ces deux fonctions de focalisation et de collimation sont assurées par 3 petits moteurs solidaires d'un encodeur optique disposés à 120° au fond du tube et reliés a la lame de fermeture par 3 tiges filetées. (photo 1 et 2)01.jpg 02.jpg

La rotation simultané des 3 moteurs dans un sens ou un autre déplace la lame en avant ou en arrière pour permettre la focalisation.
Pour cela, les 3 moteurs doivent tourner exactement du même nombre de tours lorsqu'ils sont activés.

Par contre, la rotation d'un seul de l'un ou l'autre des 3 moteurs va incliner la lame de fermeture sur son axe optique, ce qui permet d'aligner avec précision cet axe avec l'axe optique du miroir parabolique qui, lui, est fixe : c'est la collimation.

La commande de ces 3 moteurs via la raquette ne fonctionne plus (un composant HS au niveau de la carte mère gérant toutes les fonctions : irréparable au dire du SAV Meade).
Et les encodeurs d'origine bas de gamme (photo 3) sont HS (testés).03.jpg
D'ou leur remplacement prévu par des encodeurs US DIGITAL, plus fiables (photo 4)04.jpg
Ce qui a été déjà réalisé par plusieurs possesseurs de cet instrument qui avaient des problèmes récurrents avec les encodeurs d'origine.
Pour cette action, une grande précision des encodeurs n'est pas nécessaire, chaque tour complet des moteurs ne déplaçant la lame de fermeture que d'une toute petite fraction de mm.

En résumé et pour faire court, le problème à résoudre est le suivant :

* 3 moteurs CC 5V

* chaque moteur est couplé à un encodeur optique US DIGITAL.

* les 3 moteurs alimentés pendant un temps T doivent avoir tourné exactement du même nombre de tours, dans un sens ou dans l'autre, sans qu'il soit besoin de connaître ce nombre de tours.

"...Il existe des cartes de pilotage de moteurs DC pour Arduino, précisément..."

Oui, plusieurs astronomes amateurs m'ont suggéré que la solution passait par l’utilisation d'un Arduino...

Je vais chercher de ce coté.

[jiherve]

bonjour
pour acquérir les encodeurs il faut au minimum 3 pins (6 si l'on veut la direction peu utile ici) et 6 pour la commande des moteurs avec 3 ponts en H c'est donc compatible avec un Arduino mais la question est : comment seront donc reçues les consignes provenant de la raquette?

La commande de ces 3 moteurs via la raquette ne fonctionne plus (un composant HS au niveau de la carte mère gérant toutes les fonctions : irréparable au dire du SAV Meade).

une petite photo du DCD serait la bienvenue.
JR

[A voir en vidéo sur Futura]

[michel2001]

Bonjour JR.

Merci pour votre réponse.

"...comment seront donc reçues les consignes provenant de la raquette?..."

Si vous parlez de la raquette de l'instrument, les nouveaux encodeurs (o4 jpg) et les moteurs ne seront plus du tout reliés à la carte-mère, et donc à cette raquette d'origine, qui continuera à gérer toutes les autres fonctions.

L'idée est de construire une autre mini-raquette indépendante avec quelques boutons poussoirs et quelques contacteurs, permettant de gérer la focalisation et la collimation (en récupérant le 5V pour les moteurs sur la carte mère d'origine ou en lui adjoignant une alimentation 5V séparée).

Qu'entendez vous par DCD ?

[Murayama]

Bonjour!

L'idée est de construire une autre mini-raquette indépendante avec quelques boutons
poussoirs et quelques contacteurs, permettant de gérer la focalisation et la collimation
(en récupérant le 5V pour les moteurs sur la carte mère d'origine ou en lui adjoignant
une alimentation 5V séparée).

Juste une idée au passage: à chaque fois que je veux un genre de panneau de commande
sur un appareil, au lieu d'utiliser un clavier, j'utilise une télécommande comme celle-ci.




Avantages: vous n'avez besoin que d'1 seul bit (donc strict minimum de soudure) sur un
GPIO d'arduino. Enfin j'imagine que ça peut fonctionner sur Arduino, mais je ne l'ai jamais fait.
Par contre, j'utilise principalement les circuits Texas (MSP430) quand il s'agit de petits
systèmes à très basse consommation, sinon ST cortex M7 ou H7 pour les application plus
complexes avec de l'imagerie. Et dans les 2 cas, ça marche très bien.
Pour le récepteur, j'utilise un Vishay TSOP 38338, C'est assez standard. 2 pattes alimentation,
une patte signal. Branchement sans se poser de questions.

Avantage: Quasiment sans effort, pas de montage dégueu qui tient avec du scotch, du fil
de fer et du mastic à vitres, beaucoup de fonctions possibles avec des flèches de
navigation + bouton de selection. Et même un pad numérique qui permet de programmer
un angle, par exemple.


Pascal

Désolé, je n'ai toujours pas trouvé la méthode pour n'avoir qu'une seule image "inline".

[jiherve]

bonjour
DCD = décédé.
C'est bien ton truc Murayama, il va falloir que j'en trouve en France, car souvent je recycle de petites télécommandes IR ce qui est toujours instructif en ce qui concerne le codage mais au final assez chiant car les constructeurs n'ont pas manqué d'imagination pour contourner les brevets ou s’assurer une clientèle captive.
JR

[Murayama]

Re!

La dernière fois que je suis passé en France, j'en ai vu. J'avais oublié la mienne pour faire
une démonstration. Heureusement que j'avais fait un système configurable.

mais au final assez chiant car les constructeurs n'ont pas manqué d'imagination pour contourner les brevets ou s’assurer une clientèle captive.

Pas si chiant que ça, parce que c'est toujours le même principe. J'en ai récupéré plein pour avoir un
maximum de données, toutes marques, tous appareils, air conditionné, téléviseur, etc...
Il y a en gros 2 types. Peut-être plus, mais dans tout ce que j'ai récupéré:

- Le niveau haut est le niveau codant. Point haut large = 1, point haut étroit = 0. Point bas à largeur fixe
- L'inverse de la première ligne.

Ensuite, il y a des télécommandes avec préfixe et sans préfixe, avec suffixe et sans suffixe, mais la configuration se
résume à quelques bits:

- Préfixe (ou pas)
- Suffixe (ou pas)
- Codage en haut
- Codage en bas

Je n'ai jamais vu de télécommandes avec le bit large qui veut dire 0 et le bit étroit qui veut dire 1, mais
dans mon analyseur, je l'ai tout de même introduit, on ne sait jamais. Par contre, ce n'est évidemment
pas testé.

Et enfin il y a la longueur du message, parfois 16 bits, parfois 32 on se demande bien pourquoi 32 bits,
peut-être pour avoir une telle redondance que les erreurs sont impossibles.
Il y a aussi de petites trames qui veulent dire répéter la dernière commande.

Bref, on a vite fait le tour. Et si on veut un système fixe, pas forcément adaptable à d'autres, c'est
assez simple à faire. Un analyseur, ce n'est pas bien compliquer, mais le tester prend du temps
avec un plein cageot de télécommandes.

Dernier point: la télécommande ci-dessus est assez petite, ce qui est bien pratique. 140 x 40 x 13,
et fonctionne avec une pile CR2032.

Pascal

[jiherve]

re,
J'ai une Hitachi qui utilise presque le protocole Nec ,presque, et là il faut un oscillo pour voir la différence!
bon pour revenir au sujet en effet avec une petite télécommande IR il devrait pouvoir commander ses moteurs, en assembleur sur un 328p ou même un Attiny 4313 cela tient à l'aise par contre en langage compilé Arduino je ne sais pas.
JR

[Murayama]

Bonjour!

Comme je suis au labo ce samedi, j'en profite pour vérifier le temps de réactivité
d'Arduino.

Matériel:
Arduino Mega 2560
Photodétecteur (avec démodulateur 38 kHz, TSO38338)
Oscilloscope

But: Savoir si Arduino est assez rapide pour détecter un signal de télécommande

Méthode: Détecter le signal de télécommande par interruptions, et le copier sur
un autre GPIO de l'Atmega.

Explication du source ci-dessous:
- J'utilise 2 pins, un pour le capteur TSO38338, et l'autre pour un pin quelconque
en sortie. Concrètement: pin 2 = acquisition de la sortie photosensor, pin 3 = sortie
GPIO. Les deux sont branchés à l'oscillo
- 2 fonctions d'interruption, donc 2 routines différentes, l'une quand on a un
front montant, l'autre quand on a un front descendant.
- Quand je reçois un front descendant, je mets la sortie (pin 3) à 0, et change
le front de détection pour front montant
- Le cas du front montant est symétrique, je change la sortie et je reconfigure pour
front descendant. La boucle loop ne fait donc rien

void setup() {
  // put your setup code here, to run once:
  pinMode(3, OUTPUT);
  attachInterrupt(digitalPinToInterrupt(2), IRUp, RISING);
}

void loop() {
  // put your main code here, to run repeatedly:
}

void IRUp(void) {
  digitalWrite(3, HIGH);
  //    We just had a rising edge, therefore have to configure the next edge to be falling.
  attachInterrupt(digitalPinToInterrupt(2), IRDown, FALLING);
}

void IRDown(void) {
  digitalWrite(3, LOW);
  //    We just had a falling edge, therefore have to configure the next edge to be rising.
  attachInterrupt(digitalPinToInterrupt(2), IRUp, RISING);
}

Résultats:
On voit qu'en considérant la forme générale, le système a l'air réactif. Au début
les 2 traces se chevauchaient et je ne voyais que la dernière écrite, donc ça a l'air
assez simultané à cette échelle là.

En agrandissant, on voit que le délai entre un front et sa réplication est de 9 µs.
C'est assez lent. Si le chip tourne à 16 MHz, ça voudrait dire 144 clocks pour
une simple interruption, ce qui est énorme.

Par curiosité, j'ai cherché sur le net le pinout de l'Atmega 2560, et j'ai trouvé
que les pins XTAL sont aux pattes 33 et 34. L'oscillo ne révèle aucun signal. À tout
hasard, comme les pattes 27 et 28 s'appellent TOSC1 et 2, OSC = peut-être oscillateur,
j'ai vérifié aussi. Pas de signal non plus. Par contre j'ai vu que Atmega a aussi une
horloge interne. Il est donc possibe que la configuration de défaut soit basée sur une
horloge à 1 MHz par exemple, ce qui signifierait que l'appel de la function d'interruption
et celui du changement de pin 3 prennent 9 clocks en tout, ce qui est rapide.


Ceci dit, je n'ai pas le temps de rechercher plus que ça, j'ai aussi un travail qui me
nourrit.

Quoi qu'il en soit, tous les signaux ont une durée de l'orde de 1ms, alors les 9µs de la
détection ne me semblent pas trop pénalisants, et à vue de nez on peut utiliser
Arduino pour lire une télécommande.

Suite à ce que je disais, vous voyez que pour cette télécommande:
- Le niveau codant est le niveau 1 (toutes les longueurs de niveaux pas sont identiques)
- Il y a un préfixe composé d'une partie d'environ 9 ms à 0 suivi d'environ 4 ms à 1,
avant de commencer la trame.
- La trame fait 32 bits.
- Le code correspondant à cette trame est 00001100 11110011 10001100 01110011, ou en
hexa 0C F3 8C 73. On peut remarquer que les bytes sont inversés 2 à 2, c'est à dire que
l'inverse de OC est F3 et l'inverse de 8C est 73. Probablement un système rudimentaire
de détection d'erreur.

Pascal

[jiherve]

bonjour,

Si le chip tourne à 16 MHz, ça voudrait dire 144 clocks pour une simple interruption, ce qui est énorme.

il faut bien payer le "haut niveau" quelque part !

un 328p programmé en assembleur se débrouille très bien pour acquérir un TSOP (désérialisation + interprétation du code), il peut en plus asservir en vitesse deux moteurs, dialoguer en i²C avec un autre proc et balancer des message UART de debug.
il faut juste utiliser le bon langage pour moi électronicien antédiluvien :µC petite puissance de calcul et taille mémoire limitée => assembleur

Le code Hitachi est très similaire mais ces petits futés inversent tous les bits sauf 1, le MSB.
JR

[Murayama]

Bonjour!

il faut bien payer le "haut niveau" quelque part !

Pas forcément. Comme expliqué plus haut, la carte que j'ai n'utilise pas le quartz, ce qui
veut dire que le processeur doit tourner avec son horloge interne de défaut. 1MHz, je crois.
Comme on a un délai de 9µs, ça fait disons 7 pour appeler la routine d'interruption et 2 pour
basculer le port au bon niveau, ce qui est tout à fait ordinaire. Ceci dit, je n'ai pas analysé
le système de manière très rigoureuse, il faudrait pour conclure être certain de l'horloge
effectivement utilisée. Le mieux serait aussi de faire le même programme en C avec
un environnement non-Arduino et C++ avec l'environnement Arduino. Si quelqu'un d'autre
a du temps pour une vraie analyse, ce serait intéressant.

On entend généralement dire que ASM est plus rapide que C qui est plus rapide que C++ et vu
que je me méfie toujours de ce dont je n'ai pas d'expérience directe, j'ai voulu savoir
(il y a pas mal de temps) exactement combien on perd en efficacité en utilisant un langage
autre qu'assembleur.

J'ai donc essayé sur MSP430 quelques petits programmes en 3 versions chacun. ASM, C, C++.
Essais réalisés sur MSP 430, compilateur IAR, et le C++ était le "extended embedded C++"
de IAR. Ah oui, une chose importante: les objets C++ étaient instanciés en statique. Avec
une allocation dynamique, il est fort possible que les performances changeraient un peu.
Mais bon, de l'allocation dynamique sur un petit microcontrolleur...

Les petits programmes étaient par exemple: allumer et éteindre une LED dans une boucle.
En affichant la sortie LED et l'horloge à l'oscilloscope, on peut vérifier exactement
combien de cycles sont nécessaires pour une opération quelconque.

Mes observations m'ont montré que sur des opérations classiques, boucle, assignation
avec =, if, etc... l'assembleur et le C ne montrent AUCUNE différence (au cycle d'horloge
près!!). Le C++, sur une boucle, nécessitait 1 cycle d'horloge supplémentaire, ce qui
est normal parce que l'adressage est moins direct. En C, on a par exemple toggle_led(),
la fonction est appelée directement, et en C++, on a MyLed.Toggle(), fonction appelée
par l'intermédiaire de l'objet. Alors, oui, on perd 1 clock pour l'appel de la fonction,
mais on gagne l'encapsulation qui est un niveau de sécurité. L'objet a ses propres
variables qui ne sont accessibles que par lui-même.

Bref, l'idée que ASM plus rapide que C me semble venir de l'époque héroïque des premiers
compilateurs, mais ne plus être vraiment d'actualité.

On peut d'ailleurs écrire du C++ en C, par exemple dans ce cas:

typedef struct LED {
    void (*Toggle)(void);
} LED;

et l'appeler par:

LED my_led;
my_led.Toggle();

Je ne serais pas surpris que dans ce cas la performance ne soit pas meilleure qu'en C++.

Et pour en revenir au sujet Arduino, je peux admettre que l'environnement le rende un
peu moins efficace, mais 10 ou 20 fois plus lent, c'est difficile à admettre pour du C++.
Il faudra que j'essaie un de ces jours.

Pascal

[Murayama]

Re!

Je viens de m'apercevoir que la fonction digitalWrite de Arduino est effectivement très lente.
Mais cela n'a rien à voir avec C++, mais plutôt avec une fonction programmée avec les pieds.
La raison (pure supposition) doit être la suivante:
Pour faire abstraction des différents ports et avoir une adressage linéaire de pin 1 à pin x,
les programmeurs ont dû faire un switch:

switch(pin_number){
case 1:
....
case n
}

et à chaque fois envoyer la commande correspondante.

En remplaçant digitalWrite par PortX |= PORT_BIT; et PortX &= ~PORT_BIT; on gagne en vitesse
de façon assez impressionnante. Je ferai de vraies mesures un de ces jours.
NB: pour les fonctions ci-dessus, chercher un schéma pour savoir quel port + quel bit correspondent
à quel pin.

Conclusion: Arduino _peut_ être rapide même dans son environnement, à condition d'être
méfiant vis à vis des librairies existantes et surtout de regarder ce que ça donne à l'oscillo.

Pascal

[aeroman00]

Hello !
Un article intéressant sur le sujet : https://www.best-microcontroller-pro...italwrite.html

[jiherve]

bonsoir,

PortX |= PORT_BIT; et PortX &= ~PORT_BIT

là aussi cela va dépendre de la façon dont c'est fait !
basiquement les Atmel ont deux instructions pour çà : SBI PORTx,BITy ou CBI PORTx,BITy il n'y a aucun RMW .
cela se corse si l'on veut basculer plusieurs pins en même temps là il faut passer par des RMW.
JR

[Murayama]

Bonjour!

là aussi cela va dépendre de la façon dont c'est fait !
basiquement les Atmel ont deux instructions pour çà : SBI PORTx,BITy ou CBI PORTx,BITy il n'y a aucun RMW .
cela se corse si l'on veut basculer plusieurs pins en même temps là il faut passer par des RMW.

Je ne suis pas certain de comprendre exactement votre argument, mais il me
semble bien qu'il n'y ait pas 36 manières d'opérer. Les essais ci-dessous sont
fait sur un Atmega 2560, il n'y a aucune garantie de fonctionnement pour les autres.
Ni pour celui-là d'ailleurs. Disons qu'il fonctionne de cette façon dans mon labo.

Si j'utilise le code suivant:

DDRA = 0xFF; // Mettre le port A en sortie
PORTA |= val; // Mettre tous les bits de val sur le port A
PORTA &= ~val; // Effacer tous les bits de val

J'ai utilisé dans une boucle infinie les lignes ci-dessus, en mettant les 8 bits du port
à 1 puis 0.

le gain est énorme.
Une période avec digitalWrite = 11µs.
Une période avec le code ci-dessus: 250 ns.
Ça n'a pas l'air de se corser vraiment puisque je bascule les 8 bits ensemble, RMW ou pas.
J'obtiens un rapport cyclique de 75% parce qu'il y a 2 fois le temps d'une assignation
puis le temps d'un branch ou jmp. Le plus peti intervall est de 66 ns, donc 16 MHz
qui est précisément la fréquence de l'Atmega2560.
On ne peut pas aller plus vite même en assembleur.

Ceci prouve 2 choses:
- Les libraries utilisées par Arduino (pour digitalWrite par exemple) sont très
inefficaces, mais elles gèrent probablement d'autres choses, on ne peut pas critiquer
négativement sans voir le code complet et comprendre précisément ce qui peut être avantageux.
- Si on s'abstrait de ces librairies, on a une efficacité incomparable, même en utilisant
l'environnement Arduino, et même l'assembleur ne pourrait pas aller plus vite.
Ceci dit, je n'ai testé qu'une boucle, il faudrait que je teste d'autres éléments.

Par contre: l'environnement Arduino n'a pas de debugger ou du moins je ne l'ai pas
trouvé. On peut y arriver avec des printf sur le port série comme au bon vieux temps,
mais si on fait des choses un peu plus complexes qu'allumer une LED, ça doit vite
devenir fastidieux.

Pascal

[jiherve]

bonjour,
ce que j'ai écrit c'est que les µC Atmel ont des instructions spécifiques permettant de manipuler les bits des ports I/O un par un sans recourir à des cycles ReadModifyWrite c'est le hard qui se charge de tout mais si l'on veux manipuler plusieurs bits alors il faut lire l’état du registre pilotant le port faire un "et" logique avec un masque isolant les bits visés et ensuite un "ou" pour mettre à un les bits devant l’être.
PORTA |= val <=> PORTA := (PORTA & ! mask(val)) | val
bien sur si la taille de val est celle du port alors on fera PORTA := val et il est probable que le compilo soit assez malin pour detecter ce cas et transformer PORTA |= val ou PORTA &= val en PORTA := val
moi je n'utilise que l'assembleur et un ATMEL studio4 collector!
JR

[jiherve]

ajout
PORTA |= val en assembleur cela donne
pour val < PORTA et val > 1 bit

si val est cste

in r16,PORTA
andi r16,mask
ori r16,val
out PORTA,r16

si val est une variable

in r16,PORTA
andi r16,mask
lds r17,val
or r16,r17
out PORTA,r16

pour val = PORTA
si val est cste

ldi r16,val
out PORTA,r16

si val est une variable

lds r16,val
out PORTA,r16

si val ne comporte qu'un bit de rang b

sbi PORTA,b mise à un
cbi PORTA,b mise à zero

on voit donc que ce qui semble être la même opération peut varier du simple au quintuple!
JR

[Gyrocompas]

Bonjour,
Simple réflexion, l'origine de la panne est-elle trouvée?

Les encodeurs utilisés sont identiques à ce qui se trouve dans la molette d'une souris, plot à fourche avec détection du sens et comptage, quasi increvable.
Envisager de reconstituer le programme, est, comment dire, énorme.

Commencer par le plus simple, rechercher ce qui est alimenté etc.
Il peut s'agir d'un connecteur oxydé, d'un fil coupé.
Un jour, j'avais repéré une étude complète des cartes d'un Meade.
Problème, la probabilité d'obtenir une réponse, impose la langue la plus utilisée, l'english.

[jiherve]

re
ce n'est pas vraiment une panne mais une modification lourde suite à panne, il n'y a plus beaucoup de nouvelles du PP aussi Pascal et moi causons!
JR

[Gyrocompas]

Rebonjour,
Exemple d'un modèle Meade plus ancien, qui doit avoir servi de base pour les suivants : http://www.lx200classic.com/docs.HTM