Mikron WF2/3DCM... encore un retrofit Linuxcnc/Mesa

[Bruno26]

Finalement, c'est bien du plug'n'play!
Les axes ont bougés!
J'ai même commencé à m'amuser avec les PID
J'essaye de vous faire une vidéo ce soir.
Trop top, trop content!
Yes! Yes! Yes!

 

[gaston48]

 

[Bruno26]

La ptite vidéo:

5 minutes par axes pour trouver des PID pas mauvais. Pas encore fait d'enregistrement précis avec halscope mais à priori 2 ou 3 centièmes d'erreur maxi à 2000mm/min pendant les phases d'accelération!
D'autant plus happy, qu'il n'y a plus les bruits de mécanique pas terrible qu'il y avait surtout sur l'axe Z avant de tout démonter
Encore rien paramétré comme entrée/sortie logique sur la 7i77. Les switchs de fin de course agissent bien sur la ligne d'arrêt d'urgence comme d'origine, donc ça ne pose pas de problème pour un premier essais.
Je vais m'occuper de ça maintenant, notamment des "home". Faut déjà que je potasse ça comme il faut pour comprendre comment marche la procédure pour trouver ces références avec les index des règles.
Pour l'instant je n'ai fait quasiment que du copié-collé des fichiers de Laurent_CNC.

A+

 

[gaston48]

Compliment, tu vas suscité de nouvelles vocations de retrofiteur.
Sur les Mikron un peu plus récentes, les origines machines se font avec des règles munies d'index
à distances codées. le décodage plus complexe est depuis longtemps sur la liste "à faire" des développeurs
de linuxcnc. Mais peu importe si tu as ou pas ces règles, il sera toujours possible de faire seulement
l'acquisition du premier top index venu. Reste quand même ce problème pas vraiment identifier avec Laurent
d'acquisition aléatoire en fonction de la vitesse.

 

[ingenieu59]

Bonjour,

bravo , pour les paramètres et ta dextérité .
Reste à essayer un Gcode ( sans matière ni outils ).

 

[Bruno26]

Merci les gars. Ca aide beaucoup quand d'autres ont fait la même chose et l'ont partagé .

Je me suis penché sur les index de mes règles et la prise d'origine.
A priori sur les LS903 il y a un index de chaque côté de la règle. Il y a d'ailleurs un autocollant sur le corps de la règle pour l'endroit approximatif où ce trouve cet index. Enfin, c'est ce que j'en ai déduit.
Avec halscope et un déclenchement de l'enregistrement sur un front montant ou descendant de hm2_5i25.0.encoder.00.input-index, j'ai pu le trouver en déplacement lent (sur l'axe X dans pour commencer). Je vois bien son bref changement d'état, par contre hm2_5i25.0.encoder.00.index-enable ne change pas d'état, même de façon brève.
J'ai du mal à comprendre la différence entre les 2, index-enable et input-index, et pourquoi input-index n'apparaît pas dans le fichier hal.

Par ailleurs, dans le fichier hal de Laurent_CNC, ces lignes apparaissent 2 fois:
net x-index-enable axis.0.index-enable <=> hm2_5i25.0.encoder.00.index-enable
net x-index-enable <=> pid.x.index-enable

A+

 

[gaston48]

Donc tu as les règles "normales"

halscope et halmeter fait l'inventaire de tous les signaux disponibles.
je n'ai pas de 7i77, et avec Laurent, on a essayé de les copier coller pour que je puisse
les avoir, mais ça n'est pas possible, il faut les sortir avec une instruction spéciale à la console.
La 7i77 est plus obscure, qu'une carte fille sur 50 pins, il y a beaucoup de multiplexage
input-index est j'imagine une entrée hard, elle fait en quelque sorte double emploi avec index-enable,
mais la syntaxe dans HAL est simplifié pour être dans la l'esprit du plug and play.
En plus index-enable est bidirectionel.
A défut de na pas voir le front, tu dois voir le compteur se mettre à zéro

http://linuxcnc.org/docs/2.7/html/man/man9/hostmot2.9.html#encoder
(bit in/out) index-enable
When this pin is set to True, the count (and therefore also position) are reset to zero on the next Index (Phase-Z) pulse. At the same time, index-enable is reset to zero to indicate that the pulse has occurred.

Par ailleurs, dans le fichier hal de Laurent_CNC, ces lignes apparaissent 2 fois:
net x-index-enable axis.0.index-enable <=> hm2_5i25.0.encoder.00.index-enable
net

Ca c'est rien c'est pour rendre la ligne moins lourde.
Juste derrière net, tu crée le nom de ta variable "x-index-enable" ça pourrait être "activation-index-x"
Tu nommes en quelque sorte la connexion qui va transmettre l'info entre axis.0.index-enable et hm2_5i25.0.encoder.00.index-enable
ces 2 désignations, tu dois les respecter, ce sont des noms de variable choisies dans le code des composants (hostmot2)
Ensuite rien ne t’empêche de reprendre ta connexion pour l'affecter à une autre entrée
net x-index-enable <=> pid.x.index-enable
En fait c'est 2 lignes pouvait s’écrire en une seule:
net x-index-enable axis.0.index-enable <=> hm2_5i25.0.encoder.00.index-enable <=> pid.x.index-enable

 

[gaston48]

En fait quand on regarde le composant encoder (non mesa)

http://linuxcnc.org/docs/2.7/html/man/man9/encoder.9.html
je peux bien voir les 3 entrées codeur
encoder.N.phase-A bit in

Quadrature input for encoder channel N.

encoder.N.phase-B bit in

Quadrature input.

encoder.N.phase-Z bit in

Index pulse input.
Et je dois bien les câbler dans HAL en partant d'input du port // par exemple

Mais dans la 7i77, avec hostmot2, cela se fait d'une façon implicite

 

[Bruno26]

En plus index-enable est bidirectionel.

Qu'appelles tu bidirectionnel? C'est bien la 5i25 qui gère l'état de hm2_5i25.0.encoder.00.index-enable?
En fait je crois que le "enable" n'est pas très explicite. Je comprendrai mieux avec "index-found".
Je vais re-essayer avec halscope en prenant le compteur en plus.

 

[gaston48]

il faut scruter les compteurs avec halmeter en plus de halscope
C'est exprimé par la flèche à 2 pointes <=> (facultative)
par la description de cette "entrée/sortie" : (bit in/out) index-enable
hm2_5i25.0.encoder.00.index-enable reçoit len interne 'impulsion de input-index
puis il la transmet à axis.0.index-enable et pid.x.index-enable
puis il est reseté donc il devient une entrée
At the same time, index-enable is reset to zero to indicate that the pulse has occurred.

Il faut se méfier aussi de halscope (et de halmeter), il ne voit pas tout, c'est un composant temps réel
qui est intégré dans le cadencement temps réel synchrone de linuxcnc il peut louper certaines infos
ou tout au moins ne pas les afficher, de la même façon que quand tu écris et teste un composant temps réel,
il y a parfois du code ,parfaitement dans les règles, qui n'est pas pris en compte, il faut l'écrire autrement, il
n'y a pas de règle, mais quand ça marche, ça marche.
Les composants écrits en "userspace" non temps réel, sont beaucoup plus accommodants .

 

[Bruno26]

Merci gaston48, c'est plus clair pour moi.
Malheureusement, je ne pourrai sans doute pas faire d'autre essai aujourd'hui. Il doit y avoir 30km/h de vent, et chez moi dès qu'il y a un peu de vent avec des rafales, c'est 10 coupures de courant à l'heure! Plutôt casse-pied!

 

[gaston48]

Les joies de la campagne ! dans ton cas, cette POM de précision se justifie,
car en cas de coupure de courant, tu peux reprendre un usinage en cour

Tu pourras faire des essais de reproductibilité en faisant une POM
puis aller sur un comparateur ... Ensuite coupure remise en route,
POM et vérifier que tu as la même valeur au comparateur.
normalement c'est à une impulsion codeur prête.

Tu as quoi comme config PC et temps de latence ?

 

[Bruno26]

Bon, ça y'est (pas pu attendre d'avantage pour remettre en route!) la POM marche pour l'instant que sur le X. Je m'étais mélangé les pinceaux avec les paramètres de vitesse.
Par contre mon PC a clairement un problème aléatoire. Ca faisait un petit moment qu'il s'était mis à déconner, le ventilo du processeur tournaient quasiment tout le temps à fond mais ça variait si par exemple je cliquait sur la souris...
Hier, en démarant Linuxcnc il me mettait de temps en temps des messages d'erreur sur la communication avec la 7i77 et une loupiote restait allumée rouge sur la carte. Ce matin pas moyen de démarrer Linuxcnc, toujours ces mêmes erreurs.
Je fait un essai de latence pour voir, et là, max-jitter à 6153531ns!!!
Je redémarre pour regarder dans le bios la config du PC:
PC NEC
CPU AMD Sempron Processor 3600+, 2GHz
3 Giga de RAM
et une carte video.
Je laisse le PC démarrer, plus de bruit de ventilo, et max-jitter à 2200ns. C'est mieux, j'avais même plutôt 6000ns en tête au dernier test, mais j'ai rien fait dans le Bios et j'y avais déjà jeté un oeil pour voir s'il y avait pas un pb de température du processeur.
Bon, pour l'instant ça marche. Cool, mais mon PC n'est visiblement pas très fiable.
A+

 

[gaston48]

J'ai souvent lu qu'il fallait se méfier des ram d'époque, la ram serait un composant sujet au vieillissement ?
comme les alim.

 

[Bruno26]

Bon, ben les POM fonctionnent sur les 3 axes. Trop classe quand ça cherche tout seul! J'adore!
J'ai essayé aussi le serrage du porte-outil. Après une petite purge en dévissant le raccord au-dessus de la broche, ça marche nickel.
Ce soir je pense remonter la table et faire des essais plus précis avec halscope des asservissement.
Après, il faudra que je me motive pour ressortir la machine à coudre pour les soufflets du X.

A+

 

[jéjé]

Bravo pour ce travail!
J'avais du mettre de côté le meme projet, mais je vais le réactiver, vos expériences vont m'être très precieuses!

 

[Bruno26]

Bonsoir jéjé,
La même machine ou similaire? dis-nous en plus!
Je serais content si je peux à mon tour aider quelqu'un à faire pareil
A+

 

[jéjé]

Une machine très similaire, une Hermle, mais je ne veux pas polluer ton post avec ça

https://www.usinages.com/threads/hermle-uwf-600.69798/page-6

 

[wapiti]

Je serais content si je peux à mon tour aider quelqu'un à faire pareil

Tu vas être ravi!


euh, bravo pour tes avancées... t'as remarqué une relation entre le vent et les coupures de courant, j'avais jamais fait gaffe mais je le ferais voir si ce 'probleme' de coupures peut être anticipé, ça évitera un peu de 'jus de cerveau'...
Edit: effectivement, hier soir 4 microcoupures....

 

[jéjé]

Pour le vent, j'avais le même problème, et ça m'agaçant fortement , nos vieilles électronique n'aiment pas trop.
Je suis en contrat électricité pro pour l'atelier, je portais réclamation chaque fois (des coupures quand le vent exedait les 50km/h environ)
Ils ont fini par envoyer des élagueurs qui ont résolus le soucis

 

[Bruno26]

J'avais déjà parcouru ton post jéjé. Effectivement ta machine s'y prêterai bien aussi à un retrofit avec des cartes Mesa. Si tu as les schéma de cablage, avec une machine déjà fonctionnelle, le plus long est de concevoir un pupitre à ton goût...
Tiens, j'irai faire un tour autour des poteaux électriques autour de chez moi.
Allez wapiti, lance toi! Montre nous ce que tu as dans les armoires. Tu gardes quand même tout ce qui est relais et disjoncteur?
A+

 

[wapiti]

OK, j'arrete de dessiner, j'me remet au BTP...(j'étais dans un bon flow de conception, le genre de moment où je fais le monomaniaque, j'ai bien avancé, faut que je fasse une pause digestion/compilation/autocritique/recherche de docs techniques pour aller plus loin ... le moteur est un peu bas, faut que je le réaligne avec le CG...)

Je crois que je vais tout virer, apres les premiers tests de la machine d'origine pour identifier les parametres...
Tu m'as bien flingué quand même, tu me dis 'boh, 2-3 fils à brancher et ça ira' et tu le fais, et ça marche... la recette miracle c'est le hal de Laurentcnc?
à+

 

[jéjé]

J'ai tout les schémas, et j'ai identifié toutes les E/S sur les broches (des db25) sur lesquelles la CN se branche. mon but était de venir brancher le systeme linuxcnc en lieu et place de la Heidenhain sur ces prises db25 et de pouvoir rebrancher l'ancienne CN pour reprendre le boulot. Ceci le temps de faire la mise au point de la solution linuxcnc
Le soucis est que je suis artisan, et cette machine me sert quotidiennement, j'ai donc peur d'y toucher tant que je n'ai pas une autre machine pour la seconder.
Je recherche un centre d'usinage. Quand je l'aurais, j'attaque la Hermle!
J'ai aussi des servo dc munis de codeurs et de tachy qui peuvent venir en remplacement des servos des X et Y d'origine qui n'ont que des tachy. Ca me simplifierait le changement des drive par des drives Granite que j'avais acheté

Ce qui me fait peur c'est quand même ce fichier Hal qui me semble bien complexe... mais il faut que je relise de fond en comble vos sujets .....

 

[Bruno26]

la recette miracle c'est le hal de Laurentcnc?
à+

C'est bien ça. J'avais laissé tombé pncconf pour générer une config.
Je suis vraiment allé au plus simple, en 2 étapes:
- D'abord pour vérifier le fonctionnement des règles et leur configuration dans le fichier hal sans mettre en route toute la machine.
J'ai pris les fichiers de Laurent_CNC tels quels, en virant tous ce qui est "input" (appellé I/O dans la doc, tout ce qui ressemble à hm2_5i25.0.7i77.0.0.input-13, les switch en gros) sinon Linuxcnc ne démarre pas si on n'alimente pas cette partie de la carte en 24v. J'ai donc juste raccordé les sorties des règles (qui sont bien repérées sur la 7i77, les signaux A B et l'index) et une alim de PC pour alimenter la 7i77 et les règles en 5v. Mes cartes 5i25 et 7i77 faisaient partie d'un "kit" avec le bon cable db25 donc la 5i25 avait déjà le bon firmware (sinon il faut la flasher avec mesaflash). En tournant les vis à billes à la main et avec un comparateur j'ai vérifier que je mesurais bien des millimètres et dans le bon sens (valeur et signe de ENCODER_SCALE)

- Ensuite pour commander les drivers en +-10v, c'est 2 fils par axe dont un à la masse. Là aussi sur la 7i77 y'a pas à se poser de question il y un connecteur pour chaque axe et déjà ce qu'il faut dans le fichier hal. Pour l'activation des drivers j'avais déjà "schunté" l'ancienne CN pour qu'ils soient activés en relachant l'arrêt d'urgence et après avoir appuyé sur le bouton resté d'origine marqué "Feed On", j'avais testé les drivers en appliquant 1.5v avec une pile pour la consigne de vitesse. Donc un fil qui vient d'un driver appellé du genre "variateur prêt" relié directement aux 3 fils "enable" des drivers. L'arrêt d'urgence ou les switch de fin de courses coupent bien les drivers comme d'origine. Dans les armoires (disjoncteur, relais, transfos et variateurs) je n'ai absolument rien touché et dans le pupitre j'ai enlevé les boutons qui ne me serviraient pas (les boutons de déplacements des axes, le clavier du PC me va bien pour ça) j'ai juste placé les boutons différemment pour pouvoir placer l'écran comme je voulais.
J'ai rajouté sur la 7i77 l'alimentation 24v (=VIN=VFIELD dans la doc de la 7i77) qui arrivait déjà dans le pupitre.
Avant de mettre en route, je me suis assuré que les axes étaient loin des butées et j'ai modifié les valeurs des termes des PID (en fait seulement 2 paramètres par axe, les termes P et FF1) pour commencer en douceur avec des vitesses de déplacement lentes. En 5min j'avais déjà quelque chose de pas mal.

Après seulement je me suis penché sur les POM mais le plus dur était déjà fait et ça fait très peu de fils à brancher sur la 7i77.

Pour jéjé, si tu veux garder ta machine opérationnelle, ça me semble possible de poser tes boitiers EXE et la 7i77 sur une table et tu as seulement les 3 cables des règles et les 3 pour les consignes de vitesse des drivers à débrancher pour faire des essais et te faire la main avec Linuxcnc. Et rien qu'avec ça la machine peut fonctionner.
Bon, j'ai essayé de résumer ce que j'ai fait, pour "démystifier" la chose aussi. Si ça peut servir à d'autres pour se lancer, y'a pas besoin de tout comprendre au fichier hal. Le reste c'est du "plus", pour se faire plaisir et personnaliser la machine.

A+

wapiti, ne vire pas tout. Garde ce qui est fonctionnel, remplace juste le bazar (l'ancienne CN) qui se situe entre les règles et les consignes des drivers!

 

[Bruno26]

jéjé, une relecture rapide de ton post m'a été utile. A propos des offsets sur les drivers et des tachymetres. J'ai surtout sur l'axe Z des petites oscillations, de quelques microns mais cycliques et un peu agaçantes. L'offset ou une bande morte (dans Linuxcnc) n'y change pas grand chose alors j'ai jeté un oeil au tachy du servo du Z. C'est sans doute lui le fautif, les charbons sont un peu au bout du rouleau. En essayant de sortir un de ces charbons, sont support en plastique dur c'est partiellement désintégré .
Donc j'ai passé un peu de temps sur le net à chercher une solution de remplacement. D'ailleurs des charbons de cette taille je n'en ai vu nulle part (3*4.6mm).
Selon les dimensions je pourrai utiliser ça et leur refaire un support :

https://www.ebay.fr/itm/Les-Balais-...arbons-HR2400-6820V-6822-6904VH-/171390210034

Ou sinon ça à modifier aussi, ça y ressemble beaucoup:

https://www.toomanytools.com/charbo...31942-charbons-c18dd-c18pp-4002395899043.html
J'ai justement une perceuse makita sans fil, je vais voir à quoi ressemblent ses charbons.

Par ailleurs, dans le montage d'origine, il y a un ressort derrière le charbon avec une tresse soudée sur une "rondelle" mais le contact avec le fourreau métallique me paraît très hasardeux.

A+

 

[gaston48]

Bonjour,
Il y aurait une solution qui réglerait ce probleme de tachy: ce serait de renvoyer à l'ampli
un signal de vitesse calculé par linuxcnc à partir de la règle
L'info de vitesse on l'a, il faudrait l'injecter sur l'une des 3 sorties +/- 10 V encore
disponible et de comparer au scope avec le vrai signal de tachy pour affiner le
gain.

Après, il faut voir s'il est toujours indispensable de garder l'asservissement en vitesse
de l'ampli. C’était indispensable avec la boucle de calcul de PID très lente des
anciens processeurs.

 

[Bruno26]

A vrai dire j'ai essayé de sans le tachy en partant avec le gain P de linuxcnc plus petit, ça marche pas. J'ai survolé la doc du variateur sans y comprendre grand chose (ça me fait vite mal au crane de tenter de déchiffrer de l'anglais!), y'a peut-être moyen de diminuer le gain quelque part dans le variateur. S'il n'y a pas de terme intégral dans le variateur, ça devient alors juste un ampli de puissance sans l'info du tachy.
Ca serait sans doute mieux effectivement avec une info reconstituée à partir de la règle. Mais j'ai quand même un doute. Même avec des vis à billes il y a du jeu, entre le servo et la vis il y a une paire d'engrenage. Et c'est justement autour de ce baklash qu'il y a oscillation. Le servo peut tourner sans que la règle ne voit encore un déplacement, elle a un temps de retard. Après je ne sais pas quelle est la sensibilité d'un tachy analogique même en bon état.
Sinon un petit codeur incrémental collé au servo ne me couterai peut-être pas plus cher que 4 charbons et là je pourrai utiliser une entrée codeur de la 7i77 pour reconstituer du +-10v. L'idée est à creuser.

 

[jéjé]

merci beaucoup pour vos réponse et infos.

Pour mon problème d'oscillation. Il n'est présent que par temps froid.... L'été, aucun soucis, même au démarrage de la machine. L'hiver, tant que la machine n'a pas bien chauffé, elle a ces oscillations. Apres avoir tourné un moment, ça disparaît.
Donc l'hiver, quand j'ai des pièces avec du surfaçage qui doit être impeccable à faire, je la fait bien chauffer avant.

ça me faisait plus penser à des dérives de composants analogique dans le drive (??)

 

[Bruno26]

Bon, c'est décidé, j'essaie avec ce que j'ai sous la main. L'encodeur de la mainvelle (jog) d'origine, un Heidenhain 450H.
Une doc qui s'y rapproche, un 450 sans le H:
http://stanki-used.com.ua/image/PASSPORT/CNC/ROD_450_Incremental_Rotary_encoder_Heindenhain.pdf
Il faut que je rajoute quelques fils depuis la carte d'interpolation.
Cette solution me plait bien plutôt que des antiques charbons.
Merci gaston pour l'idée
A+

 

[Bruno26]

Après avoir tatonné un peu avec les fichiers hal et ini, ça marche du tonnerre avec l'encodeur rotatif à la place du tachymètre. Ca oscille d'1 micron à peine, l'arbre du moteur ne bouge que très peu.
Il faut dire que j'ai soigné l'installation...

Promis, je ferai mieux! Là c'était juste un essai de principe, mais c'est carrément très prometteur
A+