Broche ATC-800W ISO-10
Bonjour à tous, Je crée ce sujet pour vous présenter "l'aboutissement" d'un projet sur lequel je travail petit à petit depuis plus d'un an. Il s'agit d'une broche d'usinage à changement d'outil automatique de ma conception. Quelques caractéristiques : - Puissance 800W - Fréquence 0-400Hz soit...
www.usinages.com
Effectivement, au début j’étais partie sur un HSK pour cette raison.
j’ai vu qu’on peut avoir des pinces avec un runout dans des tolerances plus faible
Pince faible run out j’ai changer d’avis pour des raisons de coût du HSK
Dernière édition:
Le projet continu d'avancer plutôt bien.
Mais je suis en plein doute.
J'avais déjà beaucoup hésité au moment du set-up; servo moteur, linuxcnc et carte.
Les doutes sont revenu de plus belle au moment de finaliser la partie électronique.
Voici mon problème j'ai les servo qui sont piloté en +/-10v par une carte Mesa 7i77 et l'asservissement en position qui est réalisé dans Linuxcnc.
Mes drives Yaskawa peuvent être piloté en STEP/DIR donc pour avoir de meilleur performance c'est pas mieux de faire l'asservissement en position dans le drive ? Mais est-ce que la synchronisation entre les axes reste performante comme chacun travail dans son coin...
Et il y a une nouvelle carte qui est sortie; la 7i95 qui permettrai de commander les drives en STEP/DIR plus faire un retour à linuxcnc de la position réel. Autre question il y a un intérêt avec cette configuration de faire un asservissement position dans le drive et un asservissement en position dans linuxcnc ??
En plus les drive Yaskawa possède pas mal de fonction anti-vibration et autre. Donc au final comment obtenir la configuration la plus performante en terme de précision et en qualité de surface
Kio
Mais je suis en plein doute.
J'avais déjà beaucoup hésité au moment du set-up; servo moteur, linuxcnc et carte.
Les doutes sont revenu de plus belle au moment de finaliser la partie électronique.
Voici mon problème j'ai les servo qui sont piloté en +/-10v par une carte Mesa 7i77 et l'asservissement en position qui est réalisé dans Linuxcnc.
Mes drives Yaskawa peuvent être piloté en STEP/DIR donc pour avoir de meilleur performance c'est pas mieux de faire l'asservissement en position dans le drive ? Mais est-ce que la synchronisation entre les axes reste performante comme chacun travail dans son coin...
Et il y a une nouvelle carte qui est sortie; la 7i95 qui permettrai de commander les drives en STEP/DIR plus faire un retour à linuxcnc de la position réel. Autre question il y a un intérêt avec cette configuration de faire un asservissement position dans le drive et un asservissement en position dans linuxcnc ??
En plus les drive Yaskawa possède pas mal de fonction anti-vibration et autre. Donc au final comment obtenir la configuration la plus performante en terme de précision et en qualité de surface
Kio
Dans le doute il faut utiliser les entrées step/dir des variateurs car tu peux les piloter ainsi soit en mode position soit vitesse.
Perso je préfère piloter mes servos Yaskawa en position, c'est le seul moyen de profiter de toutes les fonctionnalités avancées du servo.
Je n'ai pas trouvé de carte idéale chez Mesa pour connecter 4 servos en step/dir + les retours codeurs, du coup je me suis fait une carte sur mesure. En bonus le cablage des servos sera un vrai plaisir...
Perso je préfère piloter mes servos Yaskawa en position, c'est le seul moyen de profiter de toutes les fonctionnalités avancées du servo.
Je n'ai pas trouvé de carte idéale chez Mesa pour connecter 4 servos en step/dir + les retours codeurs, du coup je me suis fait une carte sur mesure. En bonus le cablage des servos sera un vrai plaisir...
Dernière édition:
cela vaudrait le coup que tu partages ton travail plus en détail dans un nouveau sujet non? cela risque d'interesser du monde
J'en parlerai le moment venu dans mon sujet, mais en gros c'est une combinaison de Mesa 7i76+7i85 avec des connecteurs SCSI-50 qu'on retrouve sur les servo-variateurs Yaskawa et autres.cela vaudrait le coup que tu partages ton travail plus en détail dans un nouveau sujet non? cela risque d'interesser du monde
Bonsoir,
Si Kio a déjà investi dans une 5i25+7i77, il peut rajouter aussi une 7i78 pour 4 voies step/dir
le Firmware adapté à ces 2 cartes pour la 5i25 existe
Ensuite les ordres de déplacements sont envoyés dans les module PID dans le cas du +/-10 V
ou dans les générateurs de step/dir
Si Kio a déjà investi dans une 5i25+7i77, il peut rajouter aussi une 7i78 pour 4 voies step/dir
le Firmware adapté à ces 2 cartes pour la 5i25 existe
la synchronisation entre les axes reste uniquement réservé et limité au planificateur de trajectoire.
Ensuite les ordres de déplacements sont envoyés dans les module PID dans le cas du +/-10 V
ou dans les générateurs de step/dir
Merci de vos réponses. Pour bien comprendre; peut-on dire que le PID des drives Yaskawa est-il plus performant que le PID de Linuxcnc ?
Si oui j'ai intérêt de changer ma carte pour une 7i95 à moins que cette magnifique carte de @arba soit bientôt disponible. Je trouve top d'avoir directement les connecteurs SCSI-50 sur la carte. Je ne suis pas très contant de mon câblage sur cette partie
Si oui j'ai intérêt de changer ma carte pour une 7i95 à moins que cette magnifique carte de @arba soit bientôt disponible. Je trouve top d'avoir directement les connecteurs SCSI-50 sur la carte. Je ne suis pas très contant de mon câblage sur cette partie
Ca n'a pas de rapport avec la discussion actuelle, mais tes accouplements sans rigidité torsionnelle,
c'est une erreur, à l'inverse d'une règle optique accouplée au déplacement réel du chariot, ici ton capteur est le codeur
du servomoteur, il est au tout début de la chaine de transmission/ conversion de mouvement .
c'est une erreur, à l'inverse d'une règle optique accouplée au déplacement réel du chariot, ici ton capteur est le codeur
du servomoteur, il est au tout début de la chaine de transmission/ conversion de mouvement .
Pour être honnête, un dès retour d’expérience que je me fait, est le passage à des règles. Je l’ai rajouterai lors de la prochaine construction.
Sur la construction actuelle j’ai pris en compte la torsion de l’accouplement avec le couple maxi du moteur j’obtiens une torsion qui est l’équivalent de moins 0,1um en déplacement. Donc c’est pas la ou je perd le plus. D’ailleurs j’ai eu beaucoup de mal à trouver cette référence.
En prenant en compte les fonctionnalités des servos qui sont disponibles uniquement lorsque contrôlés en mode position je dirais que oui. Autrement il semblerait que ce soit kif-kif:
Puisque tu as déjà le matériel j'essayerais déjà comme ça. Le mieux est l'ennemi du bien
Je n'ai pas l'intention de faire commerce de ma carte sur mesure, mais si elle correspond à ton besoin et que tu es à l'aise avec la soudure je t'envoie volontiers un PCB.
Merci de vos réponses. Pour bien comprendre; peut-on dire que le PID des drives Yaskawa est-il plus performant que le PID de Linuxcnc ?
Si oui j'ai intérêt de changer ma carte pour une 7i95 à moins que cette magnifique carte de @arba soit bientôt disponible. Je trouve top d'avoir directement les connecteurs SCSI-50 sur la carte. Je ne suis pas très contant de mon câblage sur cette partie
Sur les Drives le PID est sur la vitesse alors que sur LinuxCNC il est, il me semble, sur la position.
Avec un asservissement en position sur le drive, il est extrêmement difficile de ne pas avoir d'erreur de poursuite.
Il n'y a pas de configuration définie, tout est possible. La question était justement de fermer la boucle de position dans LinuxCNC ou de laisser le variateur fermer toutes les boucles?
Est-ce que ce sera vraiment le cas en pratique si la boucle de position du variateur est 3x plus rapide que celle de LinuxCNC ? (3kHz vs 1kHz)
A noter qu'il est possible sur les servos en question de les piloter en mode position ET de leur fournir les gains anticipatifs ("feedforward") de vitesse et accélération via les entrées +10V. Ca semble la méthode de contrôle la plus optimale mais la plus compliquée à mettre en oeuvre.
Dernière édition:
je vérifierais l'ordre de grandeur de cette référence, ça ma paraît très peu, la manip avec un bras de levier et des poids est
assez facile à réaliser (d'autant plus qu'à priori, tu as un autre soucis)
Il n'y a pas de différence objective entre l'envoi de commandes par fréquence d'impulsions ou tension analogique. Les deux méthodes permettent d'envoyer une commande au lecteur.
Il peut y avoir un avantage à faire fonctionner le système en mode de contrôle de vitesse, car LinuxCNC peut alors utiliser l'anticipation de vitesse pour améliorer la boucle de contrôle.
Si vous utilisez la boucle de position dans le variateur en mode step / dir, il n'y a aucun moyen de transmettre les informations de vitesse au variateur (la vitesse anticipée est quelque chose que seul LinuxCNC "sait")
Cependant, la boucle de position dans le variateur est probable pour être beaucoup plus rapide que la boucle LinuxCNC, donc tout pourrait s'équilibrer.
Si la boucle de position est dans LinuxCNC, vous pouvez la regarder pour un réglage plus facile.
C'est intéressant ce que relève Andy, à savoir que les actions feed-forward ne peuvent être calculer que par linuxcnc
et les action FF sont primordiales, souvent confirmées par le constructeur de Mesa.
Il faut faire des manip comparatives, donc absolument avoir des entrées codeur pour mesurer les défauts de position
avec " halscop" mais attention tout n'est pas parfait non plus , halscope échantillonne à la fréquence du servo-thread
donc il ne voit pas tout (rien que pour cela je reste pour l'instant en RTAI donc pas de port ethernet, du pcie...)
Dernière édition:
Trouvez moi un drive qui a une boucle sur la position
Si on a un driver piloté en couple on agit surtout sur le PID, si on a un Drive piloté en vitesse on utilise plutôt le FF.
Non c'est 2 choses différentes, le PID et calculé sur un écart de position alors que le FF est calculé sur une vitesse.
La vitesse de la boucle d'asservissement n'est pas très importante, moi j'ai une fréquence d’environ 15kHz mais un filtrage sur 5 cycles qui fait donc 3kHz de bande passante.
Le drive peut très bien connaitre la vitesse est avoir un Feed-forward, il suffit de mesurer la fréquence des pulses, c'est très simple.
Si on a un driver piloté en couple on agit surtout sur le PID, si on a un Drive piloté en vitesse on utilise plutôt le FF.
Non c'est 2 choses différentes, le PID et calculé sur un écart de position alors que le FF est calculé sur une vitesse.
La vitesse de la boucle d'asservissement n'est pas très importante, moi j'ai une fréquence d’environ 15kHz mais un filtrage sur 5 cycles qui fait donc 3kHz de bande passante.
Le drive peut très bien connaitre la vitesse est avoir un Feed-forward, il suffit de mesurer la fréquence des pulses, c'est très simple.
Je te suis pas là... À peu près tous les variateurs relativements récents?Trouvez moi un drive qui a une boucle sur la position
Merci google traduction plutôt
2 Khz plus un microprocesseur 2 cœurs qui pédale
Oui c'est ça :
pid.N.FF0 float in
Zero order feed-forward term. Produces a contribution to the output that is FF0 multiplied by the commanded value. For position loops, it should usually be left at zero. For velocity loops, FF0 can compensate for friction or motor counter-EMF and may permit better tuning if used properly.
pid.N.FF1 float in
First order feed-forward term. Produces a contribution to the output that FF1 multiplied by the derivative of the commanded value. For position loops, the contribution is proportional to speed, and can be used to compensate for friction or motor CEMF. For velocity loops, it is proportional to acceleration and can compensate for inertia. In both cases, it can result in better tuning if used properly.
pid.N.FF2 float in
Second order feed-forward term. Produces a contribution to the output that is FF2 multiplied by the second derivative of the commanded value. For position loops, the contribution is proportional to acceleration, and can be used to compensate for inertia. For velocity loops, it should usually be left at zero.
Avec un ampli parfaitement réglé en mode vitesse que ce soit en analogique ou en digital
Ensuite une bonne valeur de FF1 ça c'est plus de 90 % de bon asservissement.
Ensuite une bonne valeur de d'action proportionnelle P
Et normalement un chouilla de FF2 pour améliorer les erreurs aux transitions, comme un changement de sens
ou tu as du stick slip (je n'y arrive pas encore bien à corriger ce point)
Ici j'ai pas beaucoup plus d'1 mic d'erreur de poursuite mais un chpouns d' 1 centième à l'inversion
(c'est une trajectoire sous forme de cercle)
C'est pas justement là tout le problème? Bien sûr que tu peux dériver la vitesse avec la commande de position, mais n'est-ce pas déjà trop tard, d'où l'erreur de poursuite?
Tandis que LinuxCNC pourrait anticiper car il connait déjà la vitesse du prochain cycle.
Je fais pareil et ça ne pose pas de problème, c'est ma carte qui gère l’asservissement pas le PC,déjà parce que c'est plus son boulot et pour des raisons de sécurité.
Tu vois bien que sur le sanyo-denki comme pour les Delta, les Kinco .... il n'y a pas de PID sur le positionnement, seulement un P et un FF.
Meuh... j'ai parlé de boucle pas de PID. Une boucle avec un gain P ça reste une boucle
Pour en revenir à ça:
Pour que ça fonctionne il faudrait connecter le pin "command-deriv" du composant pid à la vitesse du prochain cycle pour l'axe concerné: joint.X.joint-vel-cmd. Sauf que joint.X.joint-vel-cmd donne la vitesse actuelle, pas celle du prochain cycle. Le "speed feedforward" du PID n'anticipe donc pas grand chose avec toujours un cycle de retard... Au final aucun avantage puisque le servo peut faire la même chose en mode position comme l'a montré CNCSERV.
Après avoir farfouillé dans les forums LinuxCNC et son propre code, j'en suis arrivé à la conclusion que c'est purement théorique et actuellement impossible à cause du fonctionnement de LinuxCNC.
Pour que ça fonctionne il faudrait connecter le pin "command-deriv" du composant pid à la vitesse du prochain cycle pour l'axe concerné: joint.X.joint-vel-cmd. Sauf que joint.X.joint-vel-cmd donne la vitesse actuelle, pas celle du prochain cycle. Le "speed feedforward" du PID n'anticipe donc pas grand chose avec toujours un cycle de retard... Au final aucun avantage puisque le servo peut faire la même chose en mode position comme l'a montré CNCSERV.
Le Delta ASD A2 par exemple, il a une connexion pour l'encodeur du servo plus une deuxième connexion pour un autre encodeur linéaire ou rotatif.Trouvez moi un drive qui a une boucle sur la position
Je suis en train d'en installer 3 sur une fraiseuse, je ne sais pas encore ce que ça vaut.
ici une vidéo du fabricant concernant le tuning d'un petit servo drive que j'ai testé vite fait
(mais pas de comparaison approfondi ce sera pour un quatrième axe .. )
ou les feed-forward vitesse et accélération sont effectivement calculés en interne et paramétrable
(mais pas de comparaison approfondi ce sera pour un quatrième axe .. )
ou les feed-forward vitesse et accélération sont effectivement calculés en interne et paramétrable
Machdrives.com | Brushed DC Servo Drive | CNC | Mach3 | Machdrives
Ultra high performance brushed DC servo drives for CNC machine builders and makers. Ideal for CNC routers, CNC mills, plasma cutters and upgrading stepper driver systems. Made in Australia.
www.machdrives.com
et il n'y a rien a flasher ? c'est juste une interface de branchement?
Il faut évidemment reflasher le FPGA avec la bonne configuration des entrées/sorties. Comme toute carte Mesa qui s'interface directement au FPGA.
Sujets similaires
-
Curiosity_U5832
- Projets de fraiseuse et portique d'usinage CNC
-
Tristan l'apprenti
- Machines CNC d'autoconstructeurs type portique lég
