V
vibram
Compagnon
Au sujet des formations dispensées à Station F, tout ce qui est relatif à mon premier message et au sujet reste sur le sujet accessible à tous, c'est pour eviter le hors sujet.
O
Otatiaro
Compagnon
Salut,
Je viens de relire ses posts, et je pense que c'est simplement une incompréhension, il dit que lui ne code plus trop en C/C++, pas qu'il ne faut plus les utiliser (encore un qui à basculer du côté obscur et qui fait du JS j'imagine mais sur PC).
Sur STM32 il n'y a pas vraiment d'alternative au C/C++ ... il y a bien eu des STM32 qui faisaient tourner du java, mais la bonne blague est terminée.
On peut rajouter des surcouches type python, mais le moteur d'exécution reste bien en C/C++.
Et sinon j'invite cordialement ces spécialistes à la formation qu'on prépare sur le sujet avec ST, ils devraient apprendre beaucoup de choses.
Pour revenir au sujet initial:
- c'est un codeur incrémental sur une broche ?
- quel CPR, et quelle vitesse de broche max ?
- quel but final ? Si je comprend bien c'est pour du filetage, donc il faut synchroniser l'avance sur la rotation de la broche ?
Du coup ce n'est pas une question de vitesse (qu'on peut calculer séparement pour l'affichage), mais plutôt de position.
Quelle est l'erreur admissible sur la synchro (idéalement en nombre de pas du PaP de sortie) ?
Si tout ça est bon, on pourrait envisager:
- un timer en entrée en mode encodeur, qui va calculer la position comme un grand (A et B), attention à prendre plutôt TIM2 ou TIM5 qui sont sur 32 bits (les autres sont sur 16 bits), ça évitera d'avoir à gérer les dépassements.
- un timer (Systick) qui déclenche à intervalle régulier (1ms par exemple), qui prend la valeur de l'encodeur, applique un facteur (calcul entier), et en déduit la position attendue en sortie
- un timer (heureusement qu'il y en a beaucoup sur les STM32 !!!) en sortie, dont le ARR et le pulse count aura été réglé de sorte à générer le bon nombre de pulses (différence entre position actuelle et position que l'on vient de calculer) sur 1ms.
De cette façon on a toujours 1ms de décalage fixe entre l'entrée et la sortie (à voir en fonction de l'erreur admissible), pas d'accumulation d'erreur, et le MCU n'a quasiment rien à faire (en tout cas pas à gérer les timings précis, c'est les timers qui vont s'en charger).
[EDIT] et surtout la sortie sera suffisamment lissée (pour ne pas envoyer un paquet de pulses d'un coup, que le pas à pas soit bien propre et ne donne pas d'à coup).
Et tout les 100 cycles de calculs (donc à 10Hz), on fait le delta global de position en entrée, on multiplie par 10 et on a la vitesse (en CPR/s, reste à convertir en RPM pour l'affichage).
Thomas.
Je viens de relire ses posts, et je pense que c'est simplement une incompréhension, il dit que lui ne code plus trop en C/C++, pas qu'il ne faut plus les utiliser (encore un qui à basculer du côté obscur et qui fait du JS j'imagine
mais sur PC).Sur STM32 il n'y a pas vraiment d'alternative au C/C++ ... il y a bien eu des STM32 qui faisaient tourner du java, mais la bonne blague est terminée.
On peut rajouter des surcouches type python, mais le moteur d'exécution reste bien en C/C++.
Et sinon j'invite cordialement ces spécialistes à la formation qu'on prépare sur le sujet avec ST, ils devraient apprendre beaucoup de choses.
Pour revenir au sujet initial:
- c'est un codeur incrémental sur une broche ?
- quel CPR, et quelle vitesse de broche max ?
- quel but final ? Si je comprend bien c'est pour du filetage, donc il faut synchroniser l'avance sur la rotation de la broche ?
Du coup ce n'est pas une question de vitesse (qu'on peut calculer séparement pour l'affichage), mais plutôt de position.
Quelle est l'erreur admissible sur la synchro (idéalement en nombre de pas du PaP de sortie) ?
Si tout ça est bon, on pourrait envisager:
- un timer en entrée en mode encodeur, qui va calculer la position comme un grand (A et B), attention à prendre plutôt TIM2 ou TIM5 qui sont sur 32 bits (les autres sont sur 16 bits), ça évitera d'avoir à gérer les dépassements.
- un timer (Systick) qui déclenche à intervalle régulier (1ms par exemple), qui prend la valeur de l'encodeur, applique un facteur (calcul entier), et en déduit la position attendue en sortie
- un timer (heureusement qu'il y en a beaucoup sur les STM32 !!!) en sortie, dont le ARR et le pulse count aura été réglé de sorte à générer le bon nombre de pulses (différence entre position actuelle et position que l'on vient de calculer) sur 1ms.
De cette façon on a toujours 1ms de décalage fixe entre l'entrée et la sortie (à voir en fonction de l'erreur admissible), pas d'accumulation d'erreur, et le MCU n'a quasiment rien à faire (en tout cas pas à gérer les timings précis, c'est les timers qui vont s'en charger).
[EDIT] et surtout la sortie sera suffisamment lissée (pour ne pas envoyer un paquet de pulses d'un coup, que le pas à pas soit bien propre et ne donne pas d'à coup).
Et tout les 100 cycles de calculs (donc à 10Hz), on fait le delta global de position en entrée, on multiplie par 10 et on a la vitesse (en CPR/s, reste à convertir en RPM pour l'affichage).
Thomas.
V
vibram
Compagnon
Pour rappel le sujet initial est ici:
https://www.usinages.com/threads/filetage-avec-microcontrolleur.101117/page-13#post-1364538
Bien que non optimisée, la premiere version du code semble fonctionnelle.
Encore unf ois, il y a encore beaucoup à faire mais disons que c'est une base et que je vais l'améliorer. Je vais faire certaines choses obligatoirement (notamment enlever le max de float) et d'autres viendront uniquement si nécessaire (par exemple gerer les step avec un timer en output compare pour plus facilement gérer le nombre de step et varier la vitesse).
Je pars sur un codeur à 2500ppr pour la fonction diviseur, j'en utiliserai forcement moins pour la fonction filetage.
Pour la fonction filetage, RPM max je table sur 200 ou 400, pour les avances auto ce sera 3000, donc je vais devoir gérer les accelerations etc.
Pour la fonction diviseur; j'ai un reducteur 100:1 donc meme avec 2500ppr en quadrature donc 10'000 ppr je serai largement bon.
Je n'ai pas enormement de temps pour m'en occuper et mes connaissances sont plutot maigres comme je l'ai dit. Je sais qu'on peut forcement faire mieux mais dans un premier temps je veux que ce soit fonctionnel. Si c'est fonctionnel, cela me motivera à améliorer l'ensemble.
Enfin, j'ai recu mon écran 5 pouces et arduino due. Il sera le slave, uniquement pour l'affichage et le STM32 gerera tout le reste (codeur/timer/ clavier etc). je recois le F446RE d'ici la fin de la semaine et j'aurais tout l'équipement définitif
https://www.usinages.com/threads/filetage-avec-microcontrolleur.101117/page-13#post-1364538
Bien que non optimisée, la premiere version du code semble fonctionnelle.
Encore unf ois, il y a encore beaucoup à faire mais disons que c'est une base et que je vais l'améliorer. Je vais faire certaines choses obligatoirement (notamment enlever le max de float) et d'autres viendront uniquement si nécessaire (par exemple gerer les step avec un timer en output compare pour plus facilement gérer le nombre de step et varier la vitesse).
Je pars sur un codeur à 2500ppr pour la fonction diviseur, j'en utiliserai forcement moins pour la fonction filetage.
Pour la fonction filetage, RPM max je table sur 200 ou 400, pour les avances auto ce sera 3000, donc je vais devoir gérer les accelerations etc.
Pour la fonction diviseur; j'ai un reducteur 100:1 donc meme avec 2500ppr en quadrature donc 10'000 ppr je serai largement bon.
Je n'ai pas enormement de temps pour m'en occuper et mes connaissances sont plutot maigres comme je l'ai dit. Je sais qu'on peut forcement faire mieux mais dans un premier temps je veux que ce soit fonctionnel. Si c'est fonctionnel, cela me motivera à améliorer l'ensemble.
Enfin, j'ai recu mon écran 5 pouces et arduino due. Il sera le slave, uniquement pour l'affichage et le STM32 gerera tout le reste (codeur/timer/ clavier etc). je recois le F446RE d'ici la fin de la semaine et j'aurais tout l'équipement définitif
V
vres
Compagnon
le F4 a une FPU, il faut juste vérifier quelle est bien activée.
O
Otatiaro
Compagnon
Si 3000rpm avec 2500ppr, ça fait 10000 incréments par tour (en prenant tous les fronts), soit 500KHz de fréquence max.
En mode encodeur ça devrait passer, par contre en polling ou interruption, ce n'est même pas la peine d'y penser.
Avantage, avec un timer 32 bits on a quand même à pleine vitesse (3000rpm) plus d'une heure avant d'avoir un dépassement !
Alors qu'avec un 16 bits, on a un dépassement toutes les 65.5ms (15Hz) !
Il me faudrait le pas mini que tu veux faire, et le nombre de pas par mm pour le PaP de sortie, ce qui va donner le ratio entre la position de la broche et la position du moteur de sortie.
De l'autre côté, quelle vitesse max (400rpm?) et quel pas max ? (ce qui donnera l'erreur maxi pour un délai de 1ms). Sachant qu'il y a quand même une bonne continuité sur le système (il ne passe pas de 0 à 400rpm en 1ms ...). D'ailleurs ça serait bien d'avoir aussi la bande passante mécanique (quelle accélération / décélération maxi sur la broche).
Avec tout ça on pourra dimensionner le système.
Par contre vu la simplicité des calculs, si le STM32 ne fait que ça, un F446 c'est TRES LARGEMENT overkill ... un petit F031 ferait largement l'affaire !
Sur un F401 @ 84MHz on fait toute la fusion 9 axes et les PID + application des différents modèles de pré-compensations pour un quadcoptère de course à 8000Hz !!!!! Et encore il se tourne les pouces la moitié du temps.
Thomas.
En mode encodeur ça devrait passer, par contre en polling ou interruption, ce n'est même pas la peine d'y penser.
Avantage, avec un timer 32 bits on a quand même à pleine vitesse (3000rpm) plus d'une heure avant d'avoir un dépassement !
Alors qu'avec un 16 bits, on a un dépassement toutes les 65.5ms (15Hz) !
Il me faudrait le pas mini que tu veux faire, et le nombre de pas par mm pour le PaP de sortie, ce qui va donner le ratio entre la position de la broche et la position du moteur de sortie.
De l'autre côté, quelle vitesse max (400rpm?) et quel pas max ? (ce qui donnera l'erreur maxi pour un délai de 1ms). Sachant qu'il y a quand même une bonne continuité sur le système (il ne passe pas de 0 à 400rpm en 1ms ...). D'ailleurs ça serait bien d'avoir aussi la bande passante mécanique (quelle accélération / décélération maxi sur la broche).
Avec tout ça on pourra dimensionner le système.
Par contre vu la simplicité des calculs, si le STM32 ne fait que ça, un F446 c'est TRES LARGEMENT overkill ... un petit F031 ferait largement l'affaire !
Sur un F401 @ 84MHz on fait toute la fusion 9 axes et les PID + application des différents modèles de pré-compensations pour un quadcoptère de course à 8000Hz !!!!! Et encore il se tourne les pouces la moitié du temps.
Thomas.
O
Otatiaro
Compagnon
Question, en pratique je ne vois pas la différence entre le mode filetage et le mode avance auto.
On parle toujours en terme d'avance en mm/tour de broche non ?
Ou alors l'avance auto est donnée en mm par unité de temps ?
Si c'est en mm par tour c'est la même chose qu'un filetage, simplement avec une avance par tour beaucoup plus faible, non ? Auquel cas qui peut le plus peut le moins, si tu tiens le filetage à pleine vitesse alors ton avance c'est un filetage à pas très fin, j'ai bon ?
Thomas.
On parle toujours en terme d'avance en mm/tour de broche non ?
Ou alors l'avance auto est donnée en mm par unité de temps ?
Si c'est en mm par tour c'est la même chose qu'un filetage, simplement avec une avance par tour beaucoup plus faible, non ? Auquel cas qui peut le plus peut le moins, si tu tiens le filetage à pleine vitesse alors ton avance c'est un filetage à pas très fin, j'ai bon ?
Thomas.
V
vibram
Compagnon
Peut on switcher sur l'autre conversation pour la suite? histoire de tout reunir sur un post ?
Pour la différence entre avance auto et filetage, c'est juste qu'il n'y a pas d'asservissement en position mais uniquement en vitesse
Et les infos à rentrer par l'utilisateur sont légerement différentes, meme si derriere on doit pouvoir gérer ca plus ou moins de la meme maniere. je n'en suis pas encore là
Concernant le choix du MCU, c'était volontaire de voir gros pour juste combler des lacunes en terme d'optimisation.
Justement c'est pour cela que @saci (de memoire) avait proposé cette version du code (cf l'autre post) pour eviter tout dépassement dans la durée.
Je pense que du 0.3 ou 0.4mm c'est deja assez petit
Pour la résolution moteur, je suis sur une vis au pas de 2mm. Concernant les stepper, la plupart sont en 400ppr de memoire (mon stepper de test qui n'es tpas adapté était en 250ppr que javais mis en demi step donc 500ppr) et je n'exclue pas de faire des demi step voire plus. C'etait le genre de détail important que je voulais regler lors de tests réels.
Mais je te conseille de lire la longue discussion sur l'autre post ou on aborde deja pas mal cela.
Je n'ai pas encore rentré de parametre de backlash, d'erreur maxi etc, chaque chose en son temps
Pour la différence entre avance auto et filetage, c'est juste qu'il n'y a pas d'asservissement en position mais uniquement en vitesse
Et les infos à rentrer par l'utilisateur sont légerement différentes, meme si derriere on doit pouvoir gérer ca plus ou moins de la meme maniere. je n'en suis pas encore là
Concernant le choix du MCU, c'était volontaire de voir gros pour juste combler des lacunes en terme d'optimisation.
Justement c'est pour cela que @saci (de memoire) avait proposé cette version du code (cf l'autre post) pour eviter tout dépassement dans la durée.
Je pense que du 0.3 ou 0.4mm c'est deja assez petit
Pour la résolution moteur, je suis sur une vis au pas de 2mm. Concernant les stepper, la plupart sont en 400ppr de memoire (mon stepper de test qui n'es tpas adapté était en 250ppr que javais mis en demi step donc 500ppr) et je n'exclue pas de faire des demi step voire plus. C'etait le genre de détail important que je voulais regler lors de tests réels.
Mais je te conseille de lire la longue discussion sur l'autre post ou on aborde deja pas mal cela.
Je n'ai pas encore rentré de parametre de backlash, d'erreur maxi etc, chaque chose en son temps
J
jms
Compagnon
Sujets fusionnés.
Je rappelle que poser la même question dans 2 sujets différents est à proscrire comme il est précisé dans les règles.
Bonne continuation.
Je rappelle que poser la même question dans 2 sujets différents est à proscrire comme il est précisé dans les règles.
Bonne continuation.
G
gaston48
Compagnon
Attention, il faut que tu reproduises les séquences pratiquées en manuel ou sur CNC.
Quand tu reprends une passe de chariotage, tu n'as pas d'obligation de retomber dans le pas de chariotage.
En filetage, tu t''arrêtes sur une butée, tu recules l'outil puis le traînard, tu te repositionnes en début de
filetage, tu plonges l'outil pour la passe suivante et tu redémarres le filetage dans la trace du précédent,
donc obligation d’acquérir un top de synchronisme, par tour de broche
V
vibram
Compagnon
Exactement je parlais du mode avances auto là.
Pour le moment je fonctionne de la manière suivante : lorsque j'arrive au bout du filetage on doit pouvoir arrêter le moteur, j'appuie sur le bouton retour et le chariot fait le chemin inverse d'un nombre de tour entier. C'est la ou je dois vérifier ma théorie mais je suis parti du principe que le nombre de tour entier permettait de retomber dans le pas mais ce n'est pas forcément le cas. C'est encore un point à vérifier.
Le problème c'est que je développe ça dans mon appartement sans tour, donc c'est pas terrible. Je pense continuer le développement avec l écran etc pour avoir une interface graphique correcte et d'ici 12 mois je devrais être dans une maison avec un garage et le tour à portée de main
G
gaston48
Compagnon
Si tu interromps le flux entre la broche et la vis d'avance, il faut tout reprendre à zéro.
Dans un cycle G de filetage, à la fin de la passe, le synchronisme est coupé, la séquence
repositionne l'outil à l'origine précédente et attend le premier top de broche,
elle se remet exactement dans les conditions de la première passe qui attend son top de broche aussi
C'est la même démarche qu'en manuel avec la méthode "filetage aux repères"
Tant qu'à faire, il ne faut pas interrompre la rotation de la broche sauf volontairement
pour une prise de mesure ou en cour de cycle pour positionner axialement l'outil dans
un filetage à reprendre.
(Il vaut mieux prévoir dans le CDC tous les cas de figure rencontré à l'occasion d'un filetage)
V
vibram
Compagnon
Suite à relecture du sujet qui commence à dater, on parle ici du fonctionnement du codeur afin de s'assurer qu'il n'y aura pas de dépassement:
https://www.usinages.com/threads/filetage-avec-microcontrolleur.101117/page-13
Donc concernant le déplacement c'est OK, pas de souci.
Pour le moment, pour me simplifier la tache, je n'avais reflechi qu'à la possibilité d'arreter la broche, retour en position 0 du chariot, puis relancer la broche et le chariot suit de nouveau. J'avais deja inclu un systeme de butée soft pour que justement l'outil ne vienne pas en colision, et ca fonctionne pas trop mal.
Mais il est vrai que prévoir le cas ou la broche tourne constament est nécessaire, et ca je vais devoir le prendre en compte dans le code, pas si evident ... ! surtout que cela remet en cause tout le fonctionnement de ma fonction "retour" je vais y reflechir
https://www.usinages.com/threads/filetage-avec-microcontrolleur.101117/page-13
Donc concernant le déplacement c'est OK, pas de souci.
Pour le moment, pour me simplifier la tache, je n'avais reflechi qu'à la possibilité d'arreter la broche, retour en position 0 du chariot, puis relancer la broche et le chariot suit de nouveau. J'avais deja inclu un systeme de butée soft pour que justement l'outil ne vienne pas en colision, et ca fonctionne pas trop mal.
Mais il est vrai que prévoir le cas ou la broche tourne constament est nécessaire, et ca je vais devoir le prendre en compte dans le code, pas si evident ... ! surtout que cela remet en cause tout le fonctionnement de ma fonction "retour" je vais y reflechir
O
Otatiaro
Compagnon
Salut,
@vibram je viens d'aller voir le post concernant les dépassements, et je ne suis pas complètement d'accord ... certes dans 99.9% des cas ça va marcher, d'autant plus que en fonctionnement on va souvent tourner en continu dans le même sens.
Mais le problème potentiel est en cas d'arrêt juste à l'endroit ou il y a le dépassement ... même à l'arrêt avec les vibrations et autres, vu la résolution du capteurs de broche, il va passer son temps à varier de quelques pas. Si on est pile sur la jonction (dépassement), l'interruption risque de se produire très rapidement, hors une interruption à une latence, et le tail-chaining ne permettra pas de détecter qu'un autre dépassement s'est produit avant qu'on ait fini de traiter le précédent.
Si ça se produit quand on remet le chariot en place pour la passe suivante, on ne retombera pas dans le pas.
Le seul moyen d'être sur c'est d'utiliser un timer sur 32 bits (ou un FPGA, mais c'est une autre histoire).
Comme le circuit n'est pas encore figé, tu peux basculer sur TIM2 ou TIM5, ça ne coûte rien et te résoudra pas mal de soucis potentiels.
Pour le ratio, admettons que tu utilises un driver avec du microstep "moyen", disons 1/16, un stepper normal c'est 200 pas par tour, donc en 1/16 on se retrouve à 3200 step par tour, et la vis de sortie fait 2mm par tour, soit 0.625µm par pas (1600 pas par mm), la résolution est correcte (résolution != précision je le rappelle ...)
Pour un pas de 0.3mm, sur un tour de broche (10000 steps d'entrée), on devra faire 480 steps en sortie, le ratio est assez sympa (on est environ à 20:1).
Pour un pas max à vitesse max, si on part sur 2mm par tour, à une vitesse de 400rpm à la broche (je prend les infos au dessus pour le "worst case"), on fait 3200 pas en sortie pour 10000 en entrée (ratio pas mal de l'ordre de 3:1), et la fréquence de sortie sera de l'ordre de 21KHz, c'est raisonnable.
Ce qui fait que pour 1ms dans le worst case, on a au pire des cas (ce qui est impossible, à moins que la broche s'arrête en moins de 1ms ...) 21 steps de retard, soit 13.125µm. En pratique vu qu'on a seulement une ms de retard, le décalage réaliste probable est de l'ordre de quelques micron au maximum, soit bien en dessous de la précision espérée du système.
En mode avance, j'ai regardé à droite à gauche, je trouve des valeur d'avance par dent de 0.03mm à 0.6mm. En worst case 0.6mm à 3000rpm, on doit avancer à 30mm/s soit 48KHz de vitesse de step en sortie. Encore une fois ce sont des fréquences de l'ordre du raisonnable pour ce genre de matériel (à voir la fréquence maxi en entrée du driver, les "vrais" drivers montent souvent à 100, 200 voir 500KHz, les drivers type imprimante 3D sont plus limités). La vitesse du stepper serait alors de 15 tours par seconde ou 900 rpm. On considère qu'un stepper est utilisable grosso modo jusqu'à 1000rpm donc on est bon, à condition que le système vis/écrou ne frotte pas trop à ces vitesses.
Bref rien de compliqué
Thomas.
@vibram je viens d'aller voir le post concernant les dépassements, et je ne suis pas complètement d'accord ... certes dans 99.9% des cas ça va marcher, d'autant plus que en fonctionnement on va souvent tourner en continu dans le même sens.
Mais le problème potentiel est en cas d'arrêt juste à l'endroit ou il y a le dépassement ... même à l'arrêt avec les vibrations et autres, vu la résolution du capteurs de broche, il va passer son temps à varier de quelques pas. Si on est pile sur la jonction (dépassement), l'interruption risque de se produire très rapidement, hors une interruption à une latence, et le tail-chaining ne permettra pas de détecter qu'un autre dépassement s'est produit avant qu'on ait fini de traiter le précédent.
Si ça se produit quand on remet le chariot en place pour la passe suivante, on ne retombera pas dans le pas.
Le seul moyen d'être sur c'est d'utiliser un timer sur 32 bits (ou un FPGA, mais c'est une autre histoire).
Comme le circuit n'est pas encore figé, tu peux basculer sur TIM2 ou TIM5, ça ne coûte rien et te résoudra pas mal de soucis potentiels.
Pour le ratio, admettons que tu utilises un driver avec du microstep "moyen", disons 1/16, un stepper normal c'est 200 pas par tour, donc en 1/16 on se retrouve à 3200 step par tour, et la vis de sortie fait 2mm par tour, soit 0.625µm par pas (1600 pas par mm), la résolution est correcte (résolution != précision je le rappelle ...)
Pour un pas de 0.3mm, sur un tour de broche (10000 steps d'entrée), on devra faire 480 steps en sortie, le ratio est assez sympa (on est environ à 20:1).
Pour un pas max à vitesse max, si on part sur 2mm par tour, à une vitesse de 400rpm à la broche (je prend les infos au dessus pour le "worst case"), on fait 3200 pas en sortie pour 10000 en entrée (ratio pas mal de l'ordre de 3:1), et la fréquence de sortie sera de l'ordre de 21KHz, c'est raisonnable.
Ce qui fait que pour 1ms dans le worst case, on a au pire des cas (ce qui est impossible, à moins que la broche s'arrête en moins de 1ms ...) 21 steps de retard, soit 13.125µm. En pratique vu qu'on a seulement une ms de retard, le décalage réaliste probable est de l'ordre de quelques micron au maximum, soit bien en dessous de la précision espérée du système.
En mode avance, j'ai regardé à droite à gauche, je trouve des valeur d'avance par dent de 0.03mm à 0.6mm. En worst case 0.6mm à 3000rpm, on doit avancer à 30mm/s soit 48KHz de vitesse de step en sortie. Encore une fois ce sont des fréquences de l'ordre du raisonnable pour ce genre de matériel (à voir la fréquence maxi en entrée du driver, les "vrais" drivers montent souvent à 100, 200 voir 500KHz, les drivers type imprimante 3D sont plus limités). La vitesse du stepper serait alors de 15 tours par seconde ou 900 rpm. On considère qu'un stepper est utilisable grosso modo jusqu'à 1000rpm donc on est bon, à condition que le système vis/écrou ne frotte pas trop à ces vitesses.
Bref rien de compliqué
Thomas.
V
vres
Compagnon
Plutôt que de gérer le dépassement par une interruption on peut faire beaucoup plus simple.
Ici on est en 8 bits mais on peut convertir facilement en 16 bits.
Ici on est en 8 bits mais on peut convertir facilement en 16 bits.
O
Otatiaro
Compagnon
@CNCSERV j'ai pas le temps de le triturer dans tous les sens mais pour le coup si on garanti qu'il ne peut y avoir pas de la moitié de la valeur max écoulée entre 2 lectures successives, ça me semble robuste (une seule lecture de la valeur).
Pour 16 bits on avait calculé 65ms de temps de dépassement à pleine vitesse ... si on poll à 1000Hz (1ms) on est bon en théorie.
Thomas.
Pour 16 bits on avait calculé 65ms de temps de dépassement à pleine vitesse ... si on poll à 1000Hz (1ms) on est bon en théorie.
Thomas.
V
vibram
Compagnon
Pour le moment je vais choisir la facilité et mettre ca sur le timer 32bit.
Une fois fini, je pense faire mon propre PCB et ce n'est clairement pas le cout du MCU qui fera la différence...
En revanche le point soulevé par Gaston m'embete un peu plus.
Je pense que ma routine quand retour ==1 avec le reset de mult1k est fausse car elle ne me permet pas de retomber dans le pas.
A mon avis mon principe de butée logicielle est bonne, il faut juste la regler correctement pour ne pas dépasser la gorge en fin de filetage.
Ensuite, là ou ca se complique c'est si la broche continue de tourner, mon codeur continue de s'incrementer.
Je pense que le mieux est de remettre le compteur à 0 lorsque l'outil est à la position 0 et que cela devienne mon point de référence.
Voila ma reflexion mais je ne sais pas si elle est correcte:
Si je divise ma valeur codeur par la definition de la broche, j'obtiens mon nombre de tours réalisés. Je multiplie par le pas j'arrive à ma position d'outil théorique.
Je pense que pour re commencer dans le pas, je dois remettre mon outil à 0 et attendre que la distance théorique /pas donne un chiffre entier. Cela vous paraît juste ?
En plus de ne pas être sur, je ne vois surtout pas comment faire au niveau software. Car il faut que je rentre dans ma boucle d asservissement mais du coup je dois changer la valeur de la position broche pour la remettre comme en début de filetage. Je ne suis pas très clair je pense...!
Une fois fini, je pense faire mon propre PCB et ce n'est clairement pas le cout du MCU qui fera la différence...
En revanche le point soulevé par Gaston m'embete un peu plus.
Je pense que ma routine quand retour ==1 avec le reset de mult1k est fausse car elle ne me permet pas de retomber dans le pas.
A mon avis mon principe de butée logicielle est bonne, il faut juste la regler correctement pour ne pas dépasser la gorge en fin de filetage.
Ensuite, là ou ca se complique c'est si la broche continue de tourner, mon codeur continue de s'incrementer.
Je pense que le mieux est de remettre le compteur à 0 lorsque l'outil est à la position 0 et que cela devienne mon point de référence.
Voila ma reflexion mais je ne sais pas si elle est correcte:
Si je divise ma valeur codeur par la definition de la broche, j'obtiens mon nombre de tours réalisés. Je multiplie par le pas j'arrive à ma position d'outil théorique.
Je pense que pour re commencer dans le pas, je dois remettre mon outil à 0 et attendre que la distance théorique /pas donne un chiffre entier. Cela vous paraît juste ?
En plus de ne pas être sur, je ne vois surtout pas comment faire au niveau software. Car il faut que je rentre dans ma boucle d asservissement mais du coup je dois changer la valeur de la position broche pour la remettre comme en début de filetage. Je ne suis pas très clair je pense...!
G
gaston48
Compagnon
Je verrais un interface comme ça:
Je rentre:
-la longueur de filetage plus une amorce à vide.
l'amplitude du mouvement de l'outil ne sortira pas des 2 bornes de cette distance Z.
A moi de choisir la longueur d'amorce plus celle du filetage et une demi largeur de gorge s'il y a et de positionner correctement
l'outil en début d'amorce avec une sorte de jog. Comme la broche est déjà en rotation, l'amorce permet d'encaisser
une phase d'accélération du moteur de vis suite à l'impulsion index de la broche
-le pas (éventuellement un nombre de filet pour un pas rapide).
Je dispose de 2 boutons distincts: un start filetage et un bouton retour.
-Ma broche tourne, mon outil est bien positionné à l'origine Z = 0.
-Je donne une impulsion start, un cycle filetage synchronisé démarre, je peux stopper la broche ou pas mais
je commence par tangenter pour ma profondeur de filetage ... j'arrive à Z = course - delta, ici la synchronisation se coupe
pour amorcer une phase de décélération du moteur de vis et son arrêt à Z = course. Cette phase est confiné dans la gorge
ou en cour d'usinage, l'outil à fileter fera progressivement une gorge triangulaire précédé par une fin de filet courbe.
-je recule mon outil.
-je donne une impulsion retour, le moteur de vis repositionne le Z à 0
-je plonge l'outil de ma prise de passe.
-Je donne une impulsion start, un cycle filetage synchronisé démarre
etc
etc ...
La réalisation du pas rapide à plusieurs filets serait obtenu par un décalage à partir de l'impulsion d'index
actionné à chaque passe ou actionné à la fin d'usinage de chaque filet.
le sous programme de synchronisation est appelé, après réinitialisation complète, par l'appui sur start
pas de risque de dépassement compteur ou autre décalage.
edit ...
j'oubliais la possibilité de rentrer des passes latérales par décalage du Z=0 par exemple
qui sont dans le contexte d'une vis à plusieurs filets aussi, mais un décalage d'une vis
à plusieurs filet au module, c'est un nombre réel à rentrer, il serait plus pratique de rentrer un retard angulaire
de l'index
Je rentre:
-la longueur de filetage plus une amorce à vide.
l'amplitude du mouvement de l'outil ne sortira pas des 2 bornes de cette distance Z.
A moi de choisir la longueur d'amorce plus celle du filetage et une demi largeur de gorge s'il y a et de positionner correctement
l'outil en début d'amorce avec une sorte de jog. Comme la broche est déjà en rotation, l'amorce permet d'encaisser
une phase d'accélération du moteur de vis suite à l'impulsion index de la broche
-le pas (éventuellement un nombre de filet pour un pas rapide).
Je dispose de 2 boutons distincts: un start filetage et un bouton retour.
-Ma broche tourne, mon outil est bien positionné à l'origine Z = 0.
-Je donne une impulsion start, un cycle filetage synchronisé démarre, je peux stopper la broche ou pas mais
je commence par tangenter pour ma profondeur de filetage ... j'arrive à Z = course - delta, ici la synchronisation se coupe
pour amorcer une phase de décélération du moteur de vis et son arrêt à Z = course. Cette phase est confiné dans la gorge
ou en cour d'usinage, l'outil à fileter fera progressivement une gorge triangulaire précédé par une fin de filet courbe.
-je recule mon outil.
-je donne une impulsion retour, le moteur de vis repositionne le Z à 0
-je plonge l'outil de ma prise de passe.
-Je donne une impulsion start, un cycle filetage synchronisé démarre
etc
etc ...
La réalisation du pas rapide à plusieurs filets serait obtenu par un décalage à partir de l'impulsion d'index
actionné à chaque passe ou actionné à la fin d'usinage de chaque filet.
le sous programme de synchronisation est appelé, après réinitialisation complète, par l'appui sur start
pas de risque de dépassement compteur ou autre décalage.
edit ...
j'oubliais la possibilité de rentrer des passes latérales par décalage du Z=0 par exemple
qui sont dans le contexte d'une vis à plusieurs filets aussi, mais un décalage d'une vis
à plusieurs filet au module, c'est un nombre réel à rentrer, il serait plus pratique de rentrer un retard angulaire
de l'index
Dernière édition:
V
vibram
Compagnon
Bonjour gaston,
J'ai bien lu ton intervention très pertinente.
je pense que je vais essayer de m'en approcher tout en modifiant quelques points notamment car je ne saurais pas les coder (au moins dans un premier temps).
Apres avoir pas mal réfléchi, je pense faire ainsi:
Si la broche tourne toujours pendant toutes les opérations suivantes:
1. Reglage de la butée min et max -> existe deja dans le code
2. Prévoir une distance entre la position mini de l'outil et le début du filetage pour le reglage de la position du moteur mais je ne précise pas la longueur (à voir dans le futur si je peux modifier) -> existe deja dans le code
3. Lors de l'appui sur start, si c'est la premiere passe, je remets le codeur à 0 et je commence à fileter -> je dois ajouter un bouton, la necessité de devoir appuyer et la remise à 0 du compteur
4. L'outil arrive en butée soft le moteur PAP s'arrete -> existe deja dans le code
5. On sort l'outil -> opération manuelle
6. On appuie sur retour et l'outil revient en position 0 -> je dois modifier tres légerement le code
7. On appuie sur start : c'est là ou je dois pas me planter. Admettons que la broche ait fait 551 tours + 500 impulsions (concrettement je serai à 5'510'500 impulsions, hypothese codeur = 10'000 ppr)
Je remets mon nombre de tours à 0 donc 5'510'500 modulo 10'000 = 500 pulses
Il faut donc que sur la distance entre la position 0 de l'outil et le debut du filetage, le moteur rattrape la position théorique de l'outil ratrape la position de la broche et ensuite mon code fonctionne normalement.
le code est fait de telle maniere que le moteur va tourner plus vite au debut pour trapper les pas et une fois ces pas rattrapés, il sera asservi à la broche.
je dois donc faire attention:
1. à ce que la vitesse et l'acceleration ne soient pas trop importante pour le PAP, et meme en vitesse de filetage, ce n'est pas gagné !
2. A l'écart que je vais avoir au moment ou je calcule mon modulo, je me demande si je ne vais pas avoir une erreur de poursuite. j'ai du mal à m'en rendre compte. je pense que je verrai ca en fonction des tests ...!
8. On recommence le cycle et ainsi de suite.
Je dois inclure le backlash mais cela ne devrait pas être le plus dur.
Et aussi inclure un décalage du Z pour ceux qui n'usinent pas les deux flancs à chaque passe.
Je n'ai pas encore réfléchi au cas d'une vis à plusieurs filets. je pense faire étape par étape mais comme ca, je me dit qu'il suffit d'inclure une variable que l'on ajoute au codeur pour décaler le début du filetage sur la pièce. En théorie ca doit être ca.
Mon raisonnement vous parait bon?
J'ai bien lu ton intervention très pertinente.
je pense que je vais essayer de m'en approcher tout en modifiant quelques points notamment car je ne saurais pas les coder (au moins dans un premier temps).
Apres avoir pas mal réfléchi, je pense faire ainsi:
Si la broche tourne toujours pendant toutes les opérations suivantes:
1. Reglage de la butée min et max -> existe deja dans le code
2. Prévoir une distance entre la position mini de l'outil et le début du filetage pour le reglage de la position du moteur mais je ne précise pas la longueur (à voir dans le futur si je peux modifier) -> existe deja dans le code
3. Lors de l'appui sur start, si c'est la premiere passe, je remets le codeur à 0 et je commence à fileter -> je dois ajouter un bouton, la necessité de devoir appuyer et la remise à 0 du compteur
4. L'outil arrive en butée soft le moteur PAP s'arrete -> existe deja dans le code
5. On sort l'outil -> opération manuelle
6. On appuie sur retour et l'outil revient en position 0 -> je dois modifier tres légerement le code
7. On appuie sur start : c'est là ou je dois pas me planter. Admettons que la broche ait fait 551 tours + 500 impulsions (concrettement je serai à 5'510'500 impulsions, hypothese codeur = 10'000 ppr)
Je remets mon nombre de tours à 0 donc 5'510'500 modulo 10'000 = 500 pulses
Il faut donc que sur la distance entre la position 0 de l'outil et le debut du filetage, le moteur rattrape la position théorique de l'outil ratrape la position de la broche et ensuite mon code fonctionne normalement.
le code est fait de telle maniere que le moteur va tourner plus vite au debut pour trapper les pas et une fois ces pas rattrapés, il sera asservi à la broche.
je dois donc faire attention:
1. à ce que la vitesse et l'acceleration ne soient pas trop importante pour le PAP, et meme en vitesse de filetage, ce n'est pas gagné !
2. A l'écart que je vais avoir au moment ou je calcule mon modulo, je me demande si je ne vais pas avoir une erreur de poursuite. j'ai du mal à m'en rendre compte. je pense que je verrai ca en fonction des tests ...!
8. On recommence le cycle et ainsi de suite.
Je dois inclure le backlash mais cela ne devrait pas être le plus dur.
Et aussi inclure un décalage du Z pour ceux qui n'usinent pas les deux flancs à chaque passe.
Je n'ai pas encore réfléchi au cas d'une vis à plusieurs filets. je pense faire étape par étape mais comme ca, je me dit qu'il suffit d'inclure une variable que l'on ajoute au codeur pour décaler le début du filetage sur la pièce. En théorie ca doit être ca.
Mon raisonnement vous parait bon?
V
vres
Compagnon
Pour l'instant tu n'as pas intégré accélération? Le calcul de la distance pour atteindre la vitesse constante et simple.
V
vibram
Compagnon
Non j'ai fait plus simple:
En mode filetage, la vitesse de rotation de la broche fait que la vitesse de rotation du PAP est toujours inférieure à l'accélération max
Et en vitesse retour j'ai mis une vitesse constante qui évite aussi le décrochage.
Mais en effet je n'ai rien pour gérer la vitesse lors du rattrapage de position. Et comme c'est géré par la boucle "générale" (le Premier cas dans ce message), je ne vois pas comment gérer cela
V
vres
Compagnon
Je n'ai pas trop compris la problématique, je pensai que c'était pour reprendre le pas avec la broche en rotation.
En mode synchrone, l'accélération de la broche fait aussi l'accélération du moteur.
En mode synchrone, l'accélération de la broche fait aussi l'accélération du moteur.
V
vibram
Compagnon
Oui mais si la broche est toujours en rotation, il n'y a plus de moment d accélération au niveau broche donc je dois faire attention pour le PAP
V
vres
Compagnon
C'est bien ce que j'avais compris.
Sans accélération il faut limiter la vitesse du PàP pour qu'il reste en dessous de la vitesse StartUp même quand il rattrape le pas.
Après il y a t'il besoin de fileter à vitesse rapide? Ajouter l'accélération va quand même beaucoup compliquer les choses.
Sans accélération il faut limiter la vitesse du PàP pour qu'il reste en dessous de la vitesse StartUp même quand il rattrape le pas.
Après il y a t'il besoin de fileter à vitesse rapide? Ajouter l'accélération va quand même beaucoup compliquer les choses.
V
vibram
Compagnon
Oui c'est ce dont on avait déjà parlé sur le sujet je crois et on avait eu les mêmes conclusions.
Après je ne sais pas si l'accélération est aussi problématique sur les servo ? Car je peux mettre un servo en step/dit à la place du PAP par exemple. Ça résoudrait le problème de perte de pas mais je ne sais pas concernant le décrochage à l accélération? C'est un point à regarder.
Je vais avoir un entraînement par courroie cranter donc je peux facilement doubler le couple avec la taille des poulies mais je serai limité en vitesse de déplacement mais cela ne devrait pas être un problème ? C'est aussi à prendre en compte
Après je ne sais pas si l'accélération est aussi problématique sur les servo ? Car je peux mettre un servo en step/dit à la place du PAP par exemple. Ça résoudrait le problème de perte de pas mais je ne sais pas concernant le décrochage à l accélération? C'est un point à regarder.
Je vais avoir un entraînement par courroie cranter donc je peux facilement doubler le couple avec la taille des poulies mais je serai limité en vitesse de déplacement mais cela ne devrait pas être un problème ? C'est aussi à prendre en compte
G
gaston48
Compagnon
Je remets ici le G76 dans sa version complète:
http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g76
les sources de l'interpréteur sont normalement publiées, mais je ne rien trouvé ou compris ...
https://github.com/LinuxCNC/linuxcnc/tree/master/src/emc/rs274ngc
http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g76
les sources de l'interpréteur sont normalement publiées, mais je ne rien trouvé ou compris ...
https://github.com/LinuxCNC/linuxcnc/tree/master/src/emc/rs274ngc
V
vibram
Compagnon
Je vais essayer de trouver des infos sur le github mais je n'ai jamais été très doué pour comprendre le code comme ça.
En revanche après une petite nuit, je me dis que de prendre un servo avec un driver qui va gérer l'accélération est une idée qui tient la route.
Il faudrait que je trouve quelqu'un pour tester car je n'en ai pas sous la main mais si on envoie un signal pour tourner directement à 3000 rpm, je pense que la plupart des drivers vont gérer le cycle d accélération. Et ainsi comme a dit @CNCSERV je n'aurais plus qu'à calculer la distance nécessaire à l'accélération pour une vitesse max et comme ça je serai tranquille
C'est un peu prendre une masse pour écraser une mouche mais sinon c'est compliqué...
En revanche après une petite nuit, je me dis que de prendre un servo avec un driver qui va gérer l'accélération est une idée qui tient la route.
Il faudrait que je trouve quelqu'un pour tester car je n'en ai pas sous la main mais si on envoie un signal pour tourner directement à 3000 rpm, je pense que la plupart des drivers vont gérer le cycle d accélération. Et ainsi comme a dit @CNCSERV je n'aurais plus qu'à calculer la distance nécessaire à l'accélération pour une vitesse max et comme ça je serai tranquille
C'est un peu prendre une masse pour écraser une mouche mais sinon c'est compliqué...
G
gaston48
Compagnon
Finalement, gérer une phase d'accélération ne doit pas être si complexe et elle peut être très reproductible,
c'est ce qui compte après une première passe de filetage.
Il "suffit" , après l'impulsion d'index de ne prendre en compte qu' 1 impulsion du codeur sur 10, puis 1 sur 9 et ainsi de suite
jusqu'au synchronisme 1 pour 1 (indépendamment du calcul du ratio) .
idem pour le freinage.
c'est ce qui compte après une première passe de filetage.
Il "suffit" , après l'impulsion d'index de ne prendre en compte qu' 1 impulsion du codeur sur 10, puis 1 sur 9 et ainsi de suite
jusqu'au synchronisme 1 pour 1 (indépendamment du calcul du ratio) .
idem pour le freinage.
V
vres
Compagnon
Si tu as la vitesse de broche, la longueur d'amorçage tu peux facilement pré-calculer :
- la vitesse du moteur PàP a atteindre donc l'accélération.
- Avec l'accélération et la vitesse tu peux calculer le temps d'accélération,
- Avec temps et la vitesse de broche tu peux calculer le nombre de degrés broche a parcourir pendant la phase d'amorçage.
Pendant la phase de démarrage il faut faire le contraire : en fonction du nombre de dégrés restants à parcourir, tu détermine le temps
donc tu peux calculer la distance d'amorce restante donc la position du moteur et/ou la vitesse du moteur.
Si la distance et plus interessante a calculer, elle nécessite une racine², il vaut mieux travailler avec la vitesse.
Pour être précis le calcul doit être fais sur chaque cycle d'horloge.
Pour éviter les complications et les problémes de dépassement ( valeurs au ²) il est presque impératif de travailler en flottants. Donc un F4 obligatoire.
On peux aussi travailler avec des tableaux précalculés, mais c'est quand même plus compliqué a comprendre. Je ne suis pas certain que la différence de prix justifie cette complication.
- la vitesse du moteur PàP a atteindre donc l'accélération.
- Avec l'accélération et la vitesse tu peux calculer le temps d'accélération,
- Avec temps et la vitesse de broche tu peux calculer le nombre de degrés broche a parcourir pendant la phase d'amorçage.
Pendant la phase de démarrage il faut faire le contraire : en fonction du nombre de dégrés restants à parcourir, tu détermine le temps
donc tu peux calculer la distance d'amorce restante donc la position du moteur et/ou la vitesse du moteur.
Si la distance et plus interessante a calculer, elle nécessite une racine², il vaut mieux travailler avec la vitesse.
Pour être précis le calcul doit être fais sur chaque cycle d'horloge.
Pour éviter les complications et les problémes de dépassement ( valeurs au ²) il est presque impératif de travailler en flottants. Donc un F4 obligatoire.
On peux aussi travailler avec des tableaux précalculés, mais c'est quand même plus compliqué a comprendre. Je ne suis pas certain que la différence de prix justifie cette complication.
G
gaston48
Compagnon
Le problème est qu'il fait être très reproductible après le top index, qu'on tourne la broche à la main
au début ou qu'elle soit en régime " de croisière ". Comme tu dis, on ne va pas fileter à grande vitesse, donc
ce serait un compromis entre un couplage direct start / stop et une accélération toujours recalculée
au début ou qu'elle soit en régime " de croisière ". Comme tu dis, on ne va pas fileter à grande vitesse, donc
ce serait un compromis entre un couplage direct start / stop et une accélération toujours recalculée
V
vres
Compagnon
Si on travail avec la position angulaire de la broche il n'y a pas de problème.
Si tu connais la position en degré du filetage et la position de moteur pas à pas, la synchronisation sur la phase d'amorçage est facile et très précise.
En pilotage d'axe, en fonction de la distance restant à parcourir il faut calculer la vitesse maximum possible pour anticiper la décélération.
C'est le même principe.
Plus la distance d'amorçage est longue et plus tu pourras tourner vite. Si elle est nulle on aura pas de phase d'accélération donc le moteur PàP doit rester en dessous de sa vitesse StartUp (ou start/stop).
Si tu connais la position en degré du filetage et la position de moteur pas à pas, la synchronisation sur la phase d'amorçage est facile et très précise.
En pilotage d'axe, en fonction de la distance restant à parcourir il faut calculer la vitesse maximum possible pour anticiper la décélération.
C'est le même principe.
Plus la distance d'amorçage est longue et plus tu pourras tourner vite. Si elle est nulle on aura pas de phase d'accélération donc le moteur PàP doit rester en dessous de sa vitesse StartUp (ou start/stop).
Dernière édition:
Sujets similaires
Dépannage
HBX360 - Problème hydraulique
-
caramel
- Tours
-
Doctor_itchy
- Arduino