Retrofit petite Realmeca avec cartes MESA

[matt07600]

Bonjour tous le monde, j'ai pris le temps d'avancer sur ma réalméca, pour un souci de manutention j'ai dû la démonter entièrement mais j'ai quasiment fini le remontage (je me suis régalé pour le remontage des rails à billes de la broche).
Par contre j'ai un problème lors de la prise d'origine machine :
Des fois tout se passe bien mais souvent la machine se met en défaut pendant qu'elle cherche l'index après avoir touché le capteur home, cela se passe aléatoirement aussi bien sur l'axe X,Y ou Z. J'ai essayé de baisser l'avance de 0.4 à 0.3 mais ça ne change rien.
(j'ai les mêmes réglages que Laurent dans le fichier.ini)
Bonne semaine à tous.

 

[Laurent_CNC]

Salut Matt,

J'ai le même soucis, de façon aléatoire et sur l'axe X et le Z.
Je pense que c'est dû au "1/2 tour maximum avant index" qu'avait expliqué Gaston.
N'ayant jamais réglé précisément les butées je l'ai mis sur ce compte là en tout cas...

J'avoue que vu ma fréquence d'utilisation de la machine, ça ne pose pas trop de problème.
Elle fonctionne toute la journée ou pas du tout pendant un mois...

Tiens moi au jus et si tu veux que je test des trucs sur la mienne, dis moi quoi.
@micalement,
Laurent

 

[matt07600]

Salut Laurent, du coup il faut juste décaler le point de contact des capteurs "home" et re régler les fdc?
C'est 1/2 tour maxi du moteur ?
Parce qu'il me semble que ça fait plus mais je me trompe peut-être.
Je vais essayer de retrouver les explications de Gaston.
@+

 

[gaston48]

Bonjour à vous deux...
1/2 tour serait la position "optimale" après le moment du relâchement du contact de fin course.
de façon à laisser "plus ou moins" le maximum de marge aux incertitudes de la position de déclenchement
du contact.
La vitesse peut avoir un effet sur votre défaut ainsi que, je pense, des rebonds intempestifs du contact.
Il faut faire passer les signaux des contacts à travers le composant "debounce"

http://linuxcnc.org/docs/2.7/html/man/man9/debounce.9.html

Donc toujours la même "musique" dans le fichier HAL

loadrt debounce cfg=3

addf debounce.0 servo-thread

setp debounce.0.delay (il faut que je trouve l'unité du time delay ?)

http://git.linuxcnc.org/gitweb?p=li...70a9a6dc4f84e1e354d8f8869b2bc388c1ea0;hb=HEAD

 

[Laurent_CNC]

Gaston, tu es trop rapide, je n'ai pas eu le temps de finir de taper

Oui c'est ça, Gaston conseillait de ne pas dépasser un demi tour entre la mise en marche arrière et le contact Index.

Franchement, pour moi, il n'y a rien de gênant, je dois au pire relancer la procédure une fois pour cause d'erreur sur un des axes.
Après plus de soucis.
Mais si on peut optimiser et enlever cette erreur, ca ne sera que mieux.
Matt, si la manip de Gaston fonctionne tu pourras me faire un retex ?

Merci d'avance,
Laurent qui se penchera la dessus en même temps que sur sa pompe de lubrification qui refuse de tourner depuis que j'ai installer un joint spi neuf... (c'est sûr que maintenant ça ne fuit plus )

 

[gaston48]

https://forum.linuxcnc.org/38-gener...-limit-error-setting-up-debounce?limitstart=0

Plus précisément,

Andy choisit une base-thread mais ça ne veut plus rien dire sous Mesa !
on est plus certain de fperiod dans un servo-thread

loadrt debounce cfg=3

addf debounce.0 base-thread ou servo-thread

setp debounce.0.delay 20

la valeur par défaut serait 5 Andy met 20 à priori ? 20 périodes de servo-thread ?

net input => debounce.0.0.in
net input => debounce.0.1.in
net input => debounce.0.2.in

net debounce.0.0.out =>
net debounce.0.1.out =>
net debounce.0.2.out =>

 

[matt07600]

Ok merci Gaston je teste ça quand je peux...

Matt, si la manip de Gaston fonctionne tu pourras me faire un retex ?

Pas de soucis

 

[gaston48]

Donc on choisit bien un servo-thread

normalement fixé à 1000000 ns donc x 20 nous ferait un delay de 20 ms

 

[gaston48]

Il y avait encore des erreurs dans la syntaxe du composant
les posts sont corrigés

 

[matt07600]

Merci Gaston

 

[Laurent_CNC]

https://forum.linuxcnc.org/38-gener...-limit-error-setting-up-debounce?limitstart=0

Plus précisément,

Andy choisit une base-thread mais ça ne veut plus rien dire sous Mesa !
on est plus certain de fperiod dans un servo-thread

loadrt debounce cfg=3

addf debounce.0 base-thread ou servo-thread

setp debounce.0.delay 20

la valeur par défaut serait 5 Andy met 20 à priori ? 20 périodes de servo-thread ?

net input => debounce.0.0.in
net input => debounce.0.1.in
net input => debounce.0.2.in

net debounce.0.0.out =>
net debounce.0.1.out =>
net debounce.0.2.out =>

C'est jamais aussi simple...
je me doutais qu'il fallait mettre qq chose à la fin des 3 dernières lignes mais je n'ai pas réussi...
J'ai essayé ces 7 valeurs :
hm2_5i25.0.7i77.0.0.input-23
net home-z
axis.2.home-sw-in
net z-index-enable
axis.2.index-enable
hm2_5i25.0.encoder.02.index-enable
pid.z.index-enable
en prenant exemple de l'axe Z.... mais rien n'y fait, j'ai un bug à chaque fois...

C'est surement encore très con... mais je ne pine pas cette phrase :
debounce.G.F.out bit out

The F’th output pin in group G. Reflects the last "stable" input seen on the corresponding input pin.

 

[gaston48]

Donc après avoir charger 3 voies du composant debounce, tu vas simplement inserer une voie
comme ça:

avant:

net home-z <= hm2_5i25.0.7i77.0.0.input-23
net home-z => axis.2.home-sw-in

après:

net home-z debounce.0.2.in <= hm2_5i25.0.7i77.0.0.input-23
net filter-home-z debounce.0.2.out => axis.2.home-sw-in

 

[Laurent_CNC]

rahhhh j'ai essayé pas mal de config différentes mais rien n'y fait ca bug...

Le dernier hal :

Vous devez être connecté pour voir ce contenu.

 

[Laurent_CNC]

net home-x debounce.0.0.in <= hm2_5i25.0.7i77.0.0.input-21

il plante ici en me disant que debounce est déjà linké a 'input'
...

 

[gaston48]

C'est bon, il y a juste "ça" qui traîne et qui est en trop

net input => debounce.0.0.in
net input => debounce.0.1.in
net input => debounce.0.2.in

dans mes message précédent, "ça" était juste un extrais de la syntaxe

 

[Laurent_CNC]

OK, merci

Alors LInuxCNC ce lance mais la POM est toujours aléatoire.
Ca vient de planter...

 

[Laurent_CNC]

6 autres tests consécutifs ont fonctionnés d'affilés, je continue
J'annule mes pom et je relance tout semble fonctionner en fait.

et bim... ca plante sans raison... le pb n'est pas réglé...

tant que je te tiens, sais tu ou je peux régler pour que dès le démarrage c'est l'affichage de la position commandé qui est affiché et pas la position piloté ??
j'ai trouvé... c'est dans le INI
POSITION_FEEDBACK = ACTUAL - Valeur de la position (COMMANDED ou ACTUAL) à afficher au démarrage de l’interface utilisateur. La position COMMANDED est la position exacte requise par LinuxCNC. La position ACTUAL est la position retournée par l'électronique des moteurs.

Matt voici le hal à tester toi aussi :

Vous devez être connecté pour voir ce contenu.

 

[matt07600]

Je teste ça dés que possible

 

[Laurent_CNC]

Salut à tous,

J'ai aussi contrôlé visuellement mon décalage et je suis bien à moins d'un demi tour.
On entend bien de déclic du capteur a l'aller comme au retour et en regardant la visu j'ai bien moins de 2 mm de déplacement sur la phase de "marche arrière".

Ca semble correct vu que la vis fait un pas de 4 il me semble.

 

[gaston48]

Bonjour,
On peut augmenter sans problème la tempo de debounce, mais ce qui serait bien c'est de trouver
à quel moment, si c'est possible de l'observer, l'erreur est déclenché ?
Si c'est dans les transitions du switch ou si c'est une absence ou tout au moins au
moment de la détection de l'index donc après que le switch a bien fait son travail ?

Il y a un détail au niveau des paramètres d'encodeur, que je ne comprends pas bien, c'est
le filtrage. Il agit sur le 3 entrées ?, donc l'index et serait susceptible d’éliminer un parasite,
mais peut être le signal utile aussi ... le mettre à 0 pour voir .

Ensuite, on peut essayer de trouver la ou les variables qui amplifient sans équivoques le problème
comme la vitesse ou le gain d'asservissement (qui entraînerait des oscillations sur l'index)

 

[Laurent_CNC]

OK, merci Gaston
J'essaye de détecter l'enclenchement cette après midi et je tiens au courant.
Je peux tester 0 5 10 20 pour voir si ça fait évoluer le soucis.
Le truc c'est que, comme hier soir par exemple, ça marche 6, 7 fois et d'un coup, t'as un plantage...
Mais je vais gratter un peu, ne fusse que pour faire avancer le schmilblick car en fait c'est peu génant et une fois que les POM sont faites tu n'y touches plus de la journée normalement.

@ tout'

 

[Laurent_CNC]

Mes avancements du jour.
avec 5 ça a planté aussitôt sur home Z
avec 10 ça semble tenir (j'ai déjà fait une dizaine de POM d'affilées)

Le plantage semble avoir lieu après le déclic

 

[gaston48]

Tu parles bien de la valeur du delay de debounce ?
Manifestement c'est bien au niveau du switch que se situe le problème alors.
On peut tenter un delay de 50 aussi ...
Il faut également qu'un certain courant circule dans ce genre de contact qui n'est pas doré
sinon il y a des problèmes avec l'oxydation naturelle. Tu peux aussi tenter de
pulvériser un nettoyant contact si tu penses qu'il peut pénétrer.

 

[Laurent_CNC]

Le défaut à lieu "bien après" le déclenchement du switch.
On entend bien le premier clic à "l'aller" puis le second clic au "retour" et c'est seulement après que ça plante.
Tu penses que ça pourrait venir d'un mauvais contact électrique ?

Sinon, oui je modifie bien le debounce. Je vais aller le tester à 50.

@+
Laurent qui a fumé sa pompe à lub... j'suis dégoutté...

 

[gaston48]

Mauvais contacts ou rebonds entraînent, à mon avis, les même effets. une foi le contact fermé,
linuxcnc attend le top index, si le contact se rouvre, meme briévement, il se plante.
Surtout que la norme de sécurité concernant le mode de branchement d'un contact
veut qu'il soit normalement fermé elctromécaniquement parlant (donc indépendamment d'une inversion d’état soft)
ce qui veut dire qu'au retour, une foi le switch franchi, c'est au moment de sa fermeture que linuxcnc
attend le top index. S'il y a des rebonds cela s'élimine avec le debounce, le train d'impulsions
de rebonds est bien localisé dans le temps mais un mauvais contact entraînent des sortes de rebonds
mais sur une période plus longue.
Tu peux tenter de faire un autonettoyante des contacts en débranchant juste les 2 fils et avec une
pile et une résistance série, faire commuter avec un courant d'une centaine de milliampère.
Tu peux démonter le contact aussi, si c'est du genre microswitch crouzet et glisser une feuille de
papier imbiber de nettoyant contact entre les 2 contacts.

Condoléance pour ta pompe , ce ne sont pas des moteurs très coupleux et puissant
j'ai toujours vu des chicanes ou autre dispositifs, un joint spi consomme beaucoup de
couple

 

[Laurent_CNC]

Bon, j'ai testé d'autre valeurs de debounce et suis revu à 20 qui était la valeur de départ... par défaut.
En attendant de pouvoir tester mes contacts et d'avoir le retour de Matt, j'ai modifié un truc.
La vitesse du mouvement après le déclic du switch.
J'ai essayé en la diminuant encore (passé de 0,5 à 0,2). Plantage d'entrée de jeu...
Du coup je l'ai assez fortement augmenté (passé de 0,5 à 2) et 3 tests consécutifs n'ont pas amené de plantage.
Je ne sais quoi en pensé, les erreurs étant très aléatoire. Je referais des tests demain pour con ou in firmer...

@+
Laurent

 

[gaston48]

Le code est ici:
http://git.linuxcnc.org/gitweb?p=li...81290ed84f79fbfd8b981fcc3ddae64091761;hb=HEAD
Je capte pas grand chose, mais je ne vois pas d'allusion à une tempo limite quelconque
Peut être en remontant au message de plantage original (avant sa traduction éventuelle).
Dans la doc, il n'y pas de remarque sur une limite trop basse de cette vitesse. Le code dans un environnement
temps réel est très capricieux aussi.
Voir l'influence éventuelle du filtrage de l'encodeur comme je le suggérais précédemment .

 

[Laurent_CNC]

Salut Gaston,
J'ai été très basique dans ma réflexion.
Je me suis dit que comme un switch n'est jamais qu'un interrupteur, et que ceux ci quand ils sont manipulés trop doucement font des étincelles,
ben peut être qu'il fallait une certaine "franchise" dans la fermeture pour assurer le coup...

Je dis ça et peut être que ce matin, elle va planter...
@ tout' pour la suite

 

[Laurent_CNC]

Basique mais ça semble efficace.
J'ai redémarré ce matin et fait 4 fois le test des POM sans erreurs... aurais je trouver la solution ??? le temps nous le dira.

Matt, ça vaut le coup d'essayer, tu ne modifies que la valeur de la vitesse de retour sur chaque axe dans le .INI

@+
Laurent

 

[gaston48]

Normalement le mécanisme du switch comporte un ressort en genouillère qui entraîne,
au delà d'un seuil, un déclenchement instantané. Donc la vitesse d'approche du seuil n'a
pas d'importance.
Devant le même problème, j'aurais augmenté la vitesse pour entraîner un défaut systématique
et confirmer la source ... c'est là qu'on constate un effet inverse ... et cela devient un sujet de
recherche .