Contact home et Limite

[Serge62000]

Bonjour,


je possède une petite fraiseuse CNC 6040 que j’ ai acheté en pièces détachées j’ ai ajouté 2 contacts par axe pour les limites +,- & le Home, le montage se termine mais je sèche sur un problème de “contact de limite” sur LinuxCNC quand je paramètre avec uniquement le “home contact ”, la POM fonctionne parfaitement , si je paramètre “contact home + les 2 limites” j’ ai une erreur à la mise en route dans AXIS “jointure 0 en erreur sur un contact de limite”, je ne peux faire fonctionner la machine qu’ en cochant hors limite.
Je fais les tests uniquement sur l’ axe X pour le moment.

Quelqu’un peut-il m’ indiquer des pistes ou chercher , car j’ arrive au bout de mes connaissances ?.

Je joints les fichiers de config .ini et Hal pour éviter de surcharger le post .

Merci à tous .
Serge B. Voir la pièce jointe CNC-6040-hal.txt Voir la pièce jointe CNC-6040-ini.txt

 

[bipbip30]

bonjour serge62000, je vais suivre les réponses à tes questions moi je n'en suis pas encore là mais pourrait tu me dire le temps de latence obtenu et quelques détails sur ta config, tu peux répondre là https://www.usinages.com/threads/ordi-compatible-linuxcnc.82217/ si tu ne veux pas encombrer ton sujet. Merci d'avance

 

[gaston48]

Bonjour,
Je vois que les switches X rentrent sur la pin 12 du port //
Mais comment as-tu câblé les 3 interrupteurs de l'axe X ?
les 3 NO ou NF
voir fin d'ici:
http://linuxcnc.org/docs/2.7/html/config/stepconf.html

 

[Serge62000]

Bonjour Gaston48,
les switch X+ & X- sont câblés en NF avec la résistance de rappel sur la carte Breakout (en série pour chaque axe).
Quand on lance Hal mètre dans AXIS les switch fonctionnent bien (passant de TRUE à FALSE).
Merci pour ta réponse
Serge B.

 

[gaston48]

Pour avoir confirmation
Il faut que tu vérifies avec hal meter la variable both-home-x
Elle doit bien être à 0 FALSE quand aucun des 3 switchs est activé.

Les trois entrées suivantes sont activées si elles voient un 1 : TRUE

axis.N.home-sw-inIN BIT
Should be driven TRUE if the home switch for this joint is tripped.


axis.N.neg-lim-sw-inIN BIT
Should be driven TRUE if the negative limit switch for this joint is tripped.

axis.N.pos-lim-sw-inIN BIT
Should be driven TRUE if the positive limit switch for this joint is tripped.

Ici il y a les 3 lignes du .hal concernées
Le niveau logique du port// est dans un premier temps inversé par
le suffixe –not avant de fixer la valeur de la variable « both-home-x »
(le nom de cette variable est libre, c’est toi qui peut l’inventer )

net both-home-x <= parport.0.pin-12-in-not

Puis la valeur de la variable est affecté au 3 entrées de axis

net both-home-x => axis.0.home-sw-in
net both-home-x => axis.0.neg-lim-sw-in
net both-home-x => axis.0.pos-lim-sw-in

 

[Serge62000]

Oui c' est bien la même config que tu proposes qui est dans mon fichier .Hal, mais j' ai un doute car lorsque je mets "ON" dans
l' interface AXIS en maintenant un des 2 switch actif je n' ai plus l' erreur.
Est-il possible dans le fichier hal d' avoir 2 variables pointant sur un même port ?.
ex:
net both-home-x <= parport.0.pin-12-in-not
net My-limit-x <= parport.0.pin-12-in

 

[gaston48]

Oui c' est bien la même config que tu proposes

Ben oui, j'ai rigoureusement copié la tienne

Peux tu répondre à ma question avec hal meter (une chose à la foi si tu veux bien) ?

(hal meter peut tout afficher, signaux, variables etc)
Sinon ne t'inquiète pas, on peu inverser un signal logique en cours de route.
Ce qu'on ne peut pas faire, c'est 2 signaux vers une même variable.
Ta solution semble conforme, le tout est de savoir si on peut sortir
2 signaux différents de la même pin d'entrée. Il faut essayer, si ça ne
va pas le debuggeur se manifestera tout de suite.
Attention si tu modifies à l'éditeur, les modifications seront perdues
si tu recharges stepconf. Tu peux créer un autre répertoire avec le nom
de machine que tu veux et sauver tous les fichiers, soit pour les sauvegarder,
soit pour les modifier à volonté.

 

[Serge62000]

Désolé je n' avais pas vu la question, les switch sont TRUE non activé & FALSE activé .
Je n' ai que deux switch en tout : un qui me sert de limite - & home l' autre switch limit +.
Mon problème persiste quand je mets uniquement les 2 limites et pas le home.
Merci pour ton aide.
Serge B.

 

[gaston48]

Quand un switch sert de limite et de home, il y a 2 conséquences:
Il faut neutraliser l'action du switch limite quand il sert de homing
il faut absolument que le homing se fasse un axe à la foi pour des raisons de sécurité.

Dans .ini, et dans chaque section, il faut donc retrouver les lignes:
[axis_0]
HOME_IGNORE_LIMITS = yes
HOME_SEQUENCE =0

[axis_1]
HOME_IGNORE_LIMITS = yes
HOME_SEQUENCE =1

[axis_2]
HOME_IGNORE_LIMITS = yes
HOME_SEQUENCE =2

Ensuite, il y a une anomalie de résultat quand tu actionnes un switch.
Si chaque switch pris individuellement à l'ohmmètre devient ouvert quand tu l'actionnes, il est bien NF
et il doivent être câblés en série. Donc ils maintiennent à 0V le 5V qui est sinon présenté aux entrées à travers
la résistance de pull up. Quand on actionne un des switchs, on supprime la mise à la masse et
le 5V apparaît à l'entrée. Dans ce cas, la bonne ligne est la suivante:

net both-home-x <= parport.0.pin-12-in
pour que both-home-x soit TRUE quand il est actionné.

Si tes switchs sont NO, là il faut les cabler en // et la bonne ligne devient:
net both-home-x <= parport.0.pin-12-in-not

 

[Serge62000]

je suis bien dans la configuration que tu préconises pour le fichier .ini.
Comme j' ai fait pas mal de modifications cet après-midi , je suis un peu perdu je regarde demain
la config que j' ai laissé.
Merci encore & bonne soirée.
Serge B.

 

[Serge62000]

bonjour,

j' ai avancé avec tes explications :

- Je n' ai plus d' erreur au lancement de AXIS.
- Mes switch sont bien NF.
- Dans le fichier Hal j' ai fait les modifs comme tu le précisais plus haut.
- Dans le fichier .ini j' ai bien les deux lignes que tu indiques, mais j' ai l' impression que :
HOME_IGNORE_LIMITS = YES n' est pas pris en compte car j' ai une erreur lors du homing
individuel de l' axe X, (jointure 1 en erreur sur un contact de limite) et la même avec jointure 2.
Les contacts sont bien FALSE (GND) au repos & TRUE (5V) activé & en série sur un axe.
Ma version Linuxcnc 2.6.4.

Serge B.

 

[gaston48]

Bonjour,
Tu confirmes bien avec halmeter / signaux que both-home-x passe à true quand tu l'actionnes ?
As-tu bien configuré les autres axes de la même manière que le l'axe x ?
A part le fait que si tu choisis butée moins = home, le sens de recherche SEARCH devrait être négatif
et LATCH positif, je ne vois pas ???

HOME_SEARCH_VEL = 1.500000
HOME_LATCH_VEL = -1.500000

 

[Serge62000]

Bonsoir,

Je vérifie les derniers points que tu m' indiques , mais plantage LINUX pendant MAJ en 2.7, donc je ré-installe une version demain matin, mais il me semble que les deux constantes que tu indiques étaient en négatif.
Bonne soirée
Serge

 

[Serge62000]

Bonjour,

nouvelle version de Linuxcnc, même problème, tous fonctionnent quand on met uniquement les switches Home & erreur
quand on ajoute la ou les limites max-min.
J' ai imprimé quelques doc pour essayer de combler mes lacunes car je ne suis pas sûr d' avoir tous compris.
Pour le moment je vais faire tourner la machine sans limite, et reviendrai sur ce post plus tard.

Gaston48, sincères remerciements pour ton implication dans mon problème.
Serge B.

 

[gaston48]

Pour le moment je vais faire tourner la machine sans limite, et reviendrai sur ce post plus tard.

Ok, quand tu veux.
C'est sans doutes un truc tout bête (comme souvent).

 

[jblb72]

juste uun petit mot pour dire que je suis comme @Serge62000 au niveau des swicth home et limit et que je n'ai pas réussit a les faire fonctionner avec les deux fonctions, je me suis contenter de les utiliser en home et m'était dit que je verrais ça plus tard. Peut être qu'il est temps que je m'occupe de ça. En général quand on réfléchis a plusieurs on a plus d'idées pour avancer.

 

[Barbidou]

Bonjour,

Nous avons rencontré le même genre de problème lors du réglage de nos fin de courses. C'était dû au parasites sur les entrées malgré l'utilisation de câbles blindés et de condensateurs.

Nous l'avons mis en évidence avec HALscope qui montrait clairement les parasites, HALmeter ne permet pas de les voir car ils sont trop courts et on n'arrive pas à les attraper.

Le remède a été d'instancier un composant debounce sur les entrées. Depuis, plus aucun problème de cet ordre n'a été rencontré...

 

[Serge62000]

Bonjour,

j' ai pensé aux parasites à l' activation des contacts , mais tout fonctionne parfaitement quand on met uniquement max-lim ou (et) min-lim ou home, c' est uniquement lorsqu' on mixe une limite avec un home. J' ai testé avec un analyseur logique et le signal est complètement
acceptable en niveau logique, je pense à un pb logiciel plutôt que hardware.

je vais tenter quand même la méthode debounce dans quelques temps.

Merci
Serge B.

 

[bipbip30]

Le remède a été d'instancier un composant debounce sur les entrées

bonjour, là moi je ne comprends pas, peux tu me traduire ça pour un néophite svp

debounce c'est le anti rebond ok mais précisément qu'as tu fais

 

[gaston48]

Un composant hal que tu intercales dans le "câblage virtuel" du fichier hal.

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

Une façon d'assimiler les possibilités de Linuxcnc est de prendre connaissance de tout ses
composants hal
En bas de la page : http://linuxcnc.org/docs/2.7/html/
"Realtime components and kernel modules"
A savoir aussi qu'on peut facilement modifier ou écrire et compiler son composant hal

 

[Barbidou]

Bonjour,

Désolé pour le manque de clarté...

Concrètement ça donne un truc comme ça : (à adapter aux signaux de la machine, là, j'ai simplement pris une entrée par axe pour montrer le principe)

# Chargement du composant debounce pour 3 signaux
loadrt debounce cfg=3

# Réglage du delai à 200 périodes du thread de base
setp debounce.0.delay 200

# Ajout du composant dans le thread de base
addf debounce.0 base-thread

# Recupération des valeurs des switchs dans des signaux :
net both-home-x <= parport.0.pin-12-in-not
net both-home-y <= parport.0.pin-13-in-not
net both-home-z <= parport.0.pin-15-in-not

# Connection des entrées et sorties des filtres
net debounce.0.0.in <= both-home-x
net debounce.0.0.out => debounced-both-home-x
net debounce.0.1.in <= both-home-y
net debounce.0.1.out => debounced-both-home-y
net debounce.0.2.in <= both-home-z
net debounce.0.2.out => debounced-both-home-z

# Utilisation des signaux filtrés
net debounced-both-home-x => axis.0.home-sw-in
net debounced-both-home-x => axis.0.neg-lim-sw-in
net debounced-both-home-x => axis.0.pos-lim-sw-in
net debounced-both-home-y => axis.1.home-sw-in
net debounced-both-home-y => axis.1.neg-lim-sw-in
net debounced-both-home-y => axis.1.pos-lim-sw-in
net debounced-both-home-z => axis.2.home-sw-in
net debounced-both-home-z => axis.2.neg-lim-sw-in
net debounced-both-home-z => axis.2.pos-lim-sw-in​

Il y a peut-être un ou deux ajustement à faire, je n'ai pas LinuxCNC sous la main et je n'ai donc pas pu tester ce code (mais le principe est là)...

 

[Barbidou]

Re-Bonjour,

Un truc qui peut aussi te causer des soucis, ce sont les deux lignes en orange dans ton fichier .ini :

[AXIS_2]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 5.25
MAX_ACCELERATION = 60.0
STEPGEN_MAXACCEL = 75.0
SCALE = 320.0
FERROR = 1
MIN_FERROR = .25
MIN_LIMIT = -65.0
MAX_LIMIT = 0.001
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -1.500000
HOME_LATCH_VEL = 1.500000
HOME_SEQUENCE = 0​

HOME_OFFSET = 0.000000 définit la position du switch à la position 0.
HOME = 0.0 définit la position home à la position 0.

Lors de la prise d'origine, la machine va chercher le switch, quand elle l'a trouvé elle en déduit qu'elle est à la position 0. Suite à cela, elle retourne à la position home (soit 0)... Donc elle ne bouge pas. Une fois la prise d'origine faite, les limites sont prises en compte. Hors, la machine étant toujours en position 0, le switch est toujours actif. L'erreur est donc signalée.

Pour éviter celà, deux solutions :

si tu veux que le switch soit en position 0, tu met l'origine machine un peu plus loin :
HOME = -5.0
HOME_OFFSET = 0.0
MIN_LIMIT = -65.0
Les valeurs utilisables sur l'axe sont alors dans l’intervalle [-65 ; 5]

ou, pour avoir l'origine machine en 0 (ce qui est plus sympa à mes yeux), tu place le switch sur une position légèrement dégagée :
HOME = 0.0
HOME_OFFSET = 5.0
MIN_LIMIT = -60.0
Les valeurs utilisables sur l'axe sont alors dans l’intervalle [-60 ; 0]

La valeur de la limite opposée est à ajuster pour conserver la même longueur de course.

(Attention, c'est donné ici pour l'axe z dont les valeurs sont dans la plage négative, pour le x ou le y, ça change un poil...)

Ainsi, à la fin de la prise d'origine, la machine retourne en position home et le switch est relâché.

C'est bien entendu à faire sur les trois axes...

 

[gaston48]

Je ne suis pas certain Barbidou, ou tout au moins, je ne l'ai pas compris comme ça.
Dans tous les cas, quand le switch a été activité, linuxcnc inverse
le sens de déplacement jusqu'à désactiver le swiitch et là il compte son déplacement home.

Les déplacements sont bien configurés pour s'inverser
HOME_SEARCH_VEL = -1.500000
HOME_LATCH_VEL = 1.500000

C'est cette valeur d'hystéresis avant arrière que tu rentres dans le home_offset

 

[Barbidou]

Si tu reprends le graphique que tu as donné, tu verras que la dernière étape n'est pas un relâchement du switch, mais bien un retour vers la "home" position ("go to home position") :

Le HOME_OFFSET est la position du switch.
L'étape précédent le retour à la position home consiste bien en un dégagement du capteur, mais comme elle est suivie du retour en position home, le capteur se retrouve à nouveau activé...

Quand le switch home assure aussi la fonction de switch limit, la position home ne peut pas être confondue avec celle du switch.

 

[gaston48]

Ben si ?
home switch is TRIPS dans un premier temps
overshoot puis je recule jusqu'à
home switch is RELEASE
et là, je constate un offset mécanique de 3 mais je peux le laisser à 0
C'est plus utile quand il y a un index de règle optique .

http://linuxcnc.org/docs/2.7/html/config/ini-homing.html

Mais ton raisonnement colle bien avec le problème ?

 

[Barbidou]

Effectivement, dans l'exemple de la doc on a un offset de 3 après le relâchement du switch, mais cette étape est normalement suivie par le retour en position home qui est à la valeur 1 dans l'exemple.

Dans le cas de contacts partagés, il faut également ajouter le paramètre HOME_IS_SHARED=1 (mais le problème de doit pas venir de là).

 

[bipbip30]

bonjour,

@j'ai déjà commencé à lire la doc de Linuxcnc mais il y a de la matière et puis il faut lire et relier pour digérer et cette commande debounce je ne l'avais pas en mémoire, j'avais plutôt penser à un anti-rebond sous forme de composants discrêts

@Barbidou, grand merci pour tous ces informations riches d'ensignements

 

[gaston48]

Après quelques manips, quelques petits éclaircissements sur les paramètres de homing, dans le cas du switch
de limite et de homing confondus.

HOME_IGNORE_LIMITS = YES

Avec des remarques sur l’incidence des distance de freinage sur la logique de fonctionnement
Exemple de fichier.ini

La machine dispose pour l’axe x, d’une course totale de 400 mm

MIN_LIMIT = -200
MAX_LIMIT = 200

Départ du cycle:
Ordre d’aller chercher le switch vers la limite négative donc avec une vitesse négative assez rapide
pour que globalement le homing soit rapide... donc de -100

HOME_SEARCH_VEL = -100

Arrivé sur le switch, qui est actionné, ordre est donné de freiner.
Donc, pendant la distance de freinage, il y aura dépassement de la position du switch. Il doit toutefois
être maintenu actionné.
Il faut prévoir cette distance de freinage avant une collision en buté mécanique.


Un fois stoppé, ordre est donné de revenir en arrière (valeur positive ici) en vitesse lente, à (+) 10 donc,
afin de relâcher le switch. (vitesse lent pour la reproductibilité de la commutation)

HOME_LATCH_VEL = 10

C’est cette transition action/relâchement qui initialise le compteur de position.
Au moment de l’initialisation, linuxcnc va charger ce compteur avec une valeur
de correction, celle du HOME_OFFSET, afin de faire coïncider exactement
l'espace de déplacement mécanique avec l'espace de déplacement soft
défini par MIN_LIMIT et MAX-LIMIT. Les signes de ces limites définiront simplement
la position du repère 0 dans axis.

Pour finir, Linuxcnc enverra un ordre de déplacement de cette position courante
à celle paramétrée dans home (qui peut être différente de 0)
Ce déplacement complémentaire se fera à la vitesse spécifié dans home_final_vel.
le signe de cette position courante comparé à la valeur de home détermine le
sens de déplacement final

HOME_OFFSET = -200
HOME = 0
HOME_FINAL_VEL = 200

Dans mon exemple :
Je veux que mon home 0 soit positionné à mi-course 400/2 donc
offset = -200, home = 0, donc linuxcnc enverra un ordre de déplacement de + 200,
car (-200 offset) vers (0 home) demande un (+ 200 déplacement)

Si cette valeur home_offset est laissée à 0, elle peut avoir certaines conséquences imprévues:
Il faudra d’abord freiner puis revenir en arrière rejoindre la position 0 de transition.
Comme le dit Barbidou, il est possible que le switch soit de nouveau activé, cela n’a pas
d’incidence tant qu’on est dans la fonction homing, mais dès qu’elle est quittée,
le switch est considéré comme "butée activée".

On a tout intérêt donc à prévoir un petit offset qui éloignera la position Home= 0 du switch.
idéalement à la distance de freinage nécessaire à la vitesse 10.

Autre exemple, toujours avec un course utile de 400 et un home proche de la butée moins.
sans perdre de course utile.

MIN_LIMIT = -5
MAX_LIMIT = 395
HOME_SEARCH_VEL = -100
HOME_LATCH_VEL = 10
HOME_OFFSET = -5
HOME = 0
HOME_FINAL_VEL = 200

Dans cet exemple, avec le jog, de la position home = 0, je peux aller de -5 à 395, au delà il y a butées softs .

Le comportement des déplacements en phase de homing de la simulation graphique
est un peu erratique à cause de la valeur arbitraire de l'offset et ne correspond pas
temporairement à la réalité.

Exemple de configuration fichier.hal avec port mesa.
La polarité du signal envoyé à switch est FALSE relâché TRUE activé

net switch_x <= hm2_5i20.0.gpio.071.in_not
net switch_x => axis.0.home-sw-in
net switch _x => axis.0.neg-lim-sw-in
net switch_x => axis.0.pos-lim-sw-in

 

[Serge62000]

Bonjour,

merci pour ton exposé je vais regarder celui-ci de plus près dans la journée, et faire des modifications si nécessaire.
Bonne journée
Serge B.

 

[gaston48]

J'ai corrigé un peu la rédaction pour être moins confus ...