Fréquence maximale d'un codeur incrémental

[mibo39]

Bonjour à tous,

J'ai un exercice que je dois faire avec la consigne suivante :



Je dois trouver la fréquence maximale du codeur (en t/min). Pour cela, on sait que l'API a un retard de 12 ms et que la piste est de 100 points par tour.

On sait que d'après Shannon, on a f > 2*fmax.
On doit donc trouver f.

Pour cela, on a f=1/t xN xR

Avec t = 60 + Retard
N = 100

On aura donc f=1/72 x100 xR
Mais le problème ici est que je ne sais pas comment trouver la résolution.

Merci d'avance pour vos réponses
-----

[jiherve]

bonjour
ton codeur produit des pulses à F = R*60*100 cette fréquence doit être <= 1/2*12^-3 => R <= 1/2*12^-3*60*100.
C'est pas bezef donc es tu sur des 12ms ensuite stricto sensu ce n'est amha pas un retard mais une periode d’échantillonnage.
ensuite pour exploiter un codeur il faut échantillonner les deux signaux a/b donc il y aura deux fois plus d’événements!
JR

[mibo39]

C'est ce que j'avais fais comme calcul auparavant et effectivement j'avais trouvé un résultat très faible (de l'ordre du centième). C'est pour cela que je préférais demander par peur de m'être trompé dans la formule ou bien autre part.
Mais d'après la question, il s'agit bien d'un retard de l'API. J'ai mis une photo de la question ci-dessous au cas où.

[jiherve]

bonsoir
un retard et Shannon cela n'a pas de lien, je peux très bien disposer d'un échantillonneur travaillant au MHz mais suivi d'un traitement demandant plusieurs ms, c'est le cas de nombreuses applications électroniques.
Donc énoncé débile, sans doute pondu par un ignorant du domaine!
JR

[A voir en vidéo sur Futura]

[jiherve]

ajout
j'explicite ma remarque :
supposons un dispositif composé de 12 bascules cascadées et séquencées à 1 kHz alors Shannon dit que la fréquence maximale du signal d'entrée doit être limitée à 500Hz et pourtant le retard de la sortie sera d'environ 12ms!
JR

[Pascal071]

bonsoir
si l'API met 12mS pour traiter un changement d'état

si 12mS par point:
1200 mS par tour
soit 50 tours / mn !

ce n'est plus un moteur mais un bouton codeur incrémental !
c'est d'ailleurs à peu près la vitesse max d'un bouton en traitant le rebond...

[Murayama]

Bonjour!

Donc énoncé débile, sans doute pondu par un ignorant du domaine!

J'en ai bien l'impression, oui. En plus, dessiner 2 pistes avec le même
nombre de traits n'a aucun sens vu qu'il suffit de décaler les récepteurs
A et B d'1/4 de période pour avoir des signaux en quadrature. Voir photo
d'un disque qui traînait sur mon bureau. Il est un peu crade, mais bon...
Il y a 720 surfaces réfléchissantes par tour. Donc tous les 1/2 degrés.
Les graduations du compte-fils sont de 1mm. On voit clairement qu'il n'y
a qu'une piste incrémentale et un trait de synchronisation.
Pour en revenir au problème, je ne sais pas ce qu'est une entrée TOR, et
dans le contexte, je ne sais pas ce qu'est un API. Pour moi, API = Application
Programming Interface, mais je ne vois pas trop ce que ça vient faire là.
Bref, l'énoncé est un peu confus.
Pour la résolution, si vous avez 100 rayures par tour sur le disque (en supposant
que c'est la signification de "100 points par tour"), alors la quadrature vous donnera
400 fronts par tour, ce qui fait que la résolution est 400. Ceci dit, avec 100
rayures par tour, on peut aller facilement à près d'1 million en résolution.


Pascal

[jiherve]

bonjour,
TOR = tout ou rien, logique simplement.
Il doit y avoir une coquille dans l’énoncé , si l'on suppose un échantillonnage de a/b à 12µs on obtient environ 3,5 T/m ce qui est déjà plus realiste.
JR

[antek]

Et API = automate programmable industriel

[Murayama]

Re!

TOR, API: merci pour les infos.
Oui, en fait, j'ai bien l'impression aussi que le délai ou la latence n'ont rien à voir.
Il est possible de traiter tout ce qui arrive en série et que la latence soit plus importante.
Sur les encodeurs que je conçois, on peut avoir par exemple une fréquence A/B de 10 MHz
mais avec une latence de 20µs, ce n'est pas gênant.
NB: les encodeurs actuels, c'est plutôt 1 à 5 µs de latence.

Pascal