filetage avec microcontrolleur

[vibram]

la premiere tentative qui ne fonctionnait pas, c'était en 5v.
Le STM semble encore fonctionner correctement pourtant...
Ok je vais faire ca, pince rouge sur le fil A et noir et sur le fil noir (0v) ?

 

[saico]

Bonjour,

Le LPD3806-400-BM est un codeur avec sorties NPN à collecteur ouvert, donc résistances de rappel "pull-up" vers 5v sont obligatoires, sans lesquelles ni le MCU ni multimètre ne pourra détecter des niveaux "haut" de ces sorties.
l'activation des pull-up interne du stm32 ( modification suggérée par @CNCSERV ) devrait résoudre le problème mais il est possible ( mais pas sure ! ) que le rappel vers 3.3v ne soit pas suffisant , donc une résistance d'une valeur de 470ohm ..1k entre chaque sortie du codeur et le 5v est fortement conseillée.

note: le précédent schéma avec résistances et condensateurs est à éviter car il constitue un filtre pass-bas ( utilisé généralement avec des codeurs mécaniques type EC11 ) . ce filtre n’arrangera pas les signaux issues d'un codeur optique de quelques centaines d’impulsions par tour !

cdt.

 

[vibram]

Merci de ces précisions. Mon bagage technique assez faible me fait souvent passer à coté de ce genre de chose..
Je vais reprendre de 0 avec les bonnes résistances et l'ensemble alimenté en 5V + vos modifications

 

[vibram]

Bon, je m'excuse d'amblée pour les photos peu claires...
je peux apporter des précisions ecrites si vous avez des questions sur le branchement

je suis donc parti d'un board STM32F103C8T6 neuf car j'avais eu peur d'avoir fait une connerie avec l'alim de 24v sur l'encodeur

le sketch utilisé est le suivant:

Vous devez être connecté pour voir ce contenu.

Et les branchements:

J'ai suivi vos recommandations : les deux phases du codeur sont branchés sur PB6 et PB7 avec une resistance d'environ 510Ohms.
je n'ai pas de probleme lors de la compilation et de l'envoi
J'ai bien "03 qui s'affiche sur la premiere case du LCD mais rien ne se passe lorsque je tourne le codeur.

j'ai regardé la tension au bornes + et - du codeur: 4.7V

Est-ce que vous voyez une erreur grossiere?
J'ai aussi testé avec le sketch donné initialement, meme probleme.
J'aurais aimé afficher l'equivalent du seriol monitor sur arduino. j'ai donc affiché la fenetre "debug (printf) viewer" mais visiblement ce n'est pas tout a fait la meme chose. Je n'ai pas trouvé d'autre chose.

Au secours

merci de votre aide

 

[saico]

Salut,

Visiblement le câblage coté codeur est faux, voici comment tu devrais câbler les résistances pull-up vers le 5v.

 

[vibram]

Punaise je suis vraiment une buse
Cela fonctionne parfaitement merci beaucoup.
Je vais pouvoir commencer à modifier un peu le code

 

[LETARTARE]

Bonjour,
un site bourré d'exemples https://github.com/avislab/STM32F103 Avec des codeurs.
Pas testé.

 

[vibram]

les mini avancées:
j'ai réussi à convertir la librairie LCD 16x2 en 20x4
C'etait pas horriblement compliqué mais cela me permet d'apprendre un peu et de me familiariser avec l'ensemble.

Maintenant je vais me concentrer sur le codeur de la broche.
Pour re situer le contexte, je pense qu'il est préférable de mettre ce codeur sur un timer plutot qu'en interrupt.

Je dois être capable de
1. calculer la vitesse
2. donner le "top depart" par exemple lorsque la position du codeur est à 0 (là, un interrupt aurait pu être préférable?)

J'ai besoin de calculer la vitesse de rotation de la broche.
Visiblement il y a plusieurs choix possibles:
1. Faire une fonction de durée T, et compter le nombre de pulses durant ce lapse de temps
avantage: c'est simple à faire
inconvenient: ne serait pas un élément bloquant ? ou je peux le faire en non bloquant pour que le reste du sketch se poursuive
2. compter l'intervale entre chaque pulse
avantage: on peut faire sur un petit nombre de pulse et donc une tres courte période
inconvenient: quid de la précision ?
3. autre solution?

Qu'en pensez-vous ?

 

[vres]

Je pense qu'il faut que tu fasses une interruption timer pour avoir une base de temps pour générer tes pulses.
Si ton interruption timer est assez rapide tu dois pouvoir détecter l'index sur une entrée GPIO.
Si ton moteur Pas à Pas doit être synchrone avec la broche, ce qui est le but il me semble, il va devoir démarrer sans rampe d'accélération.
La conversion Position broche <> position moteur est une simple règle de 3.
Il y a un peu de calculs en flottant, le stm32f1xx n'a pas de FPU

 

[vibram]

J'ai commandé un STM32F4 qui est doté de FPU mais je n'ai pas encore creusé la chose.
Ok tu passerais donc en interrupt. Il faut que je vois comment faire pour ne pas que cela gene la suite du déroulement du sketch car l'interet de l'ensemble était de pouvoir adapter la vitesse du PAP en direct par rapport à la vitesse de la broche et non uniquement à un moment donné

 

[vres]

Je travaille avec le STM32F4 j'ai beaucoup de mal à activer le FPU.

Si ça t'intéresse je peux t'envoyer une stm32f4-discovery, j'en ai 2 qui ne me servent plus.

L'interruption ne gène pas (ou très peu) le déroulement de main.

Dans la librairie discovery tu as un exemple de PWM qui utilise les timers

 

[vibram]

c'est gentil mais le mien est déjà en cours de livraison donc je ne vais pas abuser de ta générosité.

J'attends de recevoir le board pour voir ce que ca donne mais j'essaie déjà de me familiariser avec l'ensemble

 

[saico]

Il y a environ 2 ans j’avais fait quelques tests dans ce sens là, le codeur qui commande le moteur pas à pas en mode suiveur en utilisant un stm32f7, le résultat n’était pas vraiment satisfaisant c’était une usine à gaz pour un mouvement finalement très saccadé (surement la méthode utilisée était la moins adaptée), et le projet à fini à la bene ! Voici une vidéo d’archive :

 

[vibram]

Cela a le mérite d'être clair
C'est le fait de vouloir adapter la vitesse en continue qui pose problème (les saccades)?

Et que preconiserais tu ? opter pour une vitesse constante ? quite à prévoir un % de deceleration de la broche du genre, à 60tr/m sans operation de tournage, on tombe à 55 lorsqu'on enlève de la maniere, et on corrige arbitrairement

 

[vres]

il ne faut pas faire de calcul de vitesse sur le moteur.
J'ai fait du rétrofit sur des piqueuse industrielles ou il faut que l'avance soit synchronisée avec les aiguilles.
C'est la solution la plus simple qui fonctionne le mieux.
Si tu veux "embrayer" ton moteur Pas à Pas alors que la broche est à pleine vitesse il faut que le moteur Pas à Pas soit en dessous de sa vitesse start/stop

 

[vibram]

Le moteur ne tournera jamais tres vite car je compte utiliser le harnais/volé, donc vitesse <100 tr/m
Si je comprends bien, tu adapterais juste un PWN constant sans prendre en compte le leger ralentissement ?
Je voulais mettre un codeur sur le PAP au moins pour pouvoir calculer la longueur /position de l'outil

 

[saico]

Sur mon application j’ai eu le problème car la vitesse d’entrée était très variable et presque imprévisibles, ce qui est pas le cas du tournage et spécialement pour un filetage, car la vitesse de rotation de la broche est généralement faible et pratiquement constante avec une petite fluctuation qui sera facilement détectable par un codeur de 1600 CPR !

Ce que je te propose, c’est de programmer un timer en mode périodique avec une période de 100ms ce qui donne une fréquence d’échantillonnage de Fe=10 Hz , à chaque interruption de ce timer tu captes la valeur du codeur ValCodeur, tu mesure la vitesse de rotation :

RPM_broche= ( ValCodeur * Fe * 60 ) / ResCodeur.

La résolution de ton codeur est :

ResCodeur=400 * 4 , car c’est décodé en X4.


Tu mis à jour la vitesse de rotation de ton moteur pas à pas à chaque période ( 100ms ).

si la vitesse d’avance du chariot ne nécessite pas une grande vitesse de rotation du moteur pas à pas, tu aura pas besoin d’une rampe d’accélération et du cout tu simplifiera beaucoup le programme.

Pour le top de départ, il suffit de charger la valeur de 1600 dans le registre de périodicité du timer4 ( utilisé pour le décodage tu codeur ) et d’activer l’interruption de la mise à jour (TIM_IT_Update)

De cette façon tu auras une interruption à chaque tour complet du codeur ( passage de « 1600 » à « 0 » dans un sens et de « 0 » à « 1600 » dans l’autre sens )

 

[vibram]

Merci, sur le papier ca me semble pas mal, je vais voir ce que j'arrive à faire avec le code

 

[vres]

Pour le Pas à Pas je verrai un truc comme ça :
(C'est juste un exemple brut et non essayé)

Vous devez être connecté pour voir ce contenu.

On peut ajouter une accélération mais avec un résultat imprévisible : un retard du moteur sur l'accélération et un overshoot sur la décélération.

 

[stef1204]

Je suis de moins en moins convaincu de l’avantage de ce codeur par rapport à une prise de vitesse à raison d’une impulsion par tour.

Ce n’est pas parce que la broche va varier sa vitesse d’un chouya qui après tout est très stable, la base est un moteur qui prend sa référence sur le 50hz fortement démultiplié.

Le reste n’est qu’un rapport vitesse broche/vitesse visse mère en fonction du pas de filetage.

 

[vres]

Je suis de moins en moins convaincu de l’avantage de ce codeur par rapport à une prise de vitesse à raison d’une impulsion par tour.

C'est 1600 fois plus précis .... et de fonctionner dans les 2 sens,

 

[erolhc]

Bonjour

Je ne pige pas pourquoi vous voulez calculer la vitesse de la broche qui amène pleins d’imprécisions de calculs et bouffe du temps processeur

Admettons :
une vitesse de broche de 120 tr/min
Un codeur 1600 impulsions (400*4) sur la broche
une vis mère au pas de 1.5 mm
Un PAP sur vis mère avec 800 step/tour

L'avancée de l'outil est indépendante de la vitesse de la broche car il suffit de lier les impulsions du codeur de la broche aux step du PAP :

Par exemple faire un filetage de 1 mm :
Il faut donc que le PAP fasse 800/1.5*1= 533.33 STEP (donc avance de l'outil de 1 mm) quand la broche a fait un tour (donc 1600 impulsion)

Donc il faut que toutes les 1600/533.33 = 3 impulsions du codeur de broche, le PAP avance d'un STEP

Pour un filetage au pas de 1.25mm : 1600 / (800 / 1.5 * 1.25) = 2.4 impulsion de codeur = 1 STEP (pour rester dans le entiers le PAP fait 5 STEP toutes les 12 impulsions codeur)

Pour un pas de filetage de 4 mm fait à 120tr/min cela fait 2133.33 STEP pour 1 tour de broche donc 1600/2133.33 = 0.75 impulsions broche pour 1 step (ou 4 STEP par impulsion de broche)
120tr/min = 2 tours/sec = 3800 Hz à la broche et 0.75*3800 = 2850 Hz de fréquence START/STOP au moteur PAP ce qui peut être un peu élevée pour un PAP mais de toute façon la broche ne passe pas non plus de 0 à 120tr/min instantanément non plus et faire un pas de 4 mm ce n'est pas tout les jours je pense et surtout à 120tr/min !

J'espere ne pas m'être planté dans les calculs
​

 

[vres]

car il suffit de lier les impulsions du codeur de la broche aux step du PAP :

Mais c'est exactement ce que j'ai fait, la broche et le moteur sont 100% synchrone et dans les 2 sens

 

[erolhc]

Possible je n'ai pas regardé ton programme mais quand je vois "interruption toutes les 100 ms", calcul de vitesse, etc ...

 

[gaston48]

Bonjour,
Et tant qu'à faire on évite une division avec un algo de Bresenham.

https://www.usinages.com/threads/reducteur-programmable.95098/page-2#post-1140711
https://www.usinages.com/threads/reducteur-programmable.95098/page-2#post-1140587

 

[saico]

Possible je n'ai pas regardé ton programme mais quand je vois "interruption toutes les 100 ms", calcul de vitesse, etc ...

c’était ma proposition et j’avoue que c'est pas du tout pratique, par contre celle de @CNCSERV me semble correct .

 

[vibram]

j'ai du mal à tout suivre mais au moins il y a de l'eau au moulin, j'ai de quoi reflechir quelques jours

 

[vres]

Et tant qu'à faire on évite une division avec un algo de Bresenham.

Comme je l'ai dit ce n'est qu'un exemple pas du tout optimisé, on peut remplacer la division par une multiplication :

const float Resolution_Broche = 1.0/1600.0f; // nb de tour pour une impulsion codeur
Position_Broche = (float) TIM_GetCounter(TIM4) * Resolution_Broche;
Avec la FPU c'est un cycle contre 14 pour une division.

 

[stef1204]

C'est 1600 fois plus précis .... et de fonctionner dans les 2 sens,

C’est purement théorique, en pratique la vitesse de la broche et la vitesse de la visse mère ont une inertie, de plus comme je l’ai expliqué la broche est réglé par l’horloge de 50hz ultra stable très divisé rendant la vitesse très stable.

 

[vres]

Ce qui nous intéresse ce n'est pas la vitesse de la broche mais ça position pour synchroniser le moteur Pas à Pas pour faire du filetage par exemple comme sur les exemples cités par Gaston plus haut ou comme l'a bien expliqué Chlore
La position angulaire du mandrin a son importance.
J'ai peut-être mal compris.