Coder un diviseur logique dans un microcontrôleur dsPIC33EP

[AstroFOX]

Bonjour,

Je vais poser la question mais j'ai bien peur de la réponse, est il possible de coder un diviseur logique (bascule D) dans un microcontrôleur?

Mon problème est assez rigolo : je dois asservir en position 24 moteurs avec encodeur (Faits sur demande chez Maxon). Basé sur le cahier des charges initial, j'ai fait un PCB avec un dsPIC33EP512MU814, sur le papier tout fonctionne.

Mais! Le service achat s'est trompé dans la commande, et au lieu d'avoir des encodeurs 100 CPR, les encodeurs font 1000 CPR... donc autant dire que le MCU loupe un paquet d'impulsions, qu'il n'a pas beaucoup de temps de faire autre chose en dehors du vecteur d'interruption, et qu'il y a quelques switch de fin de course qui y ont laissé leur vie

Avant de devoir re-router un PCB avec une chiée de diviseurs hardware, voire passer sur un FPGA, je préfère demander si c'est possible de faire une division de fréquence "sans déranger" le MCU...
-----

[jiherve]

bonsoir,
tu peux essayer avec les timers disposants d'une horloge externe, comme je n'utilise pas les PICs je ne peux t'en dire plus.
JR

[nornand]

bjr : tu retournes tout au service aïcha en leur demandant gentiment de te fournir le matériel commandé, c'est leur boulot .

[AstroFOX]

C'est notre service achat qui s'est planté ^^ on a déjà contacté Maxon, ils ne peuvent rien faire car c'est fait sur commande, le capteur est une puce effet hall iC-Haus programmable moulée dans un capuchon en plastique, et les pins de programmation ne sont pas accessibles sur le micro PCB, ça ressemble à ça : https://pbs.twimg.com/media/CCEmk55UsAARmYh.jpg , la bague en alu est juste collée à la cyano sur le moteur, ça s'enlève facilement, mais sans possibilité de reconfigurer le capteur, ça sert à rien... La nappe HE-10 ne communique que les signaux A et B, et les alim du capteur

[A voir en vidéo sur Futura]

[umfred]

Au niveau de ta gestion des interruptions, tu ne peux pas compter 10 "impulsions" avant de faire la tâche de l'interruption. Si ce n'est pas faisable par ton CPU, il faut le faire faire par un autre processeur qui va te générer une "impulsion" toutes les 10, pour récupérer

[jiherve]

re
si ce sont des encodeurs quadrature et que tu les exploites pour déterminer le sens de rotation il ne suffira pas de diviser leur fréquence, donc amha tu ne couperas pas au développement d'un FPGA/CPLD.
JR

[Murayama]

Bonjour!

Du point de vue asservissement, quelques commentaires:
- ABZ pour faire un asservissement en position requiert le passage à un point zéro.
Il vaudrait mieux un encodeur absolu. Cet encodeur, vous pouvez le faire vous même
avec des composants modernes, avec une résolution dans les 2^17 ~ 2^18 par tour si c'est
magnétique, ou dans les 2^20 ~ 21 si c'est optique. NB: je dis ça au pif en supposant
un petit diamètre, disons 25 ~ 30mm. Ça peut évidemment varier suivant le diamètre.
- Un encodeur absolu n'a pas besoin de point 0, donc pas besoin de l'initialiser.
Donc moins de switches de fin de course qui y laissent leur vie.

Du point de vue méthode.
- Vous cherchez à asservir l'axe de sortie, mais vous mesurez la position du moteur.
entre les 2, il y a un train épicycloïdal qui a du jeu. Donc depuis le moteur, vous
ne pouvez pas connaître une position précise de l'axe de sortie.
- En plus, ce jeu dépend de la température, de l'usure, etc...
NB: Maxon a peut-être une méthode de compensation de jeu, je ne sais pas, mais quoi
qu'il en soit, il vaut toujours mieux mesurer directement ce qui vous intéresse,
c'est à dire l'axe de sortie du réducteur.
- Pour initialiser la position, vous aurez besoin en plus d'un point zero externe
en sortie de réducteur. Il n'y a apparemment rien en sortie de réducteur ou en
tout cas la vue éclatée ne le montre pas.

si ce sont des encodeurs quadrature et que tu les exploites pour déterminer le sens
de rotation il ne suffira pas de diviser leur fréquence, donc amha tu ne couperas pas
au développement d'un FPGA/CPLD.

J'ai bien peur aussi qu'il n'y ait pas d'autre solution. En plus il serait possible
de connecter las 24 encodeurs à un gros FPGA central (1), ce qui permettrait d'avoir une
synchronisation parfaite. Une impulsion genre "latch" et vous sauvegardez la position
absolue de tous les encodeurs, chacun dans un registre, ce qui permet d'avoir une capture
des 24 positions au même instant (avec une précison qui dépend de l'horloge du FPGA,
mais disons à 10 ns près pour un 100 MHz). Avec un µP, il va falloir énormément de temps pour
interroger chaque encodeur à tour de rôle, et toutes les positions seront décalées.

(1) pas si gros que ça en fait s'il ne s'agit que de convertir les signaux AB en
valeurs absolues. Du point de vue fréquence, 1000 pas par tour à une vitesse de 10000
rpm, ça fait dans les 160 kHz. N'importe quel FPGA récent est capable de traiter ça.

Pascal

[AstroFOX]

Bonjour,

Alors pour clarifier tout ça :

Les moteurs servent à mettre un mouvement un petit élément en silicone pour reproduire le plus fidèlement possible un organe humain. Contrairement à l'exemple en image, les moteurs n'ont pas l'étage réducteur. On se sert de l'axe pour actionner une vis sans fin, transformant donc la rotation en mouvement linéaire. L'encombrement étant un problème, on actionne des pistons (seringues de 5 ou 10 ml selon l'amplitude voulue) et la "transmission de mouvement" se fait par des tubulures et un liquide visqueux. On peut ainsi déporter les moteurs sous forme de 3 étages de 8 moteurs.

L'élément en silicone est formé de plusieurs vessies que l'on "remplit" ou "vide" pour créer 2 séquences de mouvement. La durée de séquence complète est de 5 secondes pour la première, 8 secondes pour l'autre.

Chaque piston a 2 switchs, un pour trouver l'origine, l'autre pour trouver la fin de course. Normalement on ne les touche pas pendant la séquence, sauf en cas de bug... L'initialisation se fait lentement et par groupe de travail car il y a des vessies que l'on ne doit pas remplir en même temps sinon la membrane risque de se déchirer.

tu peux essayer avec les timers disposants d'une horloge externe, comme je n'utilise pas les PICs je ne peux t'en dire plus

si ce sont des encodeurs quadrature et que tu les exploites pour déterminer le sens de rotation

En effet j'utilise les encodeurs en quadrature pour déterminer le sens de rotation, mais je pourrais peut-être * me passer de la détermination du sens, en tout cas le MCU n'a pas assez de timers/compteurs pour récupérer 24/48 signaux. Il n'y a que le changement d'état des GPIO qui peut permettre de récupérer les états.

Du point de vue asservissement, quelques commentaires:
- ABZ pour faire un asservissement en position requiert le passage à un point zéro.

Du point de vue méthode.
- Vous cherchez à asservir l'axe de sortie, mais vous mesurez la position du moteur.
entre les 2, il y a un train épicycloïdal qui a du jeu.

ça c'est de ma faute, la photo est à peine différente du modèle qu'on a, car sur notre modèle il n'y a pas de réducteur, mais j'ai remis les infos essentielles en début de message

En dehors de l'interruption, le MCU se charge de faire l'acquisition de 4 capteurs de pression analogiques, et d'envoyer en temps réel toutes les infos (position de chaque actionneur + pression) par USB au PC. En préprocessing on récupère toutes les séquences depuis une EEPROM vers les buffers en RAM, ou bien on peut directement remplir les buffers RAM en envoyant les infos par USB, mais ça n'a pas d'influence sur la séquence, par contre l'USB m'impose de rester sur la même famille de MCU pour éviter un développement, surtout sur FPGA...

* Etant donné que les actionneurs ont des vis sans fin, on pourrait admettre qu'il n'y a pas de changement de sens de rotation non désiré, et donc je pourrais me passer de la détection du sens de rotation car c'est moi qui l'impose.

Pour la suite des évènements, on est en train de voir avec Maxon si il y a possibilité d'avoir les bons encodeurs seuls à un tarif raisonnable. Sinon la solution à laquelle je viens de penser, c'est de faire une petite interface logique qui viendrait se loger sur le HE-10 de la carte actuelle et le HE-10 du codeur.

Au niveau de la logique, il faudrait que je fasse la table de vérité pour vérifier que ça se passe comme prévu, mais avec 2 bascules D on peut générer une impulsion distincte en fonction du sens de rotation. J'aurais donc une impulsion "UP" et une impulsion "DOWN" si je mets un compteur modulo 10 sur "UP" et "DOWN", dès que l'un passe à '1' l'info arrive sur mon MCU, qui ne détecte non plus A/B mais UP/DOWN. On reset les compteurs et c'est reparti

[Murayama]

Re!

Pour la suite des évènements, on est en train de voir avec Maxon si il y a possibilité d'avoir les bons encodeurs seuls à un tarif raisonnable.

Tout dépend de ce que vous appelez de "bons" encodeurs, et quel tarif maximal serait raisonnable.
En plus, on pourrait ajouter la résolution nécessaire.
Si c'est pour avoir 100 pas par tour, il y a des encodeurs à faire vous-même avec un aimant en bout
d'axe. Prix approximatif: moins de 5 euros à coup sûr, mais je ne suis pas commercial ni distributeur,
donc je ne peux pas donner de vrais tarifs.



Le chip utilisé fait 4mm de côté, 16 pattes. Résolution 1024 pas par tour, MAIS: fréquence maximal
de mesure 4000Hz. Ceci dit, si le moteur entraîne des vis sans fin, j'imagine que vous n'atteindrez
jamais la rotation limite qui est de 2000 tours par seconde (donc 120 000 rpm). Il y aura certainement
de la marge.

Il faut aussi placer un aimant en bout d'axe. Ce composant est absolu mais pas multitours, donc votre
MCU devra compter les tours. De là, vous avez les choix suivants:
- Mettre des butées en fin de course
- Mettre un 2ème chip après un engrenage. Si vous avez par exemple un rapport de réduction de
1/100, alors vous aurez un vrai multi-tours à 100 tours. À vous de voir si ça suffit.
Si vous appelez At l'angle total, Am l'angle moteur et Ar l'angle après réduction, alors vous pouvez
calculer la position absolue qui sera proportionnelle à At, donc à 100*Ar + Am.

Pascal

PS: 'tain, toujours impossible de mettre correctement des images "inline", problème récurrent depuis
des années. Quelqu'un sait-il comment faire?

[jiherve]

bonjour
Pascal il achète ses moteurs équipés il ne les bidouille pas!
L'idée d'une interface placée sur les HE10 est bonne si l'on y dispose d'alimentation,pas de modif de CI à faire, amovible, que demander de plus. Avec un UP/DOWN + un pulse par moteur il faut environ 128 ff cela tient dans un petit CPLD.
j'oubliais : facturation de la modif sur le budget du service achat (OE dans ma boite) çà je l'ai déjà fait sans états d’âme
JR

[AstroFOX]

Le chip utilisé fait 4mm de côté, 16 pattes. Résolution 1024 pas par tour, MAIS: fréquence maximal
de mesure 4000Hz.

C'est sans doute le même chip, un iC-Haus magnétique configurable (en usine chez Maxon) dont le PCB est moulé dans le plastique, pour donnée une idée, sur la photo que j'avais mi en lien, la bague alu fait 15mm diamètre intérieur donc le PCB que tu as en photo serait peut être jouable.

Pascal il achète ses moteurs équipés il ne les bidouille pas!

La bague en alu s'encastre au cul du moteur, il y a un point de colle cyano qui le maintient en place mais ça se décolle sans trop forcé : je l'ai fait sur le moteur en rab pour voir comment c'était foutu et voir si on pouvait modifier facilement ^^ on reclipse, un point de colle et c'est reparti!

Mais l'idée était plutôt d'avoir le moins de modif possible à apporter, parce que derrière j'ai pas un temps illimité :
- Aucune modif hard, que du code, pour le moment c'est pas gagné.
- Arriver à avoir les codeurs configurés à la bonne valeur, pour l'aspect financier et les délais de livraison c'est pas mon domaine, je suis techno et je rattrape les conneries avec les moyens/délais qu'on veut bien me laisser ^^
- Dernière idée en date : interface entre les HE-10, j'ai l'alim et les signaux, donc c'est le plus simple au final, un petit PCB en 24 exemplaires, ça prend une semaine chez Eurocircuits.
- Modif électronique + adaptation mécanique pour refaire des encodeurs qui se logeraient à la place de ceux existants. Risque de casse à prendre en compte (c'est pas parce que j'ai pu en enlever un sans difficulté, que ce sera pareil pour tous les autres), il faut un peu d'usinage ou impression 3D, ça se fait mais c'est galère (même si la pièce n'est pas d'une complexité extrême)

facturation de la modif sur le budget du service achat (OE dans ma boite) çà je l'ai déjà fait sans états d’âme

Chez nous c'est transparent, je signale le problème, j'essaie de négocier un délai raisonnable pour ma propre personne, je propose 2 solutions leurre :
1) achat des bons encodeurs : le service achat se démerde avec le fabricant.
2) conception d'une nouvelle interface pour rectifier le tir. Solution complexe et onéreuse.
Pendant que le trio infernal débat, je planche sur la petite interface dans mon coin, comme ça le temps qu'ils cogitent aux solutions complexes je gratte du temps

[jiherve]

Re

Pendant que le trio infernal débat, je planche sur la petite interface dans mon coin, comme ça le temps qu'ils cogitent aux solutions complexes je gratte du temps

c'est sage !
JR

[Murayama]

(Re!)^n

C'est sans doute le même chip,

Si l'encodeur sort des signaux AB, ce n'est probablement pas le même chip

Pascal il achète ses moteurs équipés il ne les bidouille pas!

Oui, mais quand on a grillé le budget sur quelque chose d'inadapté (ça m'est arrivé plus d'une
fois), il faut parfois mouiller la chemise pour rattraper les conneries.

Pascal

[AstroFOX]

Si l'encodeur sort des signaux AB, ce n'est probablement pas le même chip

C'est vrai que je ne me suis pas arrêté sur la spec technique pour le coup, mais en capteur absolu ça va vraiment être compliqué ne serait-ce que pour communiquer avec 24 capteurs simultanément, ce qui impose une solution FPGA. Je ne me sens pas de développer de presque 0 la partie USB (même si on trouve des lib et des plateformes hardware bien équipées telles que Zinq et cie).

Ça aurait été une solution élégante dès le départ avec le budget et le temps adapté par contre, mais étant plus à l'aise sur microcontrôleur ça me semblait être la meilleure solution pour entreprendre un projet d'une telle ampleur avec mes compétences et les blocs que j'ai déjà mis en œuvre auparavant

Oui, mais quand on a grillé le budget sur quelque chose d'inadapté (ça m'est arrivé plus d'une
fois), il faut parfois mouiller la chemise pour rattraper les conneries.

Exactement c'est d'ailleurs pour ça que je suis là!

[Murayama]

Re!

Ce capteur fonctionne en SPI. Communiquer avec 24 capteurs en SPI n'est pas
très compliqué, il faut surtout ne pas mélanger les CS et surtout n'en envoyer qu'un
seul à la fois. D'autre part la plupart des processeurs permettent d'utiliser une
DMA sur le SPI, ce qui fait que la lecture est parfaitement transparente et qu'il
suffit d'aller lire le buffer reçu quand on reçoit une interruption.
Parce que là, aller titiller du AB brut de décoffrage à une fréquence 10 fois plus
rapide que prévu, je ne le sens pas bien.
Je crois que cette solution SPI est la solution de moindre effort.
-> Si vous utilisez un FPGA qui fait le strict minimum ou qui fait beaucoup, il faut
tout revoir et refaire un circuit imprimé.
-> Si vous continuez avec les signaux AB, je ne vois pas de solution simple en soft
pur.
-> Une solution SPI... faut voir. Il y a certainement des choses à modifier sur la carte,
je ne sais pas si c'est possible.

Pascal

[AstroFOX]

24 capteurs répartis sur un ou deux bus SPI ça commence à faire beaucoup, même si je monte la fréquence du SPI à 20 MHz, ça reste de la lecture séquentielle, et mon hardware n'est pas du tout adapté.
L'avantage du FPGA aurait été de pouvoir faire 24 blocs presque totalement indépendants intégrant l'asservissement et la PWM.

Pour un minimum de modification, j'ai un HE-10 avec +5V, GND, signaux A et B, même pas besoin de tirer un fil pour l'alim! Donc une interface intermédiaire est le plus adapté au matériel que j'ai sous la main. D'ailleurs un petit MCU 8-bit à 2€ pourrait presque faire le job, gérer un seul encodeur et renvoyer 2 signaux à la carte mère, sous le format que je veux, il dédierait 100% de son temps à cette tâche donc peu de chance qu'il loupe un évènement. J'ai un vieux PIC18F en DIP-28 et un Lauchpad de Texas Instruments dans un tiroir, ça va être rapide pour faire un proto, mais je vais quand même évoquer le re-routage et développement sur FPGA pour laisser les administratifs faire dans leur slip avant de leur proposer une solution!

[AstroFOX]

Bon après un premier essai, même un petit MSP430G2553 (le moins performant des deux MCU que j'ai sous la main) arrive a récupérer les infos de l'encodeur j'ai pas la carte mère actuellement donc je ne peux pas tester in-situ, mais avec le moteur supplémentaire (le 25ème que j'avais privé de son encodeur) et une fourche optique de reset à chaque tour, j'arrive bien à récupérer les 1000 incréments même à vitesse maximum (alimentation de labo 24V) en envoyant l'info sur l'UART

[Murayama]

Bonjour!

24 capteurs répartis sur un ou deux bus SPI ça commence à faire beaucoup, même si je
monte la fréquence du SPI à 20 MHz, ça reste de la lecture séquentielle, et mon hardware
n'est pas du tout adapté.

Faut voir. Quel doit être le temps de réponse? On est toujours surpris par la vitesse
de l'électronique qui est infiniment plus réactive que la mécanique. Un client me disait
à propos d'un chip que 25 µs de latence, c'est très lent. Je lui ai fait observer que
même si le moteur tourne à 6000 rpm (vitesse usuelle pour les moteurs industriels),
25 µs ne permet même pas au moteur de tourner d'1 degré.

D'autre part, le TW11 a une méthode de transmission des données très efficace. Il
exploite à fond les propriétés du SPI. Le bus SPI est un échange de données. Même
si vous ne voulez que lire, vous êtes obligé d'écrire. D'ailleurs dans mon software,
je n'utilise jamais spi_read ni spi_write, mais spi_exchange. Ça simplifie puisqu'il
n'y a besoin que d'une fonction qui fait tout.

Le timing est le suivant.

La fréquence max du SPI est 16 MHZ. Donc pour transmettre des paquets de 16 bits,
il vous faut 1 µs. Si vous lisez les 24 canaux à 4khz, vous devrez donc faire 96000
lectures de 1µs, ce qui vous occupe le µP à 10 % ou un peu plus en fonction des
autres tâches à accomplir pour gérer 24 canaux de SPI. Ça ne me semble pas infaisable,
même avec un seul SPI. Il y aura juste une chose à gérer: vous allez lire à chaque
fois la donnée que vous avez demandée à la dernière commande, donc il y aura un délai
un peu long. Mais encore une fois, pour des systèmes à vis sans fin, j'imagine que
ce sera suffisamment réactif.

Une chose que j'ai faite avec le MSP430 (je ne lisais que 8 canaux et ce n'était pas
des encodeurs, mais des accéléromètres). Avec un seul port, il est possible d'utiliser
toujours la même DMA. Exemple en pseudo code pour 24 canaux. Je ne mets pas la fonction
init, mais il suffit de configurer la DMA pour l'interruption.

uint8 chan;
uint16 data[24];

start() {
	chan = 0;
	chip_select(chan)
	trigger_dma();
}

dma_interrupt() {
	chip_deselect(chan);
	chan++;
	if(chan == 24) chan = 0;
	data[chan] = SPI_VAL;
	chip_select(chan);
	trigger_dma();
}

Avec DMA, le programme ci-dessus ne fait que gérer les canaux, configurer les chip-select
etc... En comptant, soyons généreux, 4 clocks par ligne, ça fait 40 clocks. 40 x 24 x 4000,
ça fait 384000 clocks. Même sur votre 2553 (16 MHz??), ça fait 2.5% de temps µP.
À partir de là, c'est à vous de voir si 4000 lectures par seconde suffisent, etc, etc...

Pascal

[AstroFOX]

Bonjour,

J'ai réussi à faire l'adaptation nécessaire avec la petite interface supplémentaire x24, finalement je suis resté sur le MSP430G2553 en me servant du Launchpad comme interface de programmation

En tout cas Murayama, même si je n'ai pas retenu la solution SPI à cause de la difficulté d'accès au port SPI sur le design actuel, je garde ces infos dans un coin pour un futur dev on ne sait jamais