Discussion :

[Guesset]

Bonjour,

Il y a plusieurs éléments qui me semblent étranges :

• Pourquoi, dans les gestionnaires d'interruptions, écrire !digitalRead(mot[moteurA].rotEncPinA) == !digitalRead(mot[moteurA].rotEncPinB) il n'y a, à mon sens, aucun intérêt à mettre !.
• Pourquoi un capteur incrémente tandis que l'autre décrémente ? Câblage ?
• Calculer positionTours dans l'interruption, c'est faire une opération lourde (il n'y pas de division dans le CPU) et inutile dans 90% des cas (10/11). Si on veut garder cela dans l'interruption, il faudrait par exemple ajouter un positionPas0 utilisable ainsi : if( abs(mot[moteurA].positionPas - mot[moteurA].positionPas0) > 10) { mot[moteurA].positionTours += mot[moteurA].positionPas > mot[moteurA].positionPas0 ? 1: -1; mot[moteurA].positionPas0 = 0; }

La solution de régler les écarts à la fin marche avec des moteurs non contraints réciproquement. Mais elle ne semble pas adaptée s'il faut respecter une limite de différence (ce qui doit être le cas avec le télescope). Aussi j'ajouterais dans les interruptions un dif_AB = int8_t(moteurA].positionPas - mot[moteurB].positionPas & $FF) pour pouvoir corriger le tir au fil du processus sans se soucier d'arrêter les interruptions. Il faut espérer être capable de limiter l'écart à 127 pas. L'usage du PWM serait peut être pratique ? Une autre approche pourrait être de créer des auto-répétitions de touches par exemple tous le 1/10 s qui utiliseraient le processus de recalage prévu à la fin de commande.

That's all folks !

[Guesset]

Bonjour JPBbricole,

...Je verrais assez un remplacement des dits moteurs par des moteurs pas à pas...

C'est également ce que j'avais conclu en regardant le schéma de commande. Mais est-ce que les moteurs pas à pas s'intégreront mécaniquement dans le télescope ?

Salut

[jpbbricole]

Bonjour Guesset

Pourquoi, dans les gestionnaires d'interruptions, écrire !digitalRead(mot[moteurA].rotEncPinA) == !digitalRead(mot[moteurA].rotEncPinB) il n'y a, à mon sens, aucun intérêt à mettre

C'est même essentiel, ça permet de définir le sens de rotation donc incrémenter ou décrémenter!

Pourquoi un capteur incrémente tandis que l'autre décrémente ? Câblage ?

Les 2 capteurs sont traités de manière absolument identique dans void rotencAchangeHandling() respectivement void rotencBchangeHandling(), seul l'index du moteurs change (moteurA et moteurB).

Cordialement
jpbbricole

[Guesset]

Bonjour jpbbricole,

C'est même essentiel, ça permet de définir le sens de rotation donc incrémenter ou décrémenter!

Ce n'est pas le test qui m'interroge mais le "!" de négation logique devant chaque terme de l'égalité qui ne change rien (les arguments ayant le même type et une égalité reste une égalité).

Les 2 capteurs sont traités de manière absolument identique dans void rotencAchangeHandling() respectivement void rotencBchangeHandling(), seul l'index du moteurs change (moteurA et moteurB).

Le traitement est le même mais les incréments sont inversés dans la déclaration.

Salut

[jpbbricole]

Bonjour Guesset

Ce n'est pas le test qui m'interroge mais le "!" de négation logique devant chaque terme de l'égalité qui ne change rien (les arguments ayant le même type et une égalité reste une égalité).

Ca veut dire l'inverse de de l'état du port. c'est comme quand on veut inverser un port avec digitalWrite(13, !digitalRead(13));

Le traitement est le même mais les incréments sont inversés dans la déclaration.

Ah! OK, c'est le grand mystère de mes 2 moteurs identiques, leur câblage est absolument identique mais ne tournent pas dans le même sens... Un a une LED rouge, l'autre une verte???

Cordialement
jpbbricole

[Guesset]

Bonjour JPBbricole,

Ca veut dire l'inverse de de l'état du port. c'est comme quand on veut inverser un port avec digitalWrite(13, !digitalRead(13));

Je crois que je ne suis pas assez clair. Le problème est pourquoi inverser les deux termes dans ce cas précis ?

Si digitalRead(mot[moteurA].rotEncPinA) == digitalRead(mot[moteurA].rotEncPinB) leur correspondances logiques (via bool(digitalRead(mot[moteurA].rotEncPinA)...) sont également == et leurs inverses logiques (via "!") aussi. Autrement dit, on peut se passer de "!" car en l'occurrence, "!" est une bijection de (0, 1) vers (true, false).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Valeurs => Résultat   !Valeurs       => Résultat
0 == 0  => true       true  == true  => true     idem
0 == 1  => false      true  == false => false    idem
1 == 0  => false      false == true  => false    idem
1 == 1  => true       false == false => true     idem

Ceci étant, ça marche ce qui reste le principal.

Salut

[Jay M]

Ca dépend du temps de fonctionnement, dans ma configuration, avec des moteurs qui tournent vite, en 10 secondes, j'ai eu jusqu'à 100 pas de différence, j'ai 11 tics/tour. En plus, ces moteurs ne tournent pas à la même vitesse dans les 2 sens. Par exemple, si les 2 moteurs tournent CCW, j'ai beaucoup moins de décalage que les 2 en CW.

Effectivement c’est beaucoup. Une approche en PID pour conserver l’écart minime et ne pas le laisser dériver pourrait s’avérer intéressante

[michel2001]

Bonsoir à tous.

"un remplacement des dits moteurs par des moteurs pas à pas"

C'est absolument inenvisageable, pour moi en tous cas : il faudrait pour cela démonter entièrement la partie optique pour accéder aux tiges filetées fixées sur l'axe des moteurs.
Je ne me risquerai pas à faire cette manip.

Par ailleurs, je dois dire que le système conçu par Meade avec des moteurs CC fonctionne parfaitement (enfin, fonctionnait...) et avec une grande précision : on pouvait mémoriser plusieurs focalisations différentes en fonction de la configuration optique choisie (caméra, oculaire, barlow, réducteur de focale, etc).
Et pour la collimation, le réglage d'usine fait au laser était en mémoire : après avoir voulu améliorer la collimation plusieurs fois en croyant bêtement mieux faire que Meade, je me suis aperçu que je n'avais réussi qu'à la dérégler fortement.
Chaque fois il m'a suffit de faire un reset de la collimation et j'ai retrouvé un alignement parfait des optiques.

"Mais est-ce que les moteurs pas à pas s'intégreront mécaniquement dans le télescope ?"

J'ai la quasi-certitude que non, et je n'ai aucune idée de la manière dont les tiges filetées sont fixées sur les axes des moteurs : ça risquerait de devenir un sacré chantier !

[Jay M]

Autrement dit, on peut se passer de "!" car en l'occurrence, "!" est une bijection de (0, 1) vers (true, false).

Oui, c’est vrai
Cela dit l’optimiseur va virer les 2 négations donc c’est plus une lourdeur pour la lecture que pour le code généré.

[jpbbricole]

Bonjour

Ma "tournure" de phrase:

!digitalRead(mot[moteurA].rotEncPinA) == !digitalRead(mot[moteurA].rotEncPinB)

veut simplement dire rotencPinA et rotencPinB == LOW, d'où l'utilité des !
Sans les ! ça donne rotencPinA et rotencPinB == HIGH, ce qui ne m'arrange pas vu que le déclenchement de l'interruption se fait sur FALLING.


Cordialement
jpbbricole

[Guesset]

Bonjour,

...!digitalRead(mot[moteurA].rotEncPinA) == !digitalRead(mot[moteurA].rotEncPinB) veut simplement dire rotencPinA et rotencPinB == LOW, d'où l'utilité des ! Sans les ! ça donne rotencPinA et rotencPinB == HIGH, ce qui ne m'arrange pas vu que le déclenchement de l'interruption se fait sur FALLING.

Si c'est vraiment l'objectif, le code ne marche pas car ! s'applique à l'élément le plus proche ce qui donne ici l'équivalent de (!digitalRead(mot[moteurA].rotEncPinA)) == (!digitalRead(mot[moteurA].rotEncPinB)).

Le petit tableau proposé montre qu'il y a égalité si les deux sont à 0 ou à 1 car !1 == !1 comme !0 == !0.
Pour avoir le résultat souhaité, le plus direct est :

digitalRead(mot[moteurA].rotEncPinA) == 0 && digitalRead(mot[moteurA].rotEncPinB) == 0

Ou :

!digitalRead(mot[moteurA].rotEncPinA) && !digitalRead(mot[moteurA].rotEncPinB) si on aime les !

Et le plus efficace me semble :

(digitalRead(mot[moteurA].rotEncPinA) + digitalRead(mot[moteurA].rotEncPinB) == 0.

Heureusement on sait déjà que digitalRead(mot[moteurA].rotEncPinA) == 0 puisque c'est un FALLING sur mot[moteurA].rotEncPinA. Donc le code, avec ou sans les ! inutiles, ne risque pas de trouver une égalité !1 == !1 (ni bien sûr 1 == 1) puisque le premier terme ne peut être 1. Mais le test peut alors se simplifier :

digitalRead(mot[moteurA].rotEncPinB) == 0.

Qui devrait être plus efficace que :

!digitalRead(mot[moteurA].rotEncPinB).

Salut

[jpbbricole]

Bonjour Guesset

Heureusement on sait déjà que digitalRead(mot[moteurA].rotEncPinA) == 0 puisque c'est un FALLING sur mot[moteurA].rotEncPinA. Donc le code, avec ou sans les ! inutiles, ne risque pas de trouver une égalité !1 == !1 (ni bien sûr 1 == 1) puisque le premier terme ne peut être 1. Mais le test peut alors se simplifier :

digitalRead(mot[moteurA].rotEncPinB) == 0.

Qui devrait être plus efficace que :

!digitalRead(mot[moteurA].rotEncPinB).

Salut

Je me rends compte à quel point j'ai l'esprit tortueux!!
Je vais revoir ma copie.
Merci pour les remarques et analyses.

Cordialement
jpbbricole