Aide Butée positionnement pour SCIE PANNEAU sur base arduino et codeur incremental ?

[jujujuju2004]

Petit retour, je viens de tester le programme, il fonctionne un tout petit peu mieux en terme de pas perdu, mais il y en a toujours je pense que ça doit venir de l'arduino, je pense aussi qu'on ne pourra pas avoir de meilleurs résultat, j'essayerais prochainement de changer l'arduino et de la migrer vers un arduino officiel.

Jules

 

[tronix]

Bonsoir,

pour bien déterminer la cause de ces problèmes, un coup d'oeil à l'oscilloscope peut être utile (forme et niveaux). Des condensateurs peuvent aussi aider à supprimer certains parasites, l'oscilloscope permet alors de bien déterminer la valeur maximale qui ne déforme pas trop les flancs et laisse passer la fréquence maximale voulue. Ensuite, des tests avec un générateur arbitraire permettent de valider le bon comptage, en générant une fréquence bien précise ou même un nombre déterminé de pas.
Il reste que les librairies Arduino, de ce que j'en ai vu, sont souvent très mal optimisées (si on peut dire...) pour faire des actions rapides, et écroulent très vite le processeur. Les fonctions Delay ne devraient jamais être utilisées. Si on ne peut pas finir une action en raison d'un signal externe non établi, il faut y revenir plus tard mais ne pas bloquer le processeur. Le problème de performance insuffisante sur le codeur peut donc venir d'une autre fonction, n'ayant rien à voir, mais qui bloque tout trop longtemps. Les interruptions peuvent régler le temps de réponse, mais si le processeur est déjà à 100%, cela ne réglera pas tout.

 

[jpbbricole]

Bonjour tronix et bonne nouvelle année à tous

un coup d'oeil à l'oscilloscope peut être utile (forme et niveaux).

Tu m'enlèves les mots de la bouche, c'est exactement ce qu je voyais comme suite.

Il reste que les librairies Arduino, de ce que j'en ai vu, sont souvent très mal optimisées

Jusqu'à il y a peu je décodais la quadrature "à la main" pensant être plus rapide et efficace, ensuite j'ai essayé, toujours en manuel mais avec digitalWriteFast.h, c'était un peu mieux pour terminer avec la librairie Encoder.h avec toujours un petit plus en mieux.

Il reste que les librairies Arduino, de ce que j'en ai vu, sont souvent très mal optimisées (si on peut dire...)

A mon niveau, difficile de juger donc je prends ce qui est le plus couramment utilisé

Je vais faire un générateur en quadrature pour faire des test de lecture calibrés pour vérifier le comptage.


Cordialement
jpbbricole

 

[cr-_-]

Bonjour,

Pour tester avec les moyens du bords le décodage je mets un fréquencemètre (multimetre) sur une des voies et j'alimente avec une alimentation variable. En jouant du chronomètre et du comptage de pas coté microcontroleur, j'arrive à estimer quand ça décroche

Avec l'arduino de mémoire je ne suis pas arrivé à faire mieux qu'une mesure de 50khz du coup j'avais besoin de plus et je suis passé sur du stm32 avec compteur hardware

 

[vres]

Mon petit code pour la lecture des codeurs.
La lecture est faite sur une interruption timer avec un encodage des 16 possibilités entre 2 lectures du codeur.
Le timer est à environ 40kHz.

Vous devez être connecté pour voir ce contenu.

 

[tronix]

Pour estimer les performances, c'est assez simple, il suffit d'utiliser une IO, de la mettre à 1 à l'entrée de la fonction et de la remettre à 0 à la sortie, par exemple. A l'oscilloscope, cela permet alors de mesurer le temps d'exécution et de voir si c'est acceptable ou non. Ou de voir quand ça décroche.
J'utilise beaucoup des PIC32 (32bits) avec horloge entre 80 et 200MHz (1 cycle = 1 instruction la plupart du temps) et j'évite les interruptions au delà de 10kHz car j'estime que cela devient vite pénalisant. Mais en utilisant bien les interruptions, les périphériques, en DMA dès que possible, on peut faire des choses monstrueuses, que je pensais réservées aux fpga. Ceci dit, je n'ai pas fait de soft pour un codeur incrémental, et je ne vois pas immédiatement comment faire une bête de course avec mes processeurs habituels. Dans d'autres marques, certains processeurs ont ce qu'il faut, mais pas sur PIC32. J'ai bien fait une carte il y a quelques années avec un encodeur, mais j'ai utilisé la solution de facilité du FPGA couplé au processeur, et qui faisait un tas d'interfaces. Là, la limitation sera bien au delà des vitesses permises par la machine. Mais un peu moins abordable pour l'amateur, même si un petit FPGA ne coûte que quelques euros.

 

[tronix]

A la réflexion, si on déclenche une interruption par front, soit 2400 interruptions par tour pour un encodeur 600 pas par tour, et si la quantité de traitements annexes n'est pas monstrueuse, on doit pouvoir atteindre des fréquences respectables, et donc des vitesses de rotation correctes.
Quelle est la vitesse maximale de rotation du codeur sur la machine, je n'ai pas trouvé en relisant rapidement tout le sujet ?

 

[jpbbricole]

Bonjour

J'ai fais un test pour contrôler la bonne marche du programme, version USIN_ButeeScieRotEncC.ino dans un Nano, Je me suis fait un générateur en quadrature et j'ai pu monter jusqu'à 10kHz ce qui correspond à environ 250 t/Min pour le codeur.
Je pense qu'il faudrait contrôler, à l'oscillo, la qualité des signaux reçus.

Cordialement
jpbbricole

 

[vibram]

Bonjour

J'ai fais un test pour contrôler la bonne marche du programme, version USIN_ButeeScieRotEncC.ino dans un Nano, Je me suis fait un générateur en quadrature et j'ai pu monter jusqu'à 10kHz ce qui correspond à environ 250 t/Min pour le codeur.
Je pense qu'il faudrait contrôler, à l'oscillo, la qualité des signaux reçus.

Cordialement
jpbbricole

Salut jpb,
je crois qu'il faut convertir en distance pour l'application ici non ? je survole de tres loin le sujet mais je ne crois pas qu'ils aient mentionné de vitesse ou tr/min mais le plus simple serait de savoir à combien de mm/sec ils peuvent aller.

Apres selon la complexité du code, tu peux peut etre mettre ca sur un stm32 en le faisant tourner sur stm32duino ? le portage devrait etre très rapide et tu augmentes sensiblement la performance

 

[dubois]

Bonjour a tous ,
Meilleurs voeux a tous et merci pour votre aide !
La partie pg est sous traité à mon fiston qui est encore dans les bras de Morphée, vacance oblige !! ah ces jeunes !!
En vitesse il faut que je regarde approximativement combien de tours minute environ ,on a fait de multiples essais et a priori cest clairement un pb de vitesse ,jai mal centré mon usinage de poulie codeur également ce qui induit un leger point dur donc peut etre une accélération trop importante a un moment donné quand ça force .
Je vait regarder tous ça.
Bonne journée a tous.

 

[jpbbricole]

Salut vibram

je crois qu'il faut convertir en distance pour l'application ici non ?

Oui, bien sûre, le t/Min c'est pour donner une idée de la vitesse possible, mais les test sont faits avec l'application et donc les conversions.
Ça permettra, aussi, s'il y a mesure avec un oscillo, de comparer avec les vitesses utilisées.

Apres selon la complexité du code, tu peux peut etre mettre ca sur un stm32

Je viens d'en commander avec bootloader Arduino, pour le portage, je pense que je te contacterai

Meilleurs voeux a tous et merci pour votre aide !

Meilleurs voeux à toi, aussi et... au boulot!!!

Cordialement
jpbbricole

 

[vres]

Personne ne veux de mon code pour codeur pourtant il est très fiable, très rapide et très simple.

 

[cr-_-]

Bonjour,
je confirme pour l'avoir relu à part coder en assembleur pour optimiser encore, on ne peut pas espérer mieux

 

[jpbbricole]

Bonjour CNCSERV

Personne ne veux de mon code pour codeur pourtant il est très fiable, très rapide et très simple.

Je suis entrain de l'essayer.

Cordialement
jpbbricole

 

[jpbbricole]

Bonsoir CNCSERV

et très simple

Oui, mais pour moi, qui n'a jamais fais de C... (Arduino étant quand même du C "adouci")
J'en ai compris une partie, mais j'ai 2 questions, comment sais t on dans quel sens on va et pourquoi il y a 16 occurrences dans le tableau table_cod[16]=
Merci par avance.

Cordialement
jpbbricole

 

[tronix]

Bonsoir,

je viens de regarder rapidement le code par curiosité, et j'avoue que bien que programmant presque tous les jours en C, je n'ai pas compris car le peu de commentaire qu'il y a n'aide pas vraiment !

 

[vres]

Sur le codeur on a deux signaux donc 2 bits, donc 4 possibilités:

A = 0; B =0 -> 0
A = 0 ; B = 1 ->2
A= 1 ; B = 1 -> 3
A= 1; B = 0 -> 1

Pour avoir les 16 possibilités on décale la lecture précédente de 2 bits.

Si sur la position actuelle on a 3 et que sur la position précédente on a 1 il faut ajouter -1. :
->Pour notre table: 1<<2 + 3 = 7; dans notre table à la position 7 on a -1;

Si sur la position actuelle on a 3 et que sur la position précédente on a 2 il faut ajouter 1. :
->Pour notre table: 2<<2 + 3 = 11; dans notre table à la position 11 on a 1;

Si sur la position actuelle on a 0 et que sur la position précédente on a 2 il faut ajouter -1. :
->Pour notre table: 2<<2 + 0 = 8 ; dans notre table à la position 8 on a -1;

sur la position actuelle on a 3 et que sur la position précédente on a 3 il faut ajouter 0. :
->Pour notre table: 3<<2 + 3 = 15 ; dans notre table à la position 15 on a 0;

Pour les 2 et -2 normalement ça ne doit pas arriver.

L'avantage de ce code c'est qu'il est beaucoup moins sensible au parasites qu'une entrée d'interruption.

int8_t table_cod[16]={0,-1,1,2,1,0,-2,-1,-1,-2,0,1,-2,1,-1,0};

je confirme pour l'avoir relu à part coder en assembleur pour optimiser encore, on ne peut pas espérer mieux

A l'origine c'était en assembleur pour ma carte DSP.

je viens de regarder rapidement le code par curiosité, et j'avoue que bien que programmant presque tous les jours en C, je n'ai pas compris car le peu de commentaire qu'il y a n'aide pas vraiment !

Je suis désolé, j'ai refait le code rapidement pour Arduino hier soir en le testant en réel. ne n'ai pas trop eu le temps pour les commentaires.
J'espère que les explications ci-dessus aiderons à comprendre le principe.

 

[usitour]

Bonsoir

J'espère que les explications ci-dessus aiderons à comprendre le principe.

Merci.
Est ce que le fait de traiter les signaux A et B avec un tampon trigger et une bascule flip flop, pour sortir un signal compteur et
une sortie direction, améliorerais la rapidité du programme.

Cdlt

 

[tronix]

Avec les explications, cela va mieux ! D'ailleurs, ne pas hésiter à les mettre intégralement dans fichier source.
/***
* bla
* bla
* bla
*****/

C'est simple et logique, et en effet moins sensible aux parasites. En revanche, c'est plus pénalisant car le timer génère toujours des interruptions qui doivent être sensiblement plus rapides que la fréquence de l'encodeur.
J'ai vu que certains processeurs (PIC24 et dsPic33) avaient des interfaces adaptées justement faites pour s'immuniser des parasites. Dommage que ce ne soit pas plus répandu.
L'optimisation d'un programme vient surtout de son écriture, de l'algorithme choisi, et aujourd'hui, sauf cas particuliers, inutile d'écrire en assembleur, le compilateur fera aussi bien, voire mieux.
Table dans la doc dsPic33, on retrouve le même principe :

 

[cr-_-]

Bonjour,
le timer peut être moins rapide que le signal grâce au +-2 avec une assomption sur la direction (mais il est peut probable d'avoir un changement de direction aussi rapide) en espérant ne pas avoir de parasites

pour l'assembleur sur des zones très critiques je n'ai pas encore été surpassé par le compilateur en particulier par le fait que je peux faire des optimisations contextuelles pour lesquelles il n'est pas compétent. Par exemple stocker 10 variables dans un registre qui du coup n'ont pas besoin d'être chargées depuis le cache on économise 1 à 2 cycles d'horloge par variable, ça peut être dimensionnant dans certaines zones

par contre en temps normal les compilateurs fonts très bien leurs tafs mais quand il faut faire rentrer des choses au chausse pied on sort l'artillerie mais c'est sur des périmètres très limité et ça doit le rester. Maintenir un gros programme en assembleur est un cauchemar

Bonsoir


Merci.
Est ce que le fait de traiter les signaux A et B avec un tampon trigger et une bascule flip flop, pour sortir un signal compteur et
une sortie direction, améliorerais la rapidité du programme.

Cdlt

Oui car dans ce cas tu peux utiliser les périphériques de comptage de l'avr (une broche pour la direction sur interruption qui configure le périphérique de comptage et l'autre en entrée du compteur) une boucle périodique pour vider le compteur . Par contre si tu as un périphérique décodeur en quadrature comme sur un stm32 par exemple ça ne changera pas grand chose

 

[vres]

en ,assembleur ça donnait ça sur le TMS32C31:

Vous devez être connecté pour voir ce contenu.

J'utilise ce code pour des codeurs relativement lents, pour ma carte servomoteur, j'utilise des HCTL2022 qui ont une bande passante de plusieurs Mhz et un filtrage numérique.

Merci.
Est ce que le fait de traiter les signaux A et B avec un tampon trigger et une bascule flip flop, pour sortir un signal compteur et
une sortie direction, améliorerais la rapidité du programme.

Il peut y avoir un état instable sur un seul signal qui peut provoquer des erreurs de comptage. Les sortie codeur des servomoteurs à résolveur sont souvent comme ça.

C'est assez futé, et en effet moins sensible aux parasites. En revanche, c'est plus pénalisant car le timer génère toujours des interruptions qui doivent être sensiblement plus rapides que la fréquence de l'encodeur.

J'ai repris le code du timer de mon croquis MultiCN, il est a 40kHz mais la fréquence peut surement être augmentée. L'interruption timer est prioritaire sur le code de Loop()

 

[usitour]

Bonsoir
@CNCSERV , j'ai essayer ton code sur une règle Acurite 5 micron , ça a l'air d'être bon.
Je n'ai apparemment plus de perte de pas, à essayer sur ma fraiseuse équipée en visu chinoise.
J'ai simplement un peu cherché pour incrémenter ou décrémenter de 5 (pas de 2/100 divisé par 4),
et j'ai modifié les valeurs de la table_cod.
En une journée, grâce à vous, j'ai énormément progressé.
C'est à mon avis largement supérieur en rapidité par rapport à la librairie Fast

Cdlt

 

[tronix]

J'ai aussi appris des choses, même si je n'ai pas d'application en ce moment. Quant aux librairies, je ne suis pas surpris, et il n'est pas rare qu'il soit plus compliqué de comprendre comment les utiliser plutôt que d'écrire le code tapant directement dans les registres du processeur.

 

[cyrdes]

Bonjour à tous,
Désolé,je déterre le sujet car j'utilise le code de JPB en version C pour mesurer la positon d'une butée . (super efficace)
Je débute en programmation sur ARDUINO et j'aimerais savoir si il est possible de sauvegarder sur la ram d'un DS1307,la valeur de la position de ma butée ( une durée d’intervalle choisi : toutes les minutes).le but étant d'appeler cette valeur au démarrage du système (pour évité une mise à zero).
La géométrie de la machine ne me permet pas d'atteindre le zéro (+5mm à +1100mm precision au mm suffisante)).
le but finale étant de commander les relais de commande de cette butée avec l'arduino et une requête de position sur pavée numérique.
merci à tous

 

[vibram]

Bonjour à tous,
Désolé,je déterre le sujet car j'utilise le code de JPB en version C pour mesurer la positon d'une butée . (super efficace)
Je débute en programmation sur ARDUINO et j'aimerais savoir si il est possible de sauvegarder sur la ram d'un DS1307,la valeur de la position de ma butée ( une durée d’intervalle choisi : toutes les minutes).le but étant d'appeler cette valeur au démarrage du système (pour évité une mise à zero).
La géométrie de la machine ne me permet pas d'atteindre le zéro (+5mm à +1100mm precision au mm suffisante)).
le but finale étant de commander les relais de commande de cette butée avec l'arduino et une requête de position sur pavée numérique.
merci à tous

Je n'ai pas lu tout le sujet, l'efficacité de JPB n'est plus à démontrer
En revanche attention au stockage de la valeur car si la machine est manipulée hors tension, il faut mettre des sécurités à l'allumage

 

[cyrdes]

La manœuvre "électrique " de butée ce fait avec lecture de la position sur l'écran LCD de l'Arduino(alimenté via tranformateur par la machine ). Il y a, dans tous les cas, des fins de course agissant sur les relais de commande moteur de la butée.

 

[jpbbricole]

Bonjour cyrdes

j'aimerais savoir si il est possible de sauvegarder sur la ram d'un DS1307

Pourquoi ne pas sauver dans l'EEPROM de l'Arduino, regardes ici.
Un truc à savoir, les EEPROM on un nombre de cycle d'écriture maximum (~100 000) alors, pour l'économiser, il ne faut pas utiliser write mais update, ainsi on écrit qu'au cas ou la valeur change.
Si nécessaire, je peux t'aider à implémenter cette fonction de sauvegarde..

Cordialement
jpbbricole

 

[cyrdes]

Bonjour jpbbricole,
J'ai un module DS1307 avec lecteur carte sd à disposition. Pour limité le nombre de sauvegarde ,doit-on intégrer un timer? Pour le update il y a beaucoup de variation de valeur avec le codeur donc beaucoup de sauvegarde non?
Bien-sur, je serais ravis d'obtenir de l'aide. Surtout que c'est la vidéo du post #75 qui m'a motivé a franchir le pas pour mon projet.
Cordialement
cyrdes

 

[jpbbricole]

Bonjour cyrdes

j'aimerais savoir si il est possible de sauvegarder sur la ram d'un DS1307

Tu veux parler du chip mémoire 24C32 sur les modules DS1307?

C'est pas de la RAM mais de l'EEPROM.

La géométrie de la machine ne me permet pas d'atteindre le zéro (+5mm à +1100mm precision au mm suffisante)).

Expliques-moi un peu plus ce problème, parce que on peut très bien inclure ces paramètres dans le programme.

Pour limité le nombre de sauvegarde ,doit-on intégrer un timer?

Une autre piste pour définir quand sauver la position, tu as certainement un système de verrouillage de ta butée, pourquoi ne pas sauver la position au moment du vérouillage?

Cordialement
jpbbricole

 

[cyrdes]

Bonjour jpbbricole,
Merci pour l'interet porté a mon projet.
Je pense avoir avancé en bricolant ton code (ci joint mon bidouillage). il me reste a comprendre l'aquisition de données d'un "KEYPAD analogique RobotDyn".

j'ai ce module: (peut-etre est-il pluis judicieux d'utiliser la SDcard?)

pour la limitation de la butée:
il y a des interrupteur fins de course (pas top pour la précision) sur le circuit d'alimentations du moteur entrainant la butée.

Pour la sauvegarde :
Il n' y a pas de système de blocage de butée (je pense avoir trouvé une solution avec une temporisation et une surveillance du nombre de pas).

Si c'est possible j'aimerias que tu m'éclaire sur le traitement des données du clavier (les rendre exploitable).
Je n'ai pas le capteur de homing sur mon installation (je n'ai pas osé le sortir du code ).
Je pense également mettre en place un bouton "reset" (je cale la machine avec ma butée à 500mm en commande manuel, je "reset" et démarre le programme à partir des 500mm puis condamne la commande manuelle).
J'espère avoir fait le tour de mes contraintes.

Encore merci
Salutations
Cyrdess