codeur de broche

[pierrepmx]

Salut coredump,

la dernière fois que j'avais regardé, il y a quelques mois, les samples étaient payants (frais fixes), mais disponibles.

@ Moissan :

ce capteur donne un signal nul quand le champs magnetique est nul , et positif ou negatif suivant le sens du champs : il n'y a donc pas besoin de mettre 2 capteur en differentiel pour faire un point de commutation precis : [glow=red]le differentiel peut se faire par des circuit magnetique , et un seul capteur de ce type[/glow]

J'ai pas compris...


Petite dérive sur les fin de courses à effet hall, il y a peut-être un rapport avec ces circuits magnétiques différentiels :

il y a un ou deux ans, en réfléchissant aux fins de course, et en extrapolant à partir d'une app. note, j'avais pensé à un système avec un capteur bipolaire ("symétrique") et deux aimants de polarité inversés, placés côte à côte dans le sens du mouvement.
Ceci de façon à créer des transitions plus raides.
Des pièces polaires pourraient encore réduire la zone de transition.
Je n'ai sûrement rien inventé ...

Ça réduit aussi l'influence de la température sur les seuil de détection (sûrement faible, mais voir datasheet).
Certains modèles de capteurs ont un latch intégré ("mémoire"), suivant le type de circuit, ça peut être un plus.

Ceci dit, des tests sur CNCZone donnaient déjà une répétabilité jusqu'à +/- 0.02 à 0.01mm avec un SS441 et un simple aimant.
Répétabilité apparemment surtout limitée par celle du couple machine+moteur PAP.

http://www.cnczone.com/forums/open_source_cnc_machine_designs/101878-electronic_home_switches_made_easy.html

 

[pierrepmx]

gaston48> effectivement si tu fais une interpolation a partir du cos/sin ca peut etre fait sans erreur de vélocité.

Je ne suis pas sur que le signal soit très sinusoidal ni très symétrique.

S'il faut filtrer pour ressortir une belle sinusoïde, autant mettre une PLL

Juste une remarque: de toute façon, avec EMC2, il y a un soft derrière, avec un interpolateur/prédicteur de trajectoire : ça n'est ni plus ou moins qu'un filtrage, pas franchement linéaire.
Et finalement, si on y réfléchit, ça pas si éloigné que ça d'une PLL, dans l'esprit.

On n'est pas du tout dans le type de solution (hardware) électronique où les impulsions (autour de 400, voire plus) commandent directement un générateur de signaux pour moteur PAP à travers quelques compteurs...

J'ai plus d'une fois vu des photos de codeurs de 20 à 100 impulsions par tour sur la broche.

--> À mon avis, ce qui compte dans ce cas, c'est le suivi d’accélération, pas la résolution angulaire en elle-même.
Accélération dépendante de l'inertie de la broche / puissance moteur/ effort de coupe...
C'est ce suivi par rapport aux déviations potentiellement induites le long du pas de filetage qui donne le nombre de pulses minimum par tour (à rapporter aussi au "facettage" du aux moteurs PAP). Tout ceci est directement lié au pas de filetage : à mon avis, plus le pas est grand, plus d'influence est sensible.


Hélas, pour l'instant, je ne peux pas parler d'expérience sur les tours (j'ai seulement un petit portique 3 axes basique)... les vôtres m'intéressent donc particulièrement !

 

[moissan]

pour pouvoir interpoler plus fin que le pas de l'engrenage il n'y a pas besoin que ça soit exactement sinusoidal : il y a simplement besoin que ça soit des courbe arrondie pas trop biscornue

en fesant le calcul comme si c'etait des sinusoide ça donnera un resultat legerement faux , mais quand même toujours mieux que de ne pas avoir ces pas suplementaire

il y a aussi un moyen de faire un vrai pas plus fin : faire les pole du capteur avec des dent de même pas que l'engrenage ou la cremaillere

par exemple une cremaillere avec un pas de 0,1 aurait des dent trop fine pour un capteur simple : mais si le capteur a une piece magnetique de 5mm de large denté avec un pas de 0,1mm aussi , les dent passent toute a la fois en face ou a coté des dent de la cremaillere : donc un bonne variation de flux mesurable par le capteur a effet hall

c'est un principe utilisé par beaucoup de moteur pas a pas , pour faire des grand nombre de pas : moteur homopolaire

 

[coredump]

Il faudrait éplucher les mailings list linuxcnc, mais il me semble avoir lu qu'entre 16 et 64 pas c'était un bon compromis pour la broche, et que l'index est requis.

 

[pierrepmx]

en fesant le calcul comme si c'etait des sinusoide ça donnera un resultat legerement faux , mais quand même toujours mieux que de ne pas avoir ces pas suplementaire

Effectivement, ça doit rajouter des harmoniques, voire un "jitter" mais ça doit sûrement permettre un échantillonnage de la position/vitesse/accélération bien supérieur.

Je suis impatient de lire la suite !

Il faudrait éplucher les mailings list linuxcnc, mais il me semble avoir lu qu'entre 16 et 64 pas c'était un bon compromis pour la broche, et que l'index est requis.

Entre 16 et 64, ça correspond bien à certaines photos où le capteur est un disque d'alu percé de trous tout bêtes, avec deux capteurs opto à fourche à 90°(plus 1 trou et un capteur pour l'index).
Ceci dit, ça remet en selle l'idée d'un pignon de harnais, qui doit bien avoir une centaine de dents et qui aurait donc une résolution au moins comparable.

Par contre, pour un indexage angulaire, façon centre d'usinage, ou un suivi hyper fin comme dans la vidéo montrée par gaston48, il faut beaucoup de pas discrets, ou une interpolation comme ce dont parle moissan, ou un système à résolution infinie (codeur de type "resolver" RVDT) .

P.S. Se rappeler de l'équation fondamentale de la CNC amateur : Resolver=€€€€€€€€€

 

[Lnx2051]

il me semble avoir lu qu'entre 16 et 64 pas c'était un bon compromis pour la broche, et que l'index est requis.

t'est sur CoreDump , parce que c pas la peine que je parte alors sur un codeur à 1000 pas $$$$$$$$$

je v fouiller les mails LinuxCnc voir si je trouve kke chose la dessus

[Edit]
j'ai oublié que le décodage de la quadrature multipliait les pulsations par 4 ! ( donc 4000 pulses/tour pour un codeur de 1000 pas )
pas facile de trouver la limite d'EMC dans la documentation :(

Apparemment, la puissance du PC intervient dans la capacité à traiter le nombre d'impulsion arrivant du capteur : BASE_PERIOD
en prenant un facteur de sécurisée de 2, on aurait :
MAX RPM = 60 / (BasePeriod* Slots *8)


avec une résolution suffisante, on peut même s'amuser à faire ça :

cdlt
Ln

 

[coredump]

Oui pratiquement sur, faut chercher dans la mailing list. Attention c'est pour le filetage au tour ces chiffres, absolument pas pour de l'indexation.
La limite ca va surtout venir de ton electronique et de la vitesse maxi.

 

[gaston48]

Sur cet exemple d’asservissement avant / arrière, par Andy, un gros contributeur
d’emc2, il utilises une roue de 50 dents.

http://www.youtube.com/watch?feature=player_detailpage&v=ZhICrb0Tbn4

Beaucoup de commentaire sur cette manip, dans Linuxcnc.
Comme je le disais, si tu trouves d’occasion un codeur optique à la résolution
trop forte, tu peux toujours la diviser simplement, avant de rentrer dans emc2.
Mais c’est justement l’une des forces des FPGA, il me semble, le comptage
est sous traité par la carte mesa.