Retrofit petite Realmeca avec cartes MESA

[gaston48]

Hello,
5000 à 6000 mm/mn pour l'instant ça n'a pas beaucoup d'importance.
les mouvement que tu observes sont uniquement le résultat de FF1.
Quand tu demandes au jog un déplacement de 1 mm à une vitesse donnée, passer
de la coordonnée x = 10 à x = 11 par exemple
l'ordre transmis est simplement une dérivée donc une impulsion de vitesse qui dure
le temps du déplacement, sans aucune contre réaction. tu as mis un FF1 à 0.1
alors que je l'avais mis à 0.01 qui est beaucoup moins rapide. c'est une config de
sûreté qui permet, comme je l'ai dit, de vérifier le sens de comptage des codeurs,
un mouvement positif de l'axe etc . Si tout est correct, on peut commencer à
appliquer une contre-réaction en montant progressivement P. Ceci sans que l'axe
s’emballe et parte dans les décors. Avec un servo de 2 Kw, tu imagines les dégâts.
Il faut que tu rentres tous mes paramètres leurs valeurs ainsi que l'affichage d'erreur de poursuite.

 

[Laurent_CNC]

Salut Gaston,
Bon je vais testé ça rapidement.
Pour le 0.01 c'est compliqué... j'ai d'abord testé avec ta valeur mais rien de bougeais... sauf que je demandais un JOG en X ou Y avec les flèches du clavier et que mes drivers étaient en défauts sur X et Y... alors j'ai pensé que la valeur était trop faible... jusqu'au moment ou j'ai appuyé sur le Z et qu'il a fait un bond ! J'ai alors regardé mes Drivers pour voir que mon branchement était pas bon pour les sécurités. Je les ai déconnecté et maintenant tout bouge...

Première victoire quand même

Maintenant , je vais déjà installer la visu d'erreur de poursuite et on avancera.

@ tout'

 

[Laurent_CNC]

Salut à tous,

Bon mes axes bougent et dans le bon sens. J'ai lancé 3 commande MDI G0 X10 puis Y10 puis Z10 et tout va dans le bons sens.

Les compteurs tournent aussi. On voit une erreur de poursuite s'afficher et elle est, elle aussi dans le bon sens.

Voici mon Axis à l'heure actuelle :

Par contre Y et Z bougent tout seuls (très lentement).
Je peux régler ça comment ? Tu parlais, gaston, de travailler sur les Drivers via un petit potar mais il me semble que tu as aussi évoqué une solution matérielle ?

Je ne touche à rien avant ta réponse. Les drivers étaient bien réglés avant, je ne dois peut être rien toucher sur le Driver..
@ bientôt

 

[gaston48]

Hello !
Ca commence à marcher tout ça
Concernant les mouvement lents, un driver n'est jamais bien réglé à lui seul, il l’était associé à la Num.
là, il faut que tu refasses le réglage le driver associé à Mesa. Le petit potar est conçu pour cela.
Une foi le contre-réaction bouclé, tout mouvement lent d'offset disparaît. On peaufine ici ce réglage
par satisfaction de l'esprit aussi.
Concernant les divers "bon sens" de rotation:
Quand tu envoies un ordre jog positif 1 mm sur X par exemple il faut vérifier avec halmeter que
hm2_5i25.0.encoder.00.count compte en positif
ensuite sur Y hm2_5i25.0.encoder.01.count compte en positif aussi
ensuite sur Z hm2_5i25.0.encoder.02.count compte en positif également.
là on est certain de capter à la source.
Si c'est bon !
On peut commencer à boucler la contre-réaction. dans axis /machine/calibration
tu peux retoucher les paramètres de la PID et les tester "en temps réel".
Il faut commencer par activer le P avec une valeur très faible (comme je le disais, se méfier des facteurs 10 imprévus)
donc avec un FF1 de 0.01 ou plus faible, passer P à 0.01 par exemple.
Si l'erreur de poursuite n'est pas diminué, passer à 0.1 et monter tout doucement jusqu'à une valeur
qui aura tendance à faire vibrer / osciller l'axe. là on redescend à une valeur ou l'axe est parfaitement stable
avec une erreur de poursuite qui te convient.

 

[Laurent_CNC]

Super, merci de ta réponse.
Ce sera le boulot de demain matin

En attendant j'ai cablé correctement ma broche et elle fonctionne.
Elle est pilotée par Axis... mais... seulement en +10V, rien d'autre.
Je la lance et je l'arrète mais c'est toujours à fond et dans le me sens.
Je suppose que l'on va déclarer qq chose à la 7i77 pour quelle module sont signal.
Une chose à la fois

@+

 

[gaston48]

super !
Normalement j'avais commencer à bien "cabler" la spindle. Ton variateur de fréquence accepte une entrée bipolaire
+ - 10V qui permet donc l'inversion de sens directe par l'entrée analogique.
le scale était bien de 10 / 4000 = 2.5-e-3
et entrée / sortie directe proportionnelle du bloc PID par FF0 = 1
et bien sur brancher sur la sortie analogique dédié analogout5 et ena5+ et ena5- et son activation par spinena
Il faut peut être aussi reprogrammer le variateur pour cela .

 

[gaston48]

Vous devez être connecté pour voir ce contenu.

il faut vérifier si la consigne de vitesse en rpm, sort bien de spindle-vel-cmd-rpm

Et concernant le branchement sur le leroy somer
C1 vers GND de la 7i77
C2 vers AOUT5 de la 7i77

Ensuite pour la mise en marche, à voir si on garde:
C10 qu'il faut mettre sur C6 pour activer la marche avant. C6 qui est le 0V logique
Possible qu'avec uniquement cet ordre marche "avant", le fait d'injecter -10V
fasse tourner la broche en arrière.
Sur le schéma original de Realmeca, C10 et C6 sont fermés avec KA5 qui
est désigné comme "DÉVERROUILLAGE DE BROCHE" je le comprend comme
un enable donc on pourrait brancher C10 sur ENA5+ et C0 sur ENA5-
C11 à mettre au 0V logique (C6) : pour indiquer que le pilotage de fréquence
se fait par l'extérieur.
Toujours d’après le schéma Realmeca, le switch programmable avec les 2 bornes A1 et A2
du Leroy somer est certainement programmé avec le paramètre B50 à 0
ce qui veut dire que A1 et A2 sont fermés si sous tension et pas en défaut.
je pense qu'il faut câbler un input-not 24V sur A1 et A2 sur un input-not
et de la brancher sur => halui.machine.off comme le default éventuel d'un drive
regroupés dans OFF_MACHINE_EXT.
Comme ils seront plusieurs à entrer sur halui.machine.off et que c'est interdit,
il va falloir charger un composant logique "OU".

 

[Laurent_CNC]

Oui, c'est mon branchement. C1 et C2 sont reliés à GND et à AOUT5.
C6 et C10 sont reliés.
Pour le reste je ne sais plus mais en tout cas ; j'ai testé en envoyant 1,5 V et 9 V par des piles sur C1 et C2 et la broche fonctionne en marche avant et en marche arrière avec des vitesses différentes, aucun soucis.

Mais quand je relie à la 7i77, c'est ON OFF, pour l'instant

Je n'ai rien de relié à ENA5 + et ENA5 - pour l'instant, c'est pour ça que la broche est ON OFF sans régul' ?

Je vais commencer par améliorer les moteurs d'axes demain matin, la broche, ce sera après

 

[gaston48]

Je n'ai rien de relié à ENA5 + et ENA5 - pour l'instant, c'est pour ça que la broche est ON OFF sans régul' ?

Non ça n'a pas de rapport.
je l'ai mal branché finalement si on utilise FF0 . spindle-vel-cmd-rpm rentre bien dans la PID mais
je n'exploite pas sa sortie

au lieu de cette ligne:
net spindle-vel-cmd-rpm => hm2_5i25.0.7i77.0.1.analogout5
il faut ceci:
net spindle-output => hm2_5i25.0.7i77.0.1.analogout5
mais ça ne devrait rien changer
C'est peut etre une histoire de scale aussi, 25e-4 devrait convenir , il faut vérifier avec halmeter la valeur spindle-vel-cmd-rpm
de FF0 etc ... tout tracer avec halmeter.
On a toujours pas trouver ce qui coinçait E-stop ??

 

[Laurent_CNC]

On a toujours pas trouver ce qui coinçait E-stop ??

Non, j'ai fini par recopier mes fichiers en les renommant realmeca... et par coller dedans les différentes valeurs que tu avais défini... c'est à n'y rien comprendre mais comme ça, ça fonctionne
J'ai du coup copier aussi les codes pour l'affichage de la broche.

Les emmerdes ont du bon, j'ai jamais autant jouer avec les fichiers de LinuxCNC moi

 

[gaston48]

Les emmerdes ont du bon, j'ai jamais autant jouer avec les fichiers de LinuxCNC moi

j'ai vu que tu avais franchi "le cap " c'est comme rouler à vélo, après tu as moins de complexe à evoluer dans tout ça.
il ne faut surtout pas hésiter à consulter la doc ou taper un mot clé dans le site de linuxcnc. Tu te prépares pour ça des liens
directs dans tes favoris.

 

[Laurent_CNC]

Bon aller, je file,
Demain, je m'attaque aux réglages de mes drives.

Je commence par shunter les bornes 3 4 11 et jouer avec le petit potar avec le PC et la 7i77 coupé mais je me demande si je sentirais seulement le mouvement des axes tellement c'est faible.
Puis je passe au BIAS si nécessaire.

Ensuite je bosserai sur ton #514 en aillant à l'esprit http://linuxcnc.org/docs/html/motion/pid_theory_fr.html

Pfffuuuu j'suis pas encore sorti de l'auberge moi

 

[gaston48]

Je commence par shunter les bornes 3 4 11 et jouer avec le petit potar avec le PC et la 7i77 coupé mais je me demande si je sentirais seulement le mouvement des axes tellement c'est faible.
Puis je passe au BIAS si nécessaire.

le bias est une possibilité si tu n'as pas de potar. Le potar n' est pas réservé au drive mais à toute la chaîne
qui se situe à partir d'une consigne qui est à zéro (je ne demande pas d'ordre de déplacement)
et un servomoteur en boucle ouverte qui doit rester à l’arrêt.
Donc linuxcnc doit etre lancé et en marche, ainsi que drive enable.
Tu positionnes le potard entre une position ou le moteur tourne dans un sens et l'autre position ou il tourne
en sens inverse à peu près à la même vitesse.

 

[Laurent_CNC]

Bonjour à tous, bonjour Gaston,

Bon,
premier essai en shuntant les bornes 3, 4 et 11 et en isolant la 7i77. La sensibilité du potar T2 est très sensible. Il est impossible difficile de stopper complétement le mouvement. J'ai fait au mieux.

Second réglage, là, tout est en ordre de marche et je lance Axis.
Mes axes bougent beaucoup tout seul... je décide de tester si T2 est utilisable.
Nickel, on voit son effet en direct sur Axis. Je règle au mieux car c'est toujours trop sensible pour être totalement à l'arrêt.

Mais je me rend compte d'un truc, les bornes 10 et 11 des drivers, sur lesquelles devraient être la résistance en pulldown ne sont pas reliés...
Je rebranche donc ça sur les bornes de la carte FD qui leurs sont réservés soit CN7,8 et 9.
Maintenant les moteurs ne bougent plus du tout... mais font du bruit... ils grognent...
Je n'y comprend plus rien...

Du coup, je refais tout le branchement des broches 12 des drivers (sur le CN26).
Je part du +24V et je sort donc un fil à la broche 8 du connecteur, sur lequel il y a +24V.
Mes moteurs, leurs drivers reliés à CN26 ne font plus de bruits... mais ne bougent plus...
Une led rouge est allumée... ils sont en erreurs

Je vais me pencher sur le paramètre BIAS.

J'ai aussi repèré un soucis potentiel, mon axe X bouge physiquement mais pas les valeurs à l'écran... le compteur ??

J'y retourne.

Je ne fais plus rien... je me perd et je vais finir par faire une connerie définitive...

 

[Laurent_CNC]

... J'ai l'impression d'avoir reculé...

Bonjour à tous,
Ben, je n'arrive pas à mettre mes moteurs d'axes au repos.

Si j'utilise la partie de la carte FD dédiée aux défauts sur les variateurs, donc les zones CN7 CN8 et CN9 ainsi que CN26.
Je relie tout ça à mes variateurs (drivers) d'axes. Ca ne fonctionne pas. Les moteurs grognent.
J'ai repris plusieurs fois mon cablage mais rien n'y fait...

Si je fais comme CNCSERV me l'a expliqué, c'est à dire relier un +24V sur la broche 10 du driver et une résistance en Pulldown sur 11,
les moteurs ne grognent plus mais tourne doucement tout seul.

Je pensais pouvoir corriger ça via le paramètre BIAS de linuxcnc mais je n'arrive pas à avoir l'arrêt complet.

En plus de ça. Les moteurs ne réagissent pas de la même façon quand linuxCNC est branché ou pas...
Ca pourrait être problèmatique car mes axes à l'arrêt sous l'influence de linuxcnc ne le sont plus forcément quand je l'arrète.

J'ai testé sur X et Y et j'ai des valeurs de BIAS très différentes. 0.002 sur X et 0.0001 sur Y.

Sinon, j'ai regarder comment comptait mes codeurs Gaston.
Pour X, le codeur et la visu compte dans le même sens mais le mouvement est inversé.
Pour Y, tout est bon, la vis, le codeur et le mouvement est le bon.
Pour Z, le codeur et la visu compte dans le même sens mais le mouvement est inversé.

 

[vres]

Si je fais comme CNCSERV me l'a expliqué, c'est à dire relier un +24V sur la broche 10 du driver et une résistance en Pulldown sur 11,
les moteurs ne grognent plus mais tourne doucement tout seul.

Si tu met du 24V sur l'entrée 10 c'est normal qu'ils tournent. En revanche il ne doivent pas tourner quand tu n'applique pas le 24V avec la résistance de tirage PullDown.
Si ils tournent ou grognent tu pourrais mesurer la tension sur la borne 10 ?

Tu pourrais griffonner un schéma de ce que tu as fait comme branchement (ou une photo)

 

[gaston48]

Bonjour,
Ne t'inquiète pas trop, il manque un potentiomètre 10T sur cet ampli pour avoir un réglage plus fin .
Il faut que le mouvement soit suffisamment lent pour que tu ais le temps de vérifier les bon sens / polarité d'une voie
puis de paufiner la valeur de FF1 pour que tu ais un déplacement sensiblement équivalent (au pif) à un jog de telle
vitesse et de tel déplacement... avant de mettre un peu de P. Et la miracle tout sera stable.

La résistance de puldown remplace le switch sur ce schéma.
Avec 1.2K ce qui fait un diviseur de tension 5V * 1.2/(3 + 1.2) = 1.4V = niveau logique bas (sans considerer la diode)
Le fait de mettre une résistance au lieu d'un switch permet d’appliquer une tension en haut de la 1.2K sans faire
un court-jus et donc de refaire passer le niveau logique à 1.
5V suffirait mais pour pouvoir metre 24 V, une diode protège de la surtension.
attention, 24V sur une 1.2K il faut dissiper 0.5W dans la résistance.

 

[Laurent_CNC]

Ok, merci à vous deux.

J'ai mis un de FF1 et les axes bougent à une vitesse très convenable et d'une longueur qui est pas mal non plus (mesurée au réglet...).
Je commencerais, en fin d'après midi à "mettre un peu de P".

Peut on facilement régler le problème du sens de déplacement ?

 

[vres]

En inversant A et /A du retour codeur.

 

[Laurent_CNC]

OK merci, voila qui est fait. Alors maintenant quand je lance un HALMETER :

axe X : la visu compte dans le même sens que la variable encoder.00.count
Mais l'axe bouge dans le mauvais sens par contre

axe Y : la visu et la pin encoder.01.count vont dans le même sens
L'axe bouge lui aussi dans le bon sens

axe Z : la visu compte dans le même sens que la variable encoder.02.count
Mais l'axe bouge dans le mauvais sens par contre

Je m'embroullais tout à l'heure et là j'ai fait à tête reposée.
Ca m'a l'air pareil après avoir inversé A et A/ ...
Je viens de remettre le Z comme avant au niveau de A et A/ et j'ai toujours le même résultat.

Mais est ce que je regarde la bonne chose.
Moi je regarde comment évolue la visu, pas le compteur de poursuite.

QQ peux me confirmer si je fais une bétise ?

Merci d'avance,

 

[Laurent_CNC]

Quand je regarde le sens du comptage entre halmeter et l'erreur de poursuite ça donne ça :

Axe X (A et A/ inversés) : quand l'erreur de poursuite augmente, encoder.01.count augmente

Axe Y (A et A/ normaux) : quand l'erreur de poursuite augmente, encoder.01.count diminue

Axe Z (A et A/ normaux) : quand l'erreur de poursuite augmente, encoder.02.count diminue

Je parle de mes valeurs en relatif par rapport à 0 on est d'accord.
Quand je passe de -1000 à -1500 je diminue et quand je passe de -45 à -35 j'augmente.

@ bientôt

 

[vres]

Tu as mis un peu de P ? tu as mesuré la consigne, tu as surement la valeur directement dans Halmeter.

 

[gaston48]

Ce qui est important c'est le sens de JOG +1 mm à petite vitesse, le count correspondant compte en +

L'erreur de poursuite c'est autre chose je ne suis pas certain que leur sens soient bons en ce qui concerne cette vérification. Tu m'as pas bien lu encore une foi #514
de toute façon on a une chance sur deux, le fil rouge ou le fil bleu ???? boummmmm

 

[Laurent_CNC]

OK, je pensais l'avoir bien lu... et j'ai donc ma réponse.
C'est mon #530 qui compte.
En + ou en -, Les comptages de jog et ce que je vois sur halmeter vont dans le meme sens.
Par contre le sens du mouvement induit par le JOG demandé est inversé pour X et Z.

@ ma prochaine séance de bricolage, j'essaye de mettre un peu de P dans le circuit et je vois ce que ça donne.

Je voudrais bien trouver par moi-même pour le sens du mouvement, ne me dite rien encore

Grand merci à vous deux.

 

[gaston48]

le #530 est peut être bon mais c'est une interprétation d'axis
En fait tu avais bon scuse tu appelles visu: halmeter. Je pensais que tu parlais de la visu
dans axis. C'est moi qui lit trop vite... un point partout (à peu près) ...
Voilà les étapes :
-j'ai configuré mon espace de déplacement dans ini (tu prends la ref linuxcnc, ?)
-j'ai des switch de homing dois-je y aller en - ou en + tout ça je prévois ...

-mon jog + fait tourner le moteur et sa vis dans le bon sens: oui ... non: j'inverse la
polarité du moteur.
-quand mon moteur va dans le bon sens + le count va-t il dans le + aussi ?
non: j'inverse le branchement du codeur ou son scale 100 à -100 par exemple

mais attention je ne suis pas certain que "count" suive il faut alors regarder "position" s'il s'inverse.
oui vérification faite, count reste toujours positif si le scale passe de 100 à -100
mais "position" qui est = à count x par -100 est bien inversé et c'est lui qui rentre dans
la PID.
etc ...

#530:
axe X : la visu compte dans le même sens que la variable encoder.00.count
Mais l'axe bouge dans le mauvais sens par contre
solution: tu inverses l'alimentation du moteur et de la tachy.

axe Y : la visu et la pin encoder.01.count vont dans le même sens
L'axe bouge lui aussi dans le bon sens
solution: c'est bon.

axe Z : la visu compte dans le même sens que la variable encoder.02.count
Mais l'axe bouge dans le mauvais sens par contre
solution: tu inverses l'alimentation du moteur et de la tachy.

 

[Laurent_CNC]

Bonjour Gaston,

Non, tu as toujours pas mal de points d'avance
Mon terme de visu concerne bien ce que Axis me montre dans la fenêtre avec le dessin (fond noir et écrit blanc)
Et quand je dit encoder.02.count, c'est ce que me montre Halmeter.

[div=none][div=none]

[/div][/div]

Dans tout les cas, je suis exactement comme dans la config en photo issu du site linuxcnc et tu nous montres.
Mes déplacements et mes Homes sont aux mêmes endroits. Juste que j'ai deux capteurs un pour Home, l'autre pour la limite +.

Il faut toujours réfléchir un minimum avec cette configuration car le mouvement de X et Y est inversé visuellement par rapport au sens de l'axe.
Mais je devrais m'en sortir avec tes explications, je vois à ça demain matin si tout va bien.

grand merci (encore) !

 

[gaston48]

Juste que j'ai deux capteurs un pour Home, l'autre pour la limite +.

Là c'est parfait.
Quand l'asservissement sera fonctionnel et avant de peaufiner la PID, on s'attaquera à la prise d'origine machine
et aux limites.

 

[Laurent_CNC]

OK
Si j'ai bien compris, mes HOMEs, je dois les cabler en mettant un +24V permanent sur un des deux fils et mettre l'autre sur une entrée de la 7i77. Mais on va déjà vérifier l'asservissement

 

[Laurent_CNC]

axe X : la visu compte dans le même sens que la variable encoder.00.count
Mais l'axe bouge dans le mauvais sens par contre
solution: tu inverses uniquement l'alimentation du moteur.

Salut à tous, salut Gaston,
J'ai testé en inversant la polarité du moteur. Je n'ai pas d'explications mais l'axe est parti violemment en butée...
J'ai remis comme c'était.

Du coup j'ai testé en changeant le sens de l'information, les fils branchés sur le connecteur 5 de la 7i77 et venant de 3 et 4 du Driver.
Le sens de déplacement est bon quand j'actionne la flèche X+... mais je vois sur la visu axis un déplacement en X-...
J'inverse A et A/ du codeur et tout va bien.

J'ai fait pareil pour Z et j'ai contrôlé Y. Tout mes axes ce déplacent comme je le veux maintenant.

Je regarde le sens de count avec halmeter
Quand je déplace en X+ la visu de axis va vers le plus et halmeter me donne un count00 qui augmente en sens +
Idem pour Y et pour Z.

Tout semble convenable.
Il me faut bosser sur les valeurs de PID maintenant... Faut que je retrouve ton post Gaston.

Avec P à 0.1 mes axes ne bougent plus. Mais avec 1 aussi.
Faut il que je laisse la plus petite valeur possible ou au contraire allez chercher la plus élevé ?

Merci pour tout !!! ça fait plaisir de voir avancer le truc.

voici un réglage type :

 

[vres]

Voici ma méthode pour régler mon Pid :

1- Je commence a vérifier le fonctionnement du codeur en bougeant l'axe à la main.
2- Je met uniquement un peu de P et je met l'asservissement en route mais sans brancher le Enable sur le driver.
Normalement en déplaçant l'axe manuellement tu dois avoir une variation de la tension de consigne, tu peux le vérifier au voltmètre.
3- Je branche le Enable du Driver et je mets l'asservissement en route avec une main sur l'AU. Deux possibilités :
- Le moteur va se stabiliser -> La consigne est bien branchée.
- le moteur va prendre de la vitesse -> la consigne est à l'envers. (inverser A et /A sur le codeur si rien est prévu au niveau logiciel)

Ensuite si le sens de déplacement ne correspond pas au déplacement logique, ça devrait normalement se changer par un paramètre du logiciel.