Câblage Fins de course, Charlyrobot et port //

[RacingMat]

Bonjour,

je vois sur la carte d'interface du rack de commande de la Charlyrobot, qu'il y a des emplacements pour des contacts de fin de course.
J'aimerai bien utiliser des contacteurs fin de course pour protéger ma mécanique

Ma question est : sur les Charlyrobot,
l'info de fin de course est-elle à destination des drivers directement (1)
ou à destination du port // pour que LinuxCNC stoppe le moteur concerné (2) ?

Selon vos réponses, je verrai si je dois souder mes brins sur la carte de fond de panier (1)
ou si je dois laisser les brins libres pour simplement les raccorder aux fins de courses (2)

Merci !

 

[cr-_-]

Bonjour,

Il vaut mieux câbler les origines machines que les fin de courses (Reference ... axis sur ton tableau)
Mais sinon c'est à destination de linuxCNC (dans les deux cas d'ailleurs)

Pour les origines l'intérêt est d'avoir la position 0,0,0 toujours au même endroit et donc de connaitre la position des chariots sur les axes et donc d'avoir les fin de courses géré par linuxCNC
Le seul problème étant qu'en cas de perte de pas ils se produise un décalage.

 

[speedjf37]

Bonjour,

Le seul problème étant qu'en cas de perte de pas ils se produise un décalage.

bonjour,

+1 avec la réponse précédente

J'installe aussi des capteur à la position max de chaque axe (en // avec le contact origine).
Si par malheur il y a perte de pas ( arret urgence ou mauvais réglage au début) la mécanique ne part pas en butée.

JF

 

[RacingMat]

merci pour vos réponses @cr-_- @speedjf37 !

donc pour le principe, ça donne ça alors :

Zou, je vais dessouder les 6 conducteurs du câble parallèle que j'avais ramenés sur la carte de fond de panier
et les amener à un bornier pour câbler mes fins de course (en partageant la masse)

 

[cr-_-]

oui ça peut être ça,

après j'aurais tendance ne pas mettre les fins de courses avec les références, mais plutôt sur la même ligne que l'arrêt d'urgence ou une autre dédiée si tu as encore de la place sur ton port parallèle

 

[RacingMat]

oui, j'ai encore de la place : sur mon câble DB25, je n'en utilise que 7 pour dialoguer vers les 3 drivers
(9 si je voulais utiliser un 4ème axe)

donc je peux ajouter les références et aussi les fins de course à part.

L'avantage si je câble une fin de course sur chaque axe (et pas sur l'AU) je pense que LinuxCNC pourra m'afficher l'axe concerné (en espérant que ça ne serve jamais)

 

[speedjf37]

oui ça peut être ça,

après j'aurais tendance ne pas mettre les fins de courses avec les références, mais plutôt sur la même ligne que l'arrêt d'urgence ou une autre dédiée si tu as encore de la place sur ton port parallèle

l'avantage d'avoir les 2 contacts par axe permet de visualiser "->" sur l'axe en défaut sur linuxcnc

JF

 

[RacingMat]

Ok, je vais faire ça !

Pour la prise de référence, il faut un capteur plus précis ou pas forcément ?

J'ai vu des capteurs à roulette, des capteurs optique à fourche,...
vous avez des préférences ?

 

[biduleur34]

en fait pour la prise de reference pour etre plus precis il faut utilisé deux capteurs.

un capteur de position classique, style les microswitch en photo plus haut, et un second sur l'arbre de ton moteur d'axe. et tu met ces deux contact en série..

l’idéal est d'avoir un capteur optique ou sans contact sur le moteur, le plus fin possible.

C'est la dénomination Index ou Z sur les capteurs de position en quadrature.

il faut egalement que la longueur de captage de ton capteur mecanique soit superieure a la distance parcourue par 1 tour de ton moteur d'axe.sinon dans un cas extreme tu pert ton capteur mecanique alors que tu n'as pas encore fait un tour moteur.

par example:
5mm par tour moteur, il faut que ton microswitch est une plage de detection plus grande.

++
Léo

 

[RacingMat]

Merci pour ces détails @biduleur34 !

Je crois que je vois ce que tu veux dire En fait, il y a un positionnement à respecter pour éviter de peter ses switch en latéral et pas en frontal
Voici un petit croquis :

Pour la partie "quadrature" par contre j'ai pas compris...

 

[RacingMat]

@biduleur34 après mûre réflexion, tu voulais certainement dire parallèle et pas série...

dans ce cas, je comprendrai les choses selon ce principe : c'est ça ?

 

[biduleur34]

salut, non je voulait bien dire serie. pour avoir une fonction & logique.
apres peu etre que linuxcnc a une possibilité pour avoir deux entrés capteur afin d'avoir une vitesse lente pour le homing lorsque le switch est on. afin de detecté plus facilement le capteur opto.

mais bon apres je pense qu'une extrême précision dans le homing n'es pas nécessaire.

concernant la partie quadrature, c’était un exemple.
certain codeur ayant une sortie A et B en déphasage ont également une sortir I ou Z qui fait office de capteur opto. 1 impulsion par tour.
mais avec tes moteurs pas a pas tu n'as pas de codeur.

++
Léo

 

[RacingMat]

Mince j'ai inventé un truc alors ?!!

Le & logique c'est bien en parallèle
En série, un inter OU l'autre déclenche l'ouverture

Bon je n'en suis pas encore là... je reviendrai sur le sujet quand ma bécane bougera !!

 

[biduleur34]

Mince j'ai inventé un truc alors ?!!

Le & logique c'est bien en parallèle
En série, un inter OU l'autre déclenche l'ouverture

Bon je n'en suis pas encore là... je reviendrai sur le sujet quand ma bécane bougera !!

et non c'est l'inverse.

en série il faut que les deux contact soit passant, l'un ET l'autre.
en parallèle c'est l'un OU l'autre.

++
Léo

 

[RacingMat]

Ok tu raisonnais en NO et moi en NF !