comptage sur interruption (PICAXE 20M2)

[polor]

Bonjour à tous les amateurs de picaxe,
j'ai pour application le comptage des impulsions d'un encodeur pour faire du positionnement, 3600 impulsions/tr.
Pour le moment et suite à vos conseils, j'utilise le programme suivant:

[B]setfreq m4
main:	
count C.5, 5000, w0
serout B.1,N2400,(254,128,#w0)
goto main				; loop back to start[/B]

cela fonctionne très bien, seulement pdt l'instruction "COUNT" mon système est bloqué, alors j'essai de refaire la même fonction mais avec des interruptions:
[B]init: 
setint %00100000,%00100000,C	; interrupt when pinC.5 goes high
setfreq m4
main:	
serout B.1,N2400,(254,128,#w0)   'affichage
goto main				; loop back to start

interrupt:
if pinC.5=1 then interrupt	; loop here until the interrupt cleared
setint %00100000,%00100000,C	; re-activate interrupt
inc w0
return				; return from sub[/B]

et là ça coince... w0 n'enregistre pas toutes les impulsions et même très loin de cela...
le cablage reste identique, le fait de changer d'entrée n'apporte rien
Je pense donc que mon programme ne doit pas être correct
Parmi vous quelqu'un aurait-il rencontré cet aléa?
merci par avance de votre aide

 

[MGU]

Bonjour,

A première vue, le "if pinC.5...." est de trop
Placez le reset en dernière ligne, avant le return

MM

 

[BESQUEUT]

cela fonctionne très bien, seulement pdt l'instruction "COUNT" mon système est bloqué

Le problème, c'est aussi que pendant le serout, le Picaxe ne compte plus et donc perds des impulsions...

j'ai pour application le comptage des impulsions d'un encodeur pour faire du positionnement, 3600 impulsions/tr.

A priori, j'aurais tendance à penser qu'un Picaxe est trop lent pour compter des impulsions à la volée.
Mais pour être plus affirmatif, il faudrait connaitre la fréquence maximale envisagée (impulsions/mn), ou le nombre de tr/mn
Accessoirement, pour les applications de positionnement, il est fréquent d'avoir des impulsions dans les deux sens ! est ce le cas ?

De plus, il faut savoir que même si la fréquence était compatible avec le temps de traitement du Picaxe, certaines instructions sont bloquantes et si vous les utilisez, il est probable que des impulsions seront manquées. C'est d'ailleurs la raison pour laquelle le COUNT est bloquant...

Compte-tenu du prix, certains proposent d'utiliser plusieurs Picaxes pour contourner le problème. A mon sens, ceci ne fait que repousser le problème : le Pixaxe chargé de compter les impulsions ne pourra pas en même temps transmettre le résultat de ses comptages... En fonction de la fréquence visée, je verrais plutôt l'utilisation d'un circuit logique spécialisé, par exemple un CD4040, en amont du Picaxe. (astuce : si vous faites ce montage, ne jamais utiliser le reset, car vous pourriez perdre une impulsion entre la lecture du compteur et le reset...)

Pour ce qui est du code proposé : la remarque de MGU serait valable pour d'autres types de processeurs.
Toutefois, il me semble conforme à la documentation pour le cas très particulier des Picaxes, surtout pour des fréquences faibles.

Mon attention est plutôt attirée par la position du inc w0 :
- si une nouvelle interruption est en attente, elle sera déclenchée dès le setint, donc avant le inc...
J'aurais tendance à permuter ces deux instructions.
Ceci peut améliorer les choses, mais si on en est là, c'est que le temps de traitement de l'interruption est trop long par rapport à la fréquence envisagée, et donc ce type de programme est voué à l'échec.

 

[PieM]

Le if then ... est nécessaire, car l'interruption ne se fait pas sur le front montant mais sur l'état de l'entrée.

Il est nécessaire aussi de mettre la réactivation de l'interruption juste avant le return, en effet.

- si une nouvelle interruption est en attente, elle sera déclenchée dès le setint, donc avant le inc...
J'aurais tendance à permuter ces deux instructions.

tout à fait d'accord.

Mais :
En fait je ne comprends pas trop le problème, hormis comme déjà dit, les infos manquantes de fréquence de comptage et de savoir si la mesure doit être permanente ou pas.

Si c'est un problème de positionnement, cela veut dire que l'on positionne quelque chose en fonction d'une consigne. Hors dans le cas d'utilisation de COUNT, on mesure une fréquence, et dans le cas de l'utilisation de l'interruption, on mesure un nombre d'impulsions sans comparaison à une valeur de consigne ...

En outre comme le fait remarquer Besqueut un codeur incrémental délivre en principe deux signaux en quadrature pour savoir dans quel sens on tourne, plus un zéro.
Je suis donc perplexe sur le but poursuivi.

En fonction de l'objectif et si c'est un problème de comptage pur, la seule solution serait d'utiliser le comptage externe, qui n'est possible que sur les 28x. et 40X.

 

[polor]

merci de vos réponses
le "if" est bien nécessaire car sinon, le programme tourne en boucle et l'incrémentation se fait automatiquement, grâce au "IF", elle se fait lors du changement d'état sur l'entrée.
la rotation est d'environ 1tr/min et il y a bien 2 signaux déphasés pour différencier 2 sens de rotation + 1 zéro. L'identification du sens de rotation, je le garde pour la suite, mais si vous avez de l'expérience sur le sujet je suis intéressé.
Par ailleurs, j'ai bien permuté le setint et le inc, une amélioration mais loin du compte.
Autrement, effectivement à terme il y aura une comparaison avec une consigne pour positionner l'ensemble, mais pour le moment, je me concentre sur le comptage qui me pose des soucis. J'y vais à mon rithme et étape par étape.
@ Piem
dois-je comprendre qu'avec un 28X, le comptage pourrait fonctionner?

@besqueut
"Le problème, c'est aussi que pendant le serout, le Picaxe ne compte plus et donc perds des impulsions..."
ceci est-il vrai malgré les interruptions?

 

[BESQUEUT]

"Le problème, c'est aussi que pendant le serout, le Picaxe ne compte plus et donc perds des impulsions..."
ceci est-il vrai malgré les interruptions?

Hélas OUI !
Voir Annexe 4, page 267 du tome 2 du manuel.
Le problème est lié au fonctionnement de l'interpréteur qui fait semblant d'être multitâches sans l'être vraiment.
Avec seulement 60 impulsions/s, je suis un peu étonné que l'on rate des impulsions, mais les faits sont têtus...
En tout cas, il semble bien que la modification ait comme prévu amélioré les choses sans résoudre le problème.
je comprends votre démarche "par étapes" que j'adopte souvent.
Dans le cas précis, elle risque de vous conduire à une impasse :
- par exemple, l'utilisation d'un compteur externe permettrait un comptage très fiable, mais pas le décodage du sens de marche !
A part l'utilisation d'un µProc compilé, je ne vois pas de solution, mais d'autres auront sans doute des idées maintenant que les données du problème sont plus précises.
Voir :
http://jleguen.info/robotik/elec/Capteurs_en_quadrature.pdf
Comme je travaille actuellement sur un xMega128, je ne résiste pas à la tentation de citer ce document :
http://www.atmel.com/Images/doc8109.pdf
Si vous arrivez à mettre la main sur la bête, il y a aussi ça :
http://www.avagotech.com/pages/en/motion_control_encoder_products/integrated_circuits/decoder_ic/hctl-2022/
Et pour finir, une solution écolo : recycler une ancienne souris à boule qui contient tout ce qu'il faut avec sortie soit en PS/2 soit en série...

 

[polor]

dans ce cas, est-ce que la solution ne consisterai pas à utiliser l'afficheur en mode "parallèle" plutôt qu'en mode "sériel"?

 

[BESQUEUT]

dans ce cas, est-ce que la solution ne consisterai pas à utiliser l'afficheur en mode "parallèle" plutôt qu'en mode "sériel"?

Euh ????
Il y a un afficheur ? pour indiquer la position courante du bidule I suppose ?
Peut-être pourriez vous donner un schéma complet du montage...
En tout cas, liaison série ou //, vous perdrez des impulsions et vous ne pourrez pas déterminer le sens de rotation.
Si c'est à titre expérimental et/ou pédagogique, il faudra ralentir la rotation (je dirais au moins 60 fois moins vite...)
Dans le cas contraire, suivez une des pistes citées en #6.

 

[PieM]

Faire abstraction des procédures futures, sens de comptage et comparaison avec une consigne, est voué à l'échec, puisque le problème qui se pose est un problème de timing.
A quoi bon savoir compter des impulsions si vous ajoutez après des lignes de programme qui vont tout perturber....

La première question à se poser, si vous faites du positionnement , c'est: est-il nécessaire d'avoir de l'affichage temps réel de la valeur du codeur ?
Votre serout demande plus de 10ms pour s'exécuter, sans compter les autres instructions. Ne soyez donc pas étonné de passer à coté d'impulsions qui surviennent toutes les 16ms.
Pourquoi rester avec une fréquence de 4 MHz, (bien que ça ne change rien au niveau du serout) ?

Vouloir traiter sérieusement le décodage d'un décodeur par soft sur un picaxe est rédhibitoire à cette fréquence.
chaque changement d'état doit être l'objet de 12 tests état lu par rapport à l'état précédent.
Il faut ensuite comparer la valeur cumulée à la consigne ...

L'interface type HCTL 2016 ou 2020 peut solutionner une partie du problème mais je ne pense pas que cela résolve tout.

 

[PapyJP]

...Vouloir traiter sérieusement le décodage d'un décodeur par soft sur un picaxe est rédhibitoire à cette fréquence....

PieM a raison,
ce Pb se traite facilement avec quelques chips externes surveillés par un Picaxe.
Pour le comptage des impulsions, vous avez l' embarras du choix, même des compteurs-décompteurs ( le choix fait, il vous reste l' embarras ( Coluche )).
Pour le sens de rotation ( et donc de comptage ), une simple bascule JK suffit.
Soit A et B les signaux ( déphasés ) délivrés par le codeur.
Vous câblez A sur l' entrée J, B sur l' entrée CLK, vous câblez K à la masse.
Si A passe à 1 avant B alors Q=1
Si B passe à 1 avant A alors Q=0
cqfd

 

[BESQUEUT]

L'interface type HCTL 2016 ou 2020 peut solutionner une partie du problème mais je ne pense pas que cela résolve tout.

Le HCTL2022 est un compteur sur 32 bits ce qui laisse de la marge... Il suffit de lire la position, tout le reste est géré, y compris des subtilités pas croyables...
En prime (si on le souhaite...) ça améliore la résolution en tenant compte du déphasage des capteurs.
Je ne vois pas ce qui pourrait manquer à notre ami, mais fo trouver la bête...
La solution PapyJP me plait bien, mais il faut lire Q à la vitesse de CLK, ce qui ramène au même problème si on le fait avec le Picaxe. Il faudrait utiliser ce signal pour passer de comptage à décomptage automatiquement. Accessoirement, un compteur sur 8 bits est tout juste suffisant pour laisser le temps au Picaxe de lire la position avant le rollover.
Ce serait mieux avec au moins un 12bits, genre CD4040. Mais il ne fait pas décompteur. On pourrait s'en sortir en en mettant 2 et en faisant la soustraction avec le Picaxe, mais ça complique...

 

[PieM]

Je ne vois pas ce qui pourrait manquer à notre ami, mais fo trouver la bête...

Quoi que l'on fasse, il faut bien lire toutes les 16ms l'état du compteur, le comparer à quelque chose , agir sur quelque chose, et afficher (?). Voilà pourquoi je dis que ce n'est pas gagné.
Et s'il y a un SERIN et un GOSUB, c'est sans espoir !


S'il ne s'agissait uniquement que de compter en + ou en - , cela pourrait presque se faire avec un 28X2 à 32 MHz en comptage externe, plus la bascule JK de PapyJP ( ) mais il faut pouvoir utiliser cette info donc la lire à 60Hz en faisant autre chose.

 

[BESQUEUT]

Quoi que l'on fasse, il faut bien lire toutes les 16ms l'état du compteur, le comparer à quelque chose , agir sur quelque chose, et afficher (?).

Nan, nan... (en tout cas pas avec le HCTM2022)
La bête présente sur ses sorties // le compteur (par paquets de 8 bits) tout en continuant à compter (et décompter).
Mettons qu'au départ le compteur est à zéro...
Au bout d'un moment, il vaut 2743.
Le Picaxe prends son temps pour lire (4 x 8 bits,...) c'est pas grave : le compteur continue à tourner !
Peut-être qu'à la fin de la lecture le compteur est à 2722, ce qui fait une différence entre la position exacte et l'affichage, ce qui est inévitable tant que le montage est en mouvement.
Mais en aucun cas la position n'est perdue. Dès que le mouvement cesse, l'affichage est correct.
Mais me direz vous (car vous aimez aller au fond des choses...) comment lire 4 fois 8 bits en sachant que le compteur continue à tourner ? Et bien c'est prévu : le compteur peut être copié dans une mémoire (Latch) pour laisser tout le temps au Picaxe de lire 4 fois 8 bits sans que cette copie change.
Tant qu'il n'y a pas de rollover, le compteur est une image fidèle de la position de l'objet en mouvement. Et avec 4 294 967 000 impulsions, ça laisse de la marge...
C'est la même chose avec les compteurs façon PapyJP. Avec un compteur sur 8 bits, on a 256 fois plus de temps pour relever le ou les compteur(s), soit 1/2 seconde environ. Ça parait jouable. Bien sur (comme indiqué en #3) il ne faut pas utiliser le reset, sinon on risque de perdre des impulsions entre la lecture du compteur et le reset. Le compteur va donc passer en rollover à un moment ou a un autre, et il va falloir gérer (en gros on relève le compteur plus souvent, disons au moins 4 fois par seconde, et on ajoute 256 chaque fois quela valeur lue est inférieure à la précédente). D'où l’intérêt d'un compteur sur 32 bits...
Sinon, il a le xMega (30€ avec tout ce qui va bien pour programmer, y compris en BASIC) mais là je vais me faire des ennemis sur ce forum...

 

[PapyJP]

Manifestement on est un peu juste en temps !
Voici une solution peu onéreuse qui permet de travailler à une fréquence plus faible, au détriment de la résolution du codeur ( voir ci-dessous ).
Avec le signal Q de la bascule " sens " ( #10 ), on aiguille les impulsions à compter vers les entrées CountUP OU CountDown d' un 74193.
Celui-ci est un compteur-décompteur modulo N ( Pour cela la sortie TC est ramenée à l' entrée PLbarre, MR est à la masse ).
N est fixé par les états de P0 à P3.
Supposons N=5 ( P0=1, P1=0, P2=1, P3=0 ). Nous aurons alors Q2=1 pendant deux cycles d' horloge mais la fréquence d' entrée est divisée par 5.
Tout autre facteur de division est possible en Réglant N par les Px.
La résolution du codeur est donc divisée par N, Est-ce acceptable par Polor ?

 

[BESQUEUT]

La résolution du codeur est donc divisée par N, Est-ce acceptable par Polor ?

Pas d'accord : c'est au contraire une bonne solution (mais il faut un circuit de plus pour faire l'aiguillage...)
Le 74193 est un compteur/décompteur sur 4 bits. Donc on a 16 fois plus de temps pour relever le compteur tout en conservant la résolution ! (Il ne faut pas utiliser le Preset : même explication qu'avec le Reset ci-dessus...)
Disons tous les 1/10 s en tenant compte du rollover.
Si c'est trop juste, ce circuit est cascadable : on doit donc pouvoir compter sur 8 bits avec 2 circuits, voire 12 bits avec 3...

 

[PapyJP]

Il me semble pourtant que, dans mon exemple, le Picaxe n' est averti que pour un changement de +/- 5 impulsions codeur ?
Me trompe-je ?

 

[PieM]

Peut-être qu'à la fin de la lecture le compteur est à 2722, ce qui fait une différence entre la position exacte et l'affichage, ce qui est inévitable tant que le montage est en mouvement.
Mais en aucun cas la position n'est perdue.

Encore une fois si on fait du positionnement il faut que l'on lise la position exacte en temps réél!
A quoi sert d'avoir un compteur qui continue à s'incrémenter pendant un déplacement si on a déjà dépassé la valeur de consigne !
En asservissement avec un tel principe, on passe son temps à courir après une une consigne avec des allers retours .

Dès que le mouvement cesse, l'affichage est correct.

oui et qu'est ce qui fait arrêter le mouvement ?

Moi j'ai compris (?) qu'il s'agissait depuis le début d'un problème de positionnement. Si on se positionne, c'est par rapport à quelque chose non ? Sinon, ce n'est pas du positionnement c'est de la mesure.

Ensuite, si on change les données du problème, à savoir la résolution du codeur, il n'est à la limite plus besoin de circuits externes de comptage ...

 

[PapyJP]

On peut faire bien des choses avec un codeur incrémental rotatif:
--- De la mesure : vitesse de rotation, sens, positionnement angulaire, rotation angulaire, ...
--- De l' asservissement : de vitesse, de positionnement angulaire, de déplacement angulaire, ...

Polor peut-il préciser son Pb ?

Ca nous éviterait de phosphorer dans l' inconnu .
Nous pourrions proposer, ou pas, des solutions adaptées à son Pb qui tiennent la route.
Tiens, à propos de route, il y a plein de capteurs digitaux sur nos voitures:
- Pour la mesure: rotatifs ( compteur de vitesse, ...) et linéaires ( jauge à essence, ...)
- Pour l' asservissement : régulateur de vitesse

 

[PapyJP]

.. Moi j'ai compris qu'il s'agissait depuis le début d'un problème de positionnement...

.
En effet, PieM, j' ai relu avec plus d' attention le post de Polor; Il parle bien de positionnement ! j' avais zappé un peu vite.

Ceci-dit, il serait interessant d' avoir des précisions de sa part.
Calage au départ, critères de bon positionnement, vitesse d' approche variable, corrections d' impulsions perdues, recalage aprés chaque positionnement, présence de butées, de fin de course, ...
Si tout est basé sur le comptage-décomptage d' impulsions, le 2022 ( ou équivalent ) de Besqueut s' impose à la condition d' avoir une vitesse d' approche variable ( en fonction du nombre d' impulsions restant à compter ).
Et à la condition expresse de ne pas avoir de jeu mécanique ( hystérésis ) au changement de sens.

 

[polor]

D'après ce que j'ai pu lire, l'opération de comptage semble compromise avec un picaxe.
dans l'idée, le serout servait à afficher l'état du compteur en réel, je pensais ainsi pouvoir m'assurer que le comptage fonctionnait correctement, la suite vous la connaissée. Je vais donc faire des essais mais sans serout car j'étais convaincu que les "interrupt" n'étaient pas influencé par les serout jusqu'à ce post.
Autrement, pour en revenir sur l'application, en gros, il y a un switch qui détecte la position initiale qui correspond à la butée mécanique, c'est la raz du compteur, ensuite, en fonction de la consigne, une vis sans fin vient se positionner conformément à la consigne.
Toujours dans l'idée, je tente de trouver une solution avec les composants que je dispose, j'entends bien qu'il est possible de faire mieux avec d'autres composants, mais d'abord, avec ce qui est à ma disposition.
Quand je vois les difficultés pour réaliser un comptage, je me dis que j'ai bien fais de ne pas me lancer à corps perdu dans la détection de sens de rotation, décomptage... comme évoqué, j'y vais à mon rythme.
Dans l'ensemble, cela me semble compromis mais j'ai noté qu'une des pistes serait de diminuer le nbre de pulsations par tour, je pensais donc utiliser une bascule (ou deux) pour diviser les pulsations par tour par 2 ou 4 selon le fonctionnement obtenu.
dans une 2e phase, Je vais également étudier le 2022.

 

[PieM]

D'après ce que j'ai pu lire, l'opération de comptage semble compromise avec un picaxe.

Si on fait du comptage avec contrôle de sens et test de coincidence de compteur avec un 20M2 à 4 MHz, c'est certain!
Par contre un comptage pur sera réalisable à condition de ne rien faire d'autre, c'est toujours le même problème.

Après si vous utilisez un 28X2 à 32 ou 64 MHz, c'est différent .
Un comptage pur peut se faire jusqu'à plus de 10MHz sur certains Picaxes !

Le problème est de savoir si vous essayez de faire quelque chose avec ce que vous avez, ou si vous voulez choisir le matériel en fonction du problème.
Problème que j'ai d'ailleurs du mal à comprendre, car vous parlez d'une vis sans fin. A quoi qui serait lié à votre codeur ?

Cette vis est entraînée par un moteur électrique classique ? Si c'est oui, il est évident que vous n'y arriverez pas de cette façon. Un tel système nécessite de ralentir le moteur avant d'arriver au point de consigne.
Et à quoi bon faire de la détection de sens si vous connaissez dès le départ le sens de rotation de votre système!

J'ai la vague impression que la solution à votre problème est dans l'utilisation d'un moteur pas à pas !