Pilotage de 2 moteurs pour l'Axe X d'une CNC

[Lezard]

Bonjour,

Je remonte ce fil un peu ancien, car le sujet correspond pile-poil à une question que je me pose en ce moment : en utilisant des servo-drives ayant le mode de pilotage CANopen, est-ce que l'on peut simplement paramétrer un des drivers comme étant un esclave du driver maître ?
Dans ce cas, le contrôleur ne verrait qu'un driver, et les 2 drivers se débrouilleraient entre eux pour se synchroniser.
Inconvénients éventuels de cette solution ?

[EDIT] je continue à potasser le sujet, en attendant de pouvoir bénéficier des lumières des gens compétents qui peuplent le forum. Je me rends compte que je me suis probablement fourvoyé : le système auquel je pensais suppose que l'un des drives (le maître) puisse piloter un drive esclave, en jouant le rôle du contrôleur, mais je ne crois pas que cela soit possible... des idées/éclairages ? [\EDIT]

 

[vince_007]

Ben en STEP/DIR, c'est facile, il suffit d'envoyer les mêmes signaux aux deux drivers. En CANOpen, c'est plus compliqué car caque driver a son adresse, donc faut voir du côté de la CN si elle peut envoyer les commandes aux 2 drivers ou, comme tu le dit, mettre un driver en master et le second en slave.

 

[Lezard]

Bonjour,

Merci pour ta réponse. Je crois que je me suis emmêlé les pinceaux, et que mon idée de faire jouer à un driver le rôle d'un master est farfelue.

 

[vince_007]

Non ce n'est pas farfelue, c'est même assez commun dans les variateurs, ça arrive souvent ce genre d'application. Je suis étonné de voir du CANOpen sur une CN mais pourquoi pas. En CANOpen, le maitre c'est l'automate et les esclaves les variateurs.

Pourquoi veux tu piloter les drivers en CANOpen ? C'est quoi la commande numérique qui pilote ?

 

[Lezard]

Re-Bonjour,

> C'est quoi la commande numérique qui pilote ?
Ben justement, ce n'est pas encore décidé. Le point de départ de ma question était de voir si je pouvais trouver une alternative à la synchronisation logicielle, qui a l'inconvénient d'utiliser un des axes pilotés par le contrôleur pour commander le 2eme moteur de l'axe X. Dans mon cas, si je veux me réserver la possibilité d'évoluer un jour en 5 axes (3D 1/2), cela signifie qu'il me faut un contrôleur 6 axes au moins.

Peut-on simplement brancher deux drivers sur le même signal STEP/DIR destiné au driver X ? Si cela marchait bien, quel est l'intérêt d'une synchronisation logicielle ?

 

[vince_007]

La commande numérique, c'est ce que tu appelle le contrôleur. Oui, tu peux mettre 2 drivers sur les mêmes signaux step/dir, tout dépend de la carte du controleur. Une entrée de drivers peut absorber jusqu’à 25mA car on attaque la LED d'un opto, donc il faut une sortie capable de driver 50mA ce qui est assez bas sauf si c'est la sortie d'une Arduino en direct par exemple.

Je n'ai jamais bien compris à quoi peut servir une synchro soft alors qu'on peut la faire en Hardware directement.

 

[gaston48]

La synchro logicielle est intéressantes par exemple s'il faut inclure un ratio bien particulier entre
les 2 axes.

 

[Lezard]

Bonsoir,

... tu peux mettre 2 drivers sur les mêmes signaux step/dir, tout dépend de la carte du controleur. Une entrée de drivers peut absorber jusqu’à 25mA car on attaque la LED d'un opto, donc il faut une sortie capable de driver 50mA ...

OK, bien compris, merci

La synchro logicielle est intéressantes par exemple s'il faut inclure un ratio bien particulier entre les 2 axes.

Dans mon cas, ce ne sera pas nécessaire, j'ai strictement les mêmes composants (pignon/réducteur/moteur/driver) sur les 2 côtés du portique. Il reste le problème éventuel de l'équerrage lors de la prise d'origine, mais je pense que mon portique sera assez rigide (?) pour ne pas pouvoir/avoir besoin de caler chaque côté séparément une fois le calage initial réalisé.

Merci pour vos explications

 

[vince_007]

Tu ne peux pas synchroniser mécaniquement par une courroie crantée, c'est quand même le mieux ?
Un seul moteur au milieu ou sur un côté, une grande courroie et c'est synchro.

 

[Lezard]

La machine est assez grande (voir le lien dans ma signature), il serait possible de synchroniser avec un seul moteur et un arbre par ex., mais j'ai décidé de faire avec 2 moteurs, ce qui semble la solution la plus largement utilisée sur ce type d'architecture.

 

[vres]

A mon avis vu la taille de la machine il faut des avances d'au moins 300mm/s donc si tu as une résolution 400 Pulse/mm ça donne 120000 Hz.
La boucle d'asservissement des servomoteurs est d'environ 3000hz, ça fait beaucoup de kPulses pour rien.
Il me semble que tu penchais fortement pour un pilotage en boucle fermée, qui à mon avis est une bonne solution, donc là il faut bien un axe logiciel par moteur.

 

[gaston48]

Si tu pars sur des servo-moteurs AC, le drive se pilote en step/dir, il est tout à fait possible d'envoyer
les signaux step/dir en parallèle sur chaque drive.
Le problème, c'est en cas de panne d'une des voies en //, le portique part en crabe et rails et patins
vont se marquer. C'est pour cette raison qu'on peut rechercher à intégrer une synchronisation mécanique
des 2 entraînements.
Avec des vis, la solution simple est un accouplements avec une courroie directe.
Avec des crémaillères, il est souvent possible d'inclure un arbre de transmission sur toute la longueur du portique.
A partir de cet arbre, on peut assurer un accouplement des 2 couples de transmissions
(arbre tubulaire de bonne section pour légèreté et rigidité torsionnelle), il peut être la basse aussi
d'un système mécanique de détection de décalage mais le temps de réponse (décélération) ne préservera
pas d'un dégât mécanique.

 

[Lezard]

Bonjour,

Merci pour vos réponses.

@CNCSERV : je ne comprends pas bien tes explications, peux-tu développer ? En particulier, d'où vient la valeur de 400 pulse/mm que tu cites, qui conduit à "beaucoup de kPulses pour rien" ?
Quand tu dis que "La boucle d'asservissement des servomoteurs est d'environ 3000hz", qu'est que cela signifie exactement ? Est-ce que cela dépend de la fréquence des ordres venant du contrôleur, ou bien est-ce strictement interne au système driver/moteur ? Est-ce qu'il faut comprendre qu'il est inutile d'avoir un contrôleur qui affiche une fréquence de commande supérieure à 3000 Hz ?

J'ai choisi une transmission par crémaillère avec un pignon 20 dents module 2, monté en sortie d'un réducteur 20:1, soit, sauf erreur, un développement de 6,66mm / tour de moteur. Cela donnerait une vitesse de 333mm/s au régime nominal des moteurs à 3000rpm. Les moteurs sont des servos Delta ECMA pilotés par des drivers DELTA ASD-A2, équipés de codeurs incrémentaux 20 bits. Il y a donc une boucle entre le moteur et le driver, et le driver fournit aussi en sortie le signal de l'encodeur, donc, si le contrôleur CNC l'accepte, on peut lui fournir ce signal et être ainsi en boucle fermée jusqu'au contrôleur. Est-ce nécessaire, utile ou bien redondant et source de problèmes à la mise au point ?

"pour un pilotage en boucle fermée, qui à mon avis est une bonne solution, donc là il faut bien un axe logiciel par moteur": je pense que tu parles d'une boucle fermée jusqu'au contrôleur ?

@gaston48 : J'avais envisagé un système tel que tu le décris, mais cela m'avait paru bien compliqué. Si un moteur a un problème, le driver devrait passer en alarme et pouvoir arrêter l'ensemble assez vite non ?

 

[vince_007]

Au vue de ton matériel, je relierais les mêmes signaux step/dir au deux variateurs, par contre, la sortie alarme de chaque variateur à 2 entrées arrêt d'urgence du contrôleur.
Qu'est ce que tu a choisis comme contrôleur ? Un CSLab, Soprolec ou autre ?

 

[gaston48]

Si un moteur a un problème,

Une simple déconnexion d'une des 2 voies // et c'est l’arrêt d'un moteur sans aucune alarme
idem pour une rupture de courroie, une poulie qui se desserre
Un obstacle sur la crémaillère et c'est le blocage d'un moteur, là tu as une erreur de poursuite
et tu peux déclencher un alarme. L'erreur de poursuite, une surcharge thermique, une alarme
du chien de garde interne au drive peuvent déclencher un arrêt.

 

[vres]

@CNCSERV : je ne comprends pas bien tes explications, peux-tu développer ? En particulier, d'où vient la valeur de 400 pulse/mm que tu cites, qui conduit à "beaucoup de kPulses pour rien" ?

J'ai mis 400 pulses car je trouve que c'est une valeur raisonnable.

Quand tu dis que "La boucle d'asservissement des servomoteurs est d'environ 3000hz", qu'est que cela signifie exactement ?

Un asservissement PID a besoin d'une base de temps pour fonctionner, plus le temps est est long plus l'asservissement est précis mais moins il est réactif. pour un moteur 3000hz est un bon compromis, pour un chauffage 1Hz sera peut-être suffisant.

Le problème de la commande Pulse c'est quelle ne peut pas envoyer des valeur supérieur à 1 donc il va falloir une fréquence élevée de pulse pour qu'au final le PID les traitent peut-être 100 par 100.
Quand le servomoteurs est en boucle fermée , vu que c'est le contrôleur qui gère l'asservissement, la position de consigne il la connait directement, pas besoin de Pulses et la, il peut traiter plusieurs millions de points par seconde sans se soucier de la fréquence de pulse.

Les moteurs sont des servos Delta ECMA pilotés par des drivers DELTA ASD-A2, équipés de codeurs incrémentaux 20 bits.

Je connais les Servomoteurs Delta, j'aime bien ce matériel. en 20bits, c'est 1 048 575 PPR.

 

[Lezard]

Une simple déconnexion d'une des 2 voies // et c'est l’arrêt d'un moteur sans aucune alarme
idem pour une rupture de courroie, une poulie qui se desserre...

Bien compris. Il reste que ce type de montage avec 2 moteurs sur un même axe semble être assez courant, il doit donc être possible de réduire les causes de problème que tu cites : câblage sécurisé (?), liaisons mécaniques fiables avec des réducteurs planétaires industriels plutôt qu'une suite de poulies / courroies etc...
Finalement, la seule solution 'sûre' serait d'avoir une boucle de contrôle à partir de règles, à priori indépendantes de la chaîne cinématique.

@vince_007 : je n'ai pas encore choisi le contrôleur, je penche pour l'instant vers une solution 'provisoire' avec un petit contrôleur autonome capable de gérer la machine en 3 axes, pour évoluer ensuite une fois la base mécanique validée en 3 axes.

@CNCSERV : "J'ai mis 400 pulses car je trouve que c'est une valeur raisonnable." : raisonnable dans le sens où cela donne une résolution théorique de 2,5µ ? Est-ce bien celà ?

"Un asservissement PID a besoin d'une base de temps pour fonctionner, plus le temps est est long plus l'asservissement est précis mais moins il est réactif. pour un moteur 3000hz est un bon compromis, pour un chauffage 1Hz sera peut-être suffisant." : compris

"Le problème de la commande Pulse c'est quelle ne peut pas envoyer des valeur supérieur à 1 donc il va falloir une fréquence élevée de pulse pour qu'au final le PID les traitent peut-être 100 par 100" : d'où l'intérêt d'avoir une fréquence de pulse élevée, sinon on doit limiter la vitesse de déplacement, c'est bien ça ?

"Quand le servomoteurs est en boucle fermée , vu que c'est le contrôleur qui gère l'asservissement, la position de consigne il la connait directement, pas besoin de Pulses et la, il peut traiter plusieurs millions de points par seconde sans se soucier de la fréquence de pulse" : bon, et donc on utilise alors une commande analogique en mode couple ou vitesse ?

Merci à tous pour votre aide

 

[vince_007]

@vince_007 : je n'ai pas encore choisi le contrôleur, je penche pour l'instant vers une solution 'provisoire' avec un petit contrôleur autonome capable de gérer la machine en 3 axes, pour évoluer ensuite une fois la base mécanique validée en 3 axes.

Alors ça ce n'est pas une grande idée, j'ai fait la même chose et j'ai longtemps galéré avec du mauvais matériel, parfois même en doutant sur les performances de la machine.

 

[gaston48]

je pense que CNCSERV a compris que tu envoyais un signal de vitesse sous forme de pulse,
donc suite à un asservissement intégré dans le PC ou la carte motion control
Alors qu'ici, tu as choisi des servomoteurs avec drive à pid integrée, donc vu
comme un " pas à pas " tu lui envoie donc des pulse de positions succéssives
l'information de position etant constitué par les codeurs sur moteur, équivalents
à des règles indépendantes
Ce qui suppose quand même, comme le précise vince_007 un générateur
de pulse et dir de très bonne qualité, signaux très propres, largeur de pulse et
décalages entre les fronts configurables et stables, jusqu'aux fréquences les plus hautes

 

[vres]

je pense que CNCSERV a compris que tu envoyais un signal de vitesse sous forme de pulse,

Non pas du tout, j'ai bien compris qu'il veut piloter ses servomoteurs comme des moteurs Pas à Pas en Dir/Step.
L'avantages des servomoteurs est de ne pas fonctionner comme un Pas à Pas.
La plupart des servo-variateurs n'ont pas de PID en positionnement comme les Delta et son souvent très difficile à régler
Je maintient, générer des pulses a plusieurs centaines de kHz pour un servomoteur n'améliore pas sa performance, juste sa résolution si on veux aller vite.

 

[Lezard]

[je me retrouve dans la situation familière où je suis perdu dans une conversation que j'ai contribué à (re)lancer... Comme disait Coluche, les gens intelligents, tu leur poses une question, à la fin de leur réponse tu ne comprends même plus ta question - Faut que je potasse, j'ai encore du pain sur la planche... pas grave je suis têtu !]

A mon niveau de compréhension, et pour revenir à la question de départ, comment piloter 2 moteurs sur le même axe, il semble donc qu'on ait plusieurs solutions :
- n'en piloter qu'un (!) et faire une liaison mécanique 'à l'ancienne' pour entraîner les 2 côtés du portique
- envoyer le signal Step/Dir du contrôleur sur les deux drivers concernés : ça marche mais c'est un peu simpliste
- utiliser une synchronisation logicielle, où le contrôleur 'sait' qu'un axe est à piloter comme un esclave d'un autre. Cela permet éventuellement de faire un contrôle en boucle fermée jusqu'au contrôleur, voire de contrôler l'équerrage du portique, de mieux gérer les problèmes etc...

@CNCSERV : je ne comprends pas bien ce que tu veux dire. Est-ce qu'il serait dommage de piloter ces drivers en Dir/Step 'comme des PàP', alors qu'on pourrait avoir de meilleures performances avec un autre mode de commande ?

 

[vres]

@CNCSERV : je ne comprends pas bien ce que tu veux dire. Est-ce qu'il serait dommage de piloter ces drivers en Dir/Step 'comme des PàP', alors qu'on pourrait avoir de meilleures performances avec un autre mode de commande ?

C'est bien ça mais c'est beaucoup plus compliqué à mettre en œuvre et souvent Gaston consacre beaucoup (trop) de temps à aider.
Il me semblai que tu avais opter pour cette solution?

 

[Lezard]

Je n'ai pas vraiment arrêté mon choix. J'ai choisi ces drivers Delta entre autre parce qu'ils offrent ce mode de commande step/dir qui a l'air plus simple à mettre en oeuvre dans un 1er temps. Mais si il y a de meilleures solutions, j'aimerais en savoir un peu plus pour avoir au moins une idée.

 

[gaston48]

envoyer le signal Step/Dir du contrôleur sur les deux drivers concernés : ça marche mais c'est un peu simpliste

Non ça n'est pas simpliste ? c'est ce qu'il faut faire, sachant qu'il y a un risque éventuel dont il faut être conscient.
soit tu le gères avec un transmission mécanique redondante, soit tu gères au mieux des informations en
tout ou rien, des alarmes, que peuvent te fournir chaque drive. mais en aucune façon tu peux faire plus,
comme des boucles d’asservissement supplémentaires ou autres.
Ensuite tu choisis ta résolution de positionnement, les machines CNC de précision sont couramment à 1 microns,
tu choisis 2.5 microns, c'est raisonnable, en fonction de la vitesse maxi des axes, tu pourras en déduire une
fréquence max de step qu'il faudra confronter avec les caractéristiques réels des sorties de ton contrôleur.

Tes 2.5 microns et les éléments mécanique de transmission vont te déterminer quel est la résolution
du codeur à programmer (la sensibilité du drive en quelque sorte) à partir de la résolution max de 1048575 ppr

 

[Lezard]

...Tes 2.5 microns et les éléments mécanique de transmission vont te déterminer quel est la résolution
du codeur à programmer (la sensibilité du drive en quelque sorte) à partir de la résolution max de 1048575 ppr

C'est le paramètre qui est souvent appelé 'Electronic Gear Ratio' ?
Par ailleurs, la doc Delta indique une résolution de 1280000 p/rev pour ces codeurs, d'où vient la différence avec 2^20 ?

 

[gaston48]

Oui c'est ça, tu peux l'exprimer aussi sous la forme d'un numérateur plus un dénominateur

 

[Lezard]

OK c'est bien ce que je vois dans la doc des drivers.

On pourrait donc dire que ce paramètre sert en qq sorte à trouver le point d'équilibre entre :
- la fréquence maxi du signal émis par le contrôleur
- la vitesse maxi de déplacement atteignable
- la résolution de positionnement

Avec un contrôleur performant (i.e fréquence d'impulsions élevée), on peut aller vite avec une résolution fine. Si le contrôleur est limité, on a le choix de limiter la vitesse maxi et/ou diminuer la résolution. C'est bien ça ?

 

[gaston48]

Oui, c'est bien ça

 

[Lezard]

Bon ben je me coucherai un peu moins bête ce soir, merci beaucoup

A quoi @CNCSERV faisait-il allusion dans son message #52 ?

 

[vres]

A quoi @CNCSERV faisait-il allusion dans son message #52 ?

par exemple :
https://www.usinages.com/threads/retrofit-petite-realmeca-avec-cartes-mesa.89790/