filetage avec microcontrolleur

[vibram]

je n'ai pas pu beaucoup avancer ce weekend mais voila ou j'en suis:
j'ai ajouté un bouton qui est lu par un timer interrupt. Pour le moment ce bouton (qui allume la LED verte sur la video) permet de passer en mode manuel (LED allumée) ou automatique, cad que le PAP suit le codeur.

J'ai ajouté un deuxieme bouton pour un retour outil.
je pense que l'idée de CNCServ est bonne à savoir de piloter le moteur uniquement via le TIM2 (et donc pas par la fonction retour outil pour le moment).
Donc ce bouton (qui active également la LED PC13 du board) a pour effet de passer la variable retour à 1 ou à 0.
Et j'ai voulu faire de maniere à ce que lorsque qu'il n'y a plus de variation de la position de la broche & que la position step > 0, alors on fait revenir l'outil.
J'ai mis la fonction dans le cycle & afin de respecter les cycles.
Je ne comprends pas pourquoi cela ne fonctionne pas. Lorsque je suis effectivement en mode retour outil (variable retour == 1), j'ai l'impression qu'il n'y a plus de cycle et que ca va a une vitesse folle. A tel point que lorsque j'appuie sur le bouton, j'entends juste un "bip" comme si tous les step descendaient à la volée, a la secode 52.
J'essaie deja d'avoir quelque chose de fonctionnel et apres je verrai comment je gere les variables avez cla position de la broche, le retour outil etc.

Dans les détails, on voit aussi que mon débounce n'est pas tres fonctionnel. j'ai mis une capa de 100uF, je vais voir en changeant cette valeur.

Vous devez être connecté pour voir ce contenu.

 

[vibram]

Petite question:
Est-ce que je peux mettre 2 timers comme le TIM4 ? enfin TIM3 et TIM4, avec le meme type d'IRQn pour gerer un deuxieme codeur?
J'ai fait quelques tests mais le TIM3 ne semble pas fonctionner.
Je posterai mon code ce soir ou demain, je me suis emmêlé dans les versions et perdu quelques jours de boulot..

 

[vres]

Je suis désolé, je n'ai pas trop le temps de me pencher sur ton code, jebsuis tout le temps en déplacement.
Avec un timer tu peux générer plusieurs interruptions a des fréquences différentes

 

[vibram]

aucun souci, j'ai pas mal avancé, je posterai le code ce weekend pour montrer ou j'en suis.
Là je bloque sur un deuxieme codeur rotatif juste pour pouvoir commander le moteur manuellement.
Je prendrai le temps ce weekend

 

[vibram]

Bon j'avoue avoir du mal à comprendre ce qu'il se passe
j'ai un code *alacon* pour tester le codeur, RAS tout fonctionne avec le codeur 1600 pulse et aussi avec un petit codeur rotatif 12 pulse ou un truc du style.
Lorsque je branche les deux codeurs sur des GPIO différents bien sur, peu importe les GPIO que j'initialise dans mon code, c'est le codeur 1600 pulse qui est pris en compte
Par exemple

Vous devez être connecté pour voir ce contenu.

Le codeur 1600 est sur le GPIOB 6/7 et le codeur est quand meme incrémenté
J'ai bien fait un rebuild all target, je vois bien que le sketch est différent mais rien a y faire, c'est ce codeur qui envoie sur le timer quel que soit le branchement.
Et j'ai bien respecté ce branchement pour les deux codeurs

Est-ce possible qu'on ne puisse pas mettre 2 timer encoder ?
Cela ne devrait pas avoir d'incidence sur le fait que les pulses du codeur sont quand meme lues meme lorsque je code indique d'autres GPIO






Edit:
l'ensemble de mon code a peu pres fonctionnel, reste la commande manuelle lorsque j'aurais réglé ce probleme de codeur

Vous devez être connecté pour voir ce contenu.

 

[vibram]

Boin j'arrive à quelque chose qui commence à me plaire.
J'ai un codeur rotatif en mode manuel pour positionner le chariot, un en mode automatique pour le filetage, une fonction retour apres chaque passe.
Sur le code ci dessous, l'affichage n'est pas celui final, c'est encore la version qui me sert de debug idem pour les fonctions de test moteur, c'est encore là tant que je n'ai pas une version qui fonctionne à 100%
Maintenant il faut que je bosse un peu le hardware, voir si je peux adapter mon rail hiwin et une fois cela fait, faire des tests
Je n'aurais pas pu en arriver là sans votre aide, merci beaucoup

J'ai sans doute encore pas mal à changer mais il y a une base

Vous devez être connecté pour voir ce contenu.

 

[vince_007]

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
​

J'arrive tard sur ce post, je réfléchi à me faire une boite électronique pour mon tour, pour ma part, j'utiliserais un PIC car j'ai les outils et je les maîtrises bien.

Je suis d'accord avec ce raisonnement, ce qui me pose problème, c'est dans le cas de faire 5 STEP toutes les 12 impulsions de codeur, les 5 STEP tu les envois à quelle fréquence ? Faut forcément un lien avec la vitesse de la broche, sinon on va avoir une avance erronée durant ces 5 steps et ça va ce voir sur l'usinage ou le filetage. C'est une question à laquelle je ne trouve pas de réponses claires, ça tombe forcément sur un nombre non entier.

 

[gaston48]

C'est une question à laquelle je ne trouve pas de réponses claires, ça tombe forcément sur un nombre non entier.

C'est à partir de la que le calcul du ratio par 59JAG est original , algorithme de Bresenham qu'on applique aussi
pour le calcul d'un interpolation linéaire
https://www.usinages.com/threads/reducteur-programmable.95098/page-2#post-1137808

 

[vince_007]

Ça veut dire quoi ? Qu'a chaque évolution du codeur de broche, il applique l'algorithme de Bresenham pour savoir si il doit envoyer un step ou pas c'est ça ?

Comment ça se passe dans le cas inverse ou il faut plus de step que de pas de codeur ? On envoi les step à quelle fréquence dans ce cas ?

J'ai du mal à comprendre en lisant les codes, c'est mal commenté pour un gars qui n'a pas réalisé le code.

 

[vres]

les commentaires sont de moi, mais tu sais. Les calculs sont en flottants, pas besoin de bresemham.
Les commentaires auraient étés meilleurs tu aurais compris que c'est une interruption timer et non une interruption sur les impulsions du codeur.
Pour ma part jai fait un minimum mais je pense qu'avec tes compétences ob va bientôt avoir quelques chose de beaucoup mieux

 

[gaston48]

Comment ça se passe dans le cas inverse ou il faut plus de step que de pas de codeur ?

Là c'est un cas insoluble, je l'ai expérimenté et ça broute un peu, mais ça marche.
C'est pour cela qu'il faut une grande résolution de codeur (ça ne coûte rien finalement) pour ne jamais tomber
dans ce cas de figure. La contrepartie, c'est un flux important de données codeurs et plus l'algorithme est simple,
plus c'est rapide.
59JAG fait ça sur un arduino 8 bits quand même

 

[vibram]

En effet les calculs sont fait en flottant et avec une vitesse de broche faible, tu as largement le temps de faire les calculs si le MCU est pas trop lent
Tu peux modifier la résolution et adapter. mais si tu prends un codeur 2000ppr, en quadrature X4, tu arrives à 8000 pulses par revolution; ca me semble plus que largement suffisant. j'ai choisi beaucoup moin pour ce projet. Je n'ai pas encore pris le temps de m'y remettre

 

[vres]

C'est la bonne solution. Si on veut augmenter la resolution en sortie il faut introduire la notion de vitesse, ce n'est plus le meme code.

 

[vince_007]

Il faut savoir que certains PIC ont une interface encoder intégré, ils font l'acquisition x4 en hardware, ils mettent la position du codeur dans un registre qu'il suffit de lire.
Par exemple, le PIC 18F2331 mais il y en a plein d'autres.

Je souhaite me faire une boite qui supporte les vitesses de broche jusqu'à 2500rpm sinon ça ne me sert à rien.

 

[gaston48]

2500 rpm oui c'est logique si tu veux piloter une avance de chariotage.

 

[vres]

Il faut savoir que certains PIC ont une interface encoder intégré, ils font l'acquisition x4 en hardware,

Il faut savoir que cette fonction existe aussi sir les STM32 et que Vibram l'utilise il me semble.

 

[vince_007]

les commentaires sont de moi, mais tu sais. Les calculs sont en flottants, pas besoin de bresemham.
Les commentaires auraient étés meilleurs tu aurais compris que c'est une interruption timer et non une interruption sur les impulsions du codeur.
Pour ma part jai fait un minimum mais je pense qu'avec tes compétences ob va bientôt avoir quelques chose de beaucoup mieux

Eh ben, je sent une pointe d'agression dans ton post, surtout que je parlais des algos de Bresenham et donc pas de ton code mais passons.

Interruption timer OK mais pour faire quoi ? Echantillonné l'acquisition encodeur ? Le timer il tourne a quelle vitesse ?
Mes premiers calculs montrent que ce n'est pas possible de travailler avec des timers sauf à faire tourner la broche lentement. C'est pour cette raison que je me suis rabattu sur les algorithmes par fraction qui ne travaillent pas en flottant, les seuls qui n'introduisent pas d'erreurs et capable de tourner sur des petits micros en 80MHz.
Il me reste à resoudre le problème de la fréquence d'émission des multi pulses mais l'algo de bresenham semble résoudre ce problème en introduisant un autre, la fréquence de l'encodeur doit être supérieure à celle des steps.

 

[vince_007]

Il faut savoir que cette fonction existe aussi sir les STM32 et que Vibram l'utilise il me semble.

J'en doute pas mais je ne veux pas de STM32, je le répète je maitrise les PIC, y compris les DsPIC et PIC32, j'ai les outils de développement qui vont avec. Le STM32 n'apporte rien de plus ou de moins, c'est juste une autre marque avec une autre architecture, que je ne maitrise pas.

 

[vince_007]

Est ce que changer le diviseur des micropas du driver serait une bonne idée dans le cas où on veut une grande avance ?
Bien sûr, ça nécessite de modifier un driver pour piloter ces entrées mais ça permettrais plus de possibilité.

 

[vres]

Eh ben, je sent une pointe d'agression dans ton post,

Je dirai plutôt de l'agacement, tu as surement raison, mes commentaires sont nuls mais ils ont le mérite d'exister. Personne et rien ne m'obligeait à les faire.

Interruption timer OK mais pour faire quoi ? Echantillonné l'acquisition encodeur ? Le timer il tourne a quelle vitesse ?

Le timer sert de base de temps, ça doit être évoqué quelque part,
la fréquence doit être le double de la fréquence de pulse maximun désirée pour le moteur Pas à Pas.
Une interruption sur 2 remet le bit pulse à zéro.

Mes premiers calculs montrent que ce n'est pas possible de travailler avec des timers sauf à faire tourner la broche lentement. C'est pour cette raison que je me suis rabattu sur les algorithmes par fraction qui ne travaillent pas en flottant, les seuls qui n'introduisent pas d'erreurs et capable de tourner sur des petits micros en 80MHz.

Sur ma première carte j'avais un DSP de 80MHZ et 80MIPS et j'avais un timer a 80kHZ. Certes il avais une FPU.

Avec le STM32F4xx qui a lui aussi une FPU, un cadencement à 168MHZ et beaucoup plus en MIPS, on peut avoir un timer de plusieurs centaines de kHZ sans problème.

Maintenant si il faut faire une multiplication de point de façon homogène et faire une synchronisation à la volée sur une broche a 2500tr/min, on est plus du tout sur ce qui a été demandé par Vibram.

Dans ce cas il va falloir calculer les vitesse de la broche, du moteur, gérer les rampes d'accél/deccel pour synchroniser a la bonne position. Ce n'est plus le même travail.

 

[vres]

Ce serait un montage amateur avec une vitesse de broche faible, j'imagine en dessous de 100trs/m

Pour info

 

[gaston48]

Normalement on continu à utiliser les organes mécaniques du tablier pour embrayer une avance
ou un filetage.
Donc, de la même façon qu'on n'embraye pas ou on change les rapport d'une boite d'avance "en marche"
c'est à dire la broche en rotation, ici on bénéficie toujours de l'accélération / decéle naturelle lors de la mise en rotation
ou arrêt du moteur de broche.

Ensuite, il faut voir (mais ce n'est pas indispensable) si cette boite électronique peut nous apporter des solutions
plus confortables aux simples embrayages mécaniques du tablier.
Dans le cas du chariotage, l'apport par exemple de butée électrique d’arrêt automatique.
sachant qu'on peut perdre sans problème le synchronisme dans le cas d'un chariotage
Dans le cas du filetage des solutions qui éviterait de débrayer la vis mère du tablier, de réaliser un
cycle qui s'approcherait d'un G33, mais dont les séquences serait activées par l'appui sur une touche
par exemple, car il faut reculer le transversal, puis reprendre une passe et ainsi de suite. Là
ne pas oublier qu'on peut bénéficier d'un index

 

[vince_007]

Pour les filetages, je ne debraye jamais, je démarre la broche embrayé et j'ai une butée électrique qui coupe la broche sur la fin, ensuite je recule l'outil et je reviens en arrière en inversant la broche. Bon, j'ai un variateur sur la broche avec freinage électrique et ça nécessite une gorge en fin de filetage mais c'est une solution fiable.
Je compte faire pareil avec la boite électronique, donc les rampes d'accélération du moteur pas à pas seront réalisées par les rampes de la broche.

Maintenant pour le chariotage, le synchronisme angulaire avec la broche n'est pas nécessaire, on peut envisager des rampes sur le stepper ou tout simplement embrayer mécaniquement comme c'est le cas avec des pignons.

Mon but n'est pas de faire un tour CN autonome, je veux juste une boite électronique pour virrer les pignons.

Au final, je me demande si un FPGA ne serait pas plus adapté à cet usage.

 

[vres]

Donc, de la même façon qu'on n'embraye pas ou on change les rapport d'une boite d'avance "en marche"
c'est à dire la broche en rotation, ici on bénéficie toujours de l'accélération / decéle naturelle lors de la mise en rotation
ou arrêt du moteur de broche.

Dans ce cas oui il n'y a pas besoin de gérer l'accélération, mais Il me semble que Vibram voulait faire un embrayage.

Si on veut faire quelque chose de bien, alors il faut faut faire un filtrage de la position du codeur, comme cela on a plus un incrément de 0 ou 1 sur chaque cycle, mais un incrément en flottant.
De cette façon, même en cas de multiplication le moteur Pas à Pas va recevoir, des Pulses réguliers.

 

[speedjf37]

Mon but n'est pas de faire un tour CN autonome, je veux juste une boite électronique pour virrer les pignons.

Bonjour,

Cette option m' intéresse beaucoup , je suis ça de très près.

JF

 

[gaston48]

C'est vrais qu'on dévient du sujet et des souhaits de Vibram.

il faut faut faire un filtrage de la position du codeur

Tout à fait, j'ai expérimenté cette solution, pour une autre application de "boite électronique" sachant
que ma résolution de codeur (ici une règle optique) était figé.
Code en flottant avec linuxcnc sur Beagle Bone Black ...

 

[vres]

Avec un tableau circulaire c'est 5 lignes de codes.

Si on veut faire du simple chariotage sans synchro, c'est quand même intéressant d'avoir un embrayage sur broche tournante.
La gestion de l'accélération est quand même importante et ce n'est pas si compliqué que cela.

 

[gaston48]

En chariotage, tu es constamment débrayé mécaniquement car tu as besoin de mouvement
rapide instinctif manuel au volant pour dégager, accoster pour une nouvelle passe etc...
Si tu es embrayé sur la vis mère (pour les tours simples) ou sur la crémaillère c'est mécaniquement
irréversible, tu ne peux pas te déplacer manuellement.
Si le mécanisme n'a pas de friction en stoppant sur une butée, l'ajout d'une butée électrique est
un plus ainsi qu'un réglage d'avance en continu en cour de chariotage.

En filetage, c'est carrément l'inverse, tu ne peux pas débrayé de la vis mère, sinon c'est toute
la problématique "de la retombée dans le pas".
Un premier plus serait une butée électrique qui stoppe l'avance de filetage avec ou sans stopper la rotation
de la broche, plutôt sans stopper pour la fatigue du tour.
Si c'est sans stopper la broche, la possibilité d'inverser le sens de rotation du pas à pas pour revenir
en début de passe et de réenclencher une passe de filetage.
Donc après l’arrêt en butée,
je recule l'outil.
j'appui sur un bouton (joystick à droite) retour rapide je stoppe en relâchant
je prends ma nouvelle passe au vernier
j'appui sur un autre bouton (joystick à gauche) je démarre une nouvelle passe synchronisé.
je pense qu'un index, un pulse par tour de broche est indispensable, peut être une butée
à droite aussi, on se remet dans les conditions d'un filetage aux repères ... et un 32 bits aussi ...

 

[59JAG]

Ça veux dire quoi ? Qu'a chaque évolution du codeur de broche, il applique l'algorithme de Bresenham pour savoir si il doit envoyer un step ou pas c'est ça ?

Comment ça se passe dans le cas inverse ou il faut plus de step que de pas de codeur ? On envoi les step à quelle fréquence dans ce cas ?

J'ai du mal à comprendre en lisant les codes, c'est mal commenté pour un gars qui n'a pas réalisé le code.

Bonjour,
ca fait un momment que je n ai pas lu le post,je vois que l on parle de moi.
pour répondre , oui a chaque pulse sur codeur de broche j applique l algorithme de Bresenham pour savoir si on
envoi un pluse step au pap.
on ne peux envoyé au maximum q un step par pulse.
pour les commentaires le prog est toujours en phase de conception( manque de temps) pour info le prog est de moi et l idée d utiliser Bresenham aussi.
l avancement de mon projet je suis en train ecrire les menu ,intégration d un deuxième codeur pour verfier le pap.

 

[vres]

Quand je parle d'embrayer c'est électriquement, pas mécaniquement.
Il n' y pas de perte de position.

En filetage un resynchronisation est possible si elle se fait sur une zone none usinée.