DRO Interface pas chère pour TouchDro de Yuri à moins de 5€

[moufy55]

Pourquoi que pour les horlogers ?
Sectaire ! Les usineurs sont plus nombreux, et plus forts, ils vous feront la peau !

 

[jon]

Hihi je pense que mon produit étant donné la miniaturisation des capteurs et des règles est plutôt orienté pour être intégré dans de petites machines (tour 6-8mm) et petits schaublins style 70 , Petites fraiseuses type aciera f1 ou sixis 101 pointeuses type Hauser M1, pour du plus gros les personnes peuvent s’équiper de règles en verres a pas cher et je ne sais pas si mon système serait alors intéressant pour eux. Après je peux me tromper ?
Amicalement

 

[moufy55]

C’est un peu là où, j’voulais en venir.
Tes capteurs fonctionnent avec une interface afficheur classique asiatique au même titre que des règles verre fonctionnent sur ton boîtier ?

Pour les fonctions ajoutées, si tu en créé d’autres, assure la mise à jour, ça peut être intéressant sur une fraiseuse conventionnelle pour upgrader un ancien afficheur basique.

Je raisonne sans m’intéresser au coté CN de tes moteurs pas à pas qui est un truc de feignant

 

[jon]

Exact les capteurs qui sont tout de même haut de gamme fonctionnent avec une visue classique (c’est aussi volontaire de ma part ) à la différence ce sont les fonctions que j’ai développées en plus plutôt axées horlogerie qui font la différence. Exemple avec la partie des moteurs pas à pas la possibilité de refaire des filetages bourgeaux / delamure, latard, thury, rien que ça c’est une perle pour les restaurateurs car trouver une filière ou un taraud c’est très vite compliqué et cher. Pour ce qui est de la maintenant et mise à jour je pars du principe: un utilisateur, une idée, intégration et diffusion de la mise à jour à la communauté d’abonnés et ce de façon gratuite
Amicalement

 

[jon]

Et voici la bête installée sur mon p’tit tour
Amicalement

 

[ppt]

le reve pour mes petites machines
mais je crains que mon budget soit trop juste

 

[alogic]

bonjour, désolé pour la traduction. je voulais remercier pailpoe
thanx!!

hp printer encoder

 

[sebosse]

bonjour . je dispose de ce type de règle que javais acheté sur aliexpress pour mon petit tour chinois , a la différence quelles sont brancher en direct ( pas d’USB ).
je me suis procuré un st-link v2 + smt32F103C8T6 + hc-06.
est-ce possible avec ce matos ou faut il que je me procure du matos autre ?

ps : jai deja flasher le smt32 et testé la liaison Bluetooth avec touch dro ( OK ) .

​

 

[wika58]

Aah ça ca m'interesse car j'ai les meme regles sur ma fraiseuse...

 

[speedjf37]

Bonjour,

je me suis procuré un st-link v2 + smt32F103C8T6 + hc-06.

le spécialiste STM32 c'est @pailpoe

JF

 

[Bernique]

Hello,
et merci aux balaises qui m'ont permis de monter mon boitier moi aussi (pailpoe et Doctor_itchy pour ne citer qu'eux)
Je sèche juste sur un point: sur le github @pailpoe il est mentionné le codage de la vitesse de broche, mais je ne retrouve pas celà sur le schéma ni dans le code. J'ai regardé pour m'y coller, mais là ça dépasse gravement mes maîgres compétences.

Quelqu'un a-t-il réalisé ce câblage/codage de la vitesse de broche et pourrait le partager svp?

Merci et bonnes fêtes de fin d'année (moi j'ai commandé des règles au papa Noël chinois )

 

[lebidule]

bonjour . je dispose de ce type de règle que javais acheté sur aliexpress pour mon petit tour chinois , a la différence quelles sont brancher en direct ( pas d’USB ).
je me suis procuré un st-link v2 + smt32F103C8T6 + hc-06.
est-ce possible avec ce matos ou faut il que je me procure du matos autre ?

ps : jai deja flasher le smt32 et testé la liaison Bluetooth avec touch dro ( OK ) .

Bonjour,
Je serais intéressé aussi de savoir si quelqu'un a réussi à faire fonctionner ce type de DRO.

J'essaie de mon côté et - étant pas vraiment porté sur l’électronique - c'est pas encore ça. Le soucis c'est vraiment les signaux de retour en 1.6V. Du coup, si j'ai bien compris, faut un "level shifter" (type txs0108e) pour les repasser en 3.3V, mais aussi un régulateur "step down" (type L-M 2596) de 3.3V vers 1.6V pour avoir le voltage de référence des signaux pour le level sifter. (J'utilise des modules tout fait acheté sur ali)

Notez que les fils n'ont à voir avec les modules présentés en première pages. J'ai l'impression que ça dépend des modèles/vendeurs. Un beau bazar. Là c'est:
GND (fil noir): Clock (1.6V)
D+ (fil vert): DATA (1.6V)
D- (fil blanc): +3.3V
VBUS (fil rouge): GND

J'obtiens bien la même sortie sur oscilloscope, ça m'a bien aidé d'ailleurs la première page de ce post, merci à @pailpoe

 

[wika58]

Bien ce petit Up...

J'ai installé de ces règles sur ma BF et je voudrais avoir une DRO centralisée...
Mais rien depuis 2022...

 

[Bernique]

Je sèche juste sur un point: sur le github @pailpoe il est mentionné le codage de la vitesse de broche, mais je ne retrouve pas celà sur le schéma ni dans le code. J'ai regardé pour m'y coller, mais là ça dépasse gravement mes maîgres compétences.

Quelqu'un a-t-il réalisé ce câblage/codage de la vitesse de broche et pourrait le partager svp?

ouaip, car j'en suis toujours au même point

 

[furynick]

pour la prise de mesure il y a plusieurs moyens : capteur à effet hall avec un aimant collé (bof), roue codeuse et surement plein d'autres.
le pb c'est que le code va dépendre du matériel installé.

 

[Bernique]

oui, c'est sûr.
Mon idée de base était de confectionner un encodeur quadratique à base de deux capteurs à réflexion de type TCRT5000 (émetteur infrarouge couplé à un phototransistor) disposés proche de la broche tournante. J'avais jeté mon dévolu sur une platine intégrant un traitement du signal qui permet d'avoir un signal propre, exactement celle-ci: https://makerselectronics.com/product/line-tracker-module-3-channels
Elle possède un capteur de trop, mais ce n'est pas grave du tout!
Logiquement, je dois pouvoir en sortir deux signaux carrés propres (enfin j'espère!) en 0-3,3v ou 0-5v selon l'alimentation.
La logique de l'encodeur quadratique m'allait bien, c'est sa mise en œuvre dans la travail de Yuri qui me pose problème!

 

[furynick]

Tu as des bibliothèques toutes faites qui gèrent les encodeurs.
L'idéal étant de connecter les phases A et B sur des pins qui gèrent les interruptions.

Attention toutefois à la fréquence max que le µC pourra assurer.

 

[JieMBe]

Dans ce sketch il y a bien une section de gestion du tachymètre, c'est pour un Arduino. Je n'ai pas trop creusé, mais pour l'heure, je n'y comprends rien.

JMB

 

[JieMBe]

Ici aussi, il y a une gestion du tachymètre, c'est encore plus compliqué, je n'y comprends rien non plus, et pour le coup ça ne marche pas, ça renvoie NAWAK. Ça passe de t-19247 à t-28479 puis t12896.....

JMB

// ESP32_Touch_Tacho.h

#ifndef _ESP32_TOUCH_TACHO_h
#define _ESP32_TOUCH_TACHO_h

#if defined(ARDUINO) && ARDUINO >= 100
#include "Arduino.h"
#else
#include "WProgram.h"
#endif

#ifndef _ESP32TACHO_h
#define _ESP32TACHO_h
#endif
//#define MAX_ENCODERS 4
#include "ESP32_Quad_Encoder.h"
//enum pullupType { none, up, down };
class ESP32Tacho {
private:
unsigned long maxPulseInterval;
//int nopulseCount;
gpio_num_t tachoPinA;
enum pullupType puType;
void(setupPin(gpio_num_t pin));

public:
ESP32Tacho(int pinA, int pinB, float pulsePerRev, pullupType uip);
ESP32Tacho();
void attachTacho();
float get_ppm();
float pulsesPerRev;
float pulsesPerMinute;
volatile unsigned long timeOfLastPulse;
volatile unsigned long aggregateMicros;
unsigned long pulseInterval;
volatile int pulseCount;
bool running;
bool directionEnabled;
int direction;
gpio_num_t tachoPinB;
};

void IRAM_ATTR tacho_isr();




#endif

// ESP32_Touch_Tacho.cpp

/* Routines to add Tacho capability to TouchDRO Interface
Mates with ESP32Encoder as adapted by romeo
Prepared June 2020
*/


#include "ESP32_Touch_Tacho.h"

const int minRPM = 20; //RPM below which tacho will decide shaft is stopped

extern ESP32Tacho Tacho;

portMUX_TYPE TachoMux = portMUX_INITIALIZER_UNLOCKED; //despite vs squiggly line, compiles ok
const int32_t microsPerMinute = 60000000;

ESP32Tacho::ESP32Tacho() {
pulsesPerRev = 0;
}
ESP32Tacho::ESP32Tacho(int aP, int bP, float ppr, pullupType uip) {
tachoPinA = (gpio_num_t)aP;
tachoPinB = (gpio_num_t)bP;
pulsesPerRev = ppr;
puType = uip;
pulsesPerMinute = 0;
maxPulseInterval = microsPerMinute / (minRPM * pulsesPerRev);
directionEnabled = false;
}

void ESP32Tacho::attachTacho() {
setupPin(tachoPinA);
if (tachoPinB != 0 && tachoPinB != tachoPinA) {
setupPin(tachoPinB);
directionEnabled = true;
running = false;
}
attachInterrupt(tachoPinA, tacho_isr, RISING);
}
void ESP32Tacho::setupPin(gpio_num_t a) {
gpio_pad_select_gpio(a);
gpio_set_direction(a, GPIO_MODE_INPUT);
if (puType == down) {
gpio_pulldown_en(a);
}
else {
if (puType == up) {
gpio_pullup_en(a);
}
}
}

void IRAM_ATTR tacho_isr() {
unsigned long isr_micros = micros();
if (!Tacho.running) {
portENTER_CRITICAL_ISR(&TachoMux);
Tacho.running = true;
Tacho.pulseCount = 0;
Tacho.direction = digitalRead(Tacho.tachoPinB);
Tacho.timeOfLastPulse = isr_micros;
Tacho.aggregateMicros = 0;
portEXIT_CRITICAL_ISR(&TachoMux);
}
else {
portENTER_CRITICAL_ISR(&TachoMux);
Tacho.pulseCount++;
Tacho.aggregateMicros += (isr_micros - Tacho.timeOfLastPulse);
Tacho.direction = digitalRead(Tacho.tachoPinB);
Tacho.timeOfLastPulse = isr_micros;
portEXIT_CRITICAL_ISR(&TachoMux);
}
}

float ESP32Tacho::get_ppm() {
int temp_pulseCount;
unsigned long temp_aggregateMicros;
unsigned long temp_timeOfLastPulse;

if (!Tacho.running) {
return 0;
}
portENTER_CRITICAL(&TachoMux);
temp_pulseCount = pulseCount;
pulseCount = 0;
temp_aggregateMicros = aggregateMicros;
aggregateMicros = 0;
temp_timeOfLastPulse = timeOfLastPulse;
portEXIT_CRITICAL(&TachoMux);

if (temp_pulseCount == 0) { //if no actual pulses received, display an apparent slowdown in accordance with the report interval
pulseInterval = micros() - temp_timeOfLastPulse;
if (pulseInterval > maxPulseInterval) {
running = false;
direction = 0;
return 0;
}
temp_pulseCount = 1;
}
else {
pulseInterval = temp_aggregateMicros / temp_pulseCount;
}
return (microsPerMinute / pulseInterval);
}

Et enfin la partie du code relatif au tachymètre dans le programme principal

if (++tachoReportCounter >= tachoReportInterval) {
tachoReportCounter = 0;
if (Tacho.direction == 0) {
outputString += ("t" + String((int)Tacho.get_ppm()) + ";");
}
else {
outputString += ("t-" + String((int)Tacho.get_ppm()) + ";");
}
}

 

[Bernique]

je n'y pige rien non plus à cette syntaxe

 

[furynick]

C'est de la programmation objet mais beaucoup trop lourd pour l'objectif à mon sens.
Là on est pas sur de l'encodeur (2 phases décalées) mais sur de l'impulsion donc sur le principe de la roue codeuse.

A mon avis c'est le plus simple à mettre en œuvre et le plus simple à coder.
Il te faut brancher le signal du capteur sur une pin capable de déclencher une interruption.
Dans cette interruption tu incrémentes un compteur.

En parallèle il faut créer un timer de 250 ou 500ms par exemple, ce timer calcule la vitesse en divisant la valeur du compteur par le nombre de dents de la roue codeuse et du temps. Sans oublier de réinitialiser le compteur.

Il suffit ensuite d'afficher la valeur quelque part (port série, LCD, écran, etc).

Ça donnerait quelque chose comme ça (cf. https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/ pour les interruptions)

Vous devez être connecté pour voir ce contenu.

 

[Bernique]

merci, c'est effectivement l'idée que j'en avais quant au principe du code... il faut que je replonge dedans, mais je souhaitais à l'époque compléter le code de Yuri/Pailpoe pour bénéficier de toute le travail déjà disponible car j'ai une vielle tablette disponible et j'ai aussi déjà réalisé mon boitier d'acquisition avec le matériel préconisé en début de post ici-même

 

[Bernique]

Re,

je viens d'aller jeter un œil furtif sur le github de pailpoe... vais voir si j'arrive à y insérer l'idée du code que tu proposes, mais il faut commencer par épluché la datasheet du STM32F103C8T6 que je ne connais pas du tout

Bon ce week-end c'est plutôt placo, alors je vais éviter de céder à la tentation tout de suite sinon c'est mort

 

[wika58]

Il est super ton boitier.
Comment as-tu fait la face avant ?

 

[Bernique]

Merci.
C'est une impression 3D en PET gris et PETG bleu, puis une plaque de PMMA gravée laser rapportée et collée pour la vitre

 

[Bernique]

je viens d'aller jeter un œil furtif sur le github de pailpoe... vais voir si j'arrive à y insérer l'idée du code que tu proposes, mais il faut commencer par épluché la datasheet du STM32F103C8T6 que je ne connais pas du tout

Bon ce week-end c'est plutôt placo, alors je vais éviter de céder à la tentation tout de suite sinon c'est mort

j'ai fait une pause dans le placo

Dans le github de Pailpoe, il est mentionné ceci:

The frame format is :
Xaaa;Ybbb;Zccc;Wddd;Teee;

aaa : Step for X sensor ( example : -2563 or 4569)
bbb : Step for Y sensor ( example : -2563 or 4569)
ccc : Step for Z sensor ( example : -2563 or 4569)
ddd : Step for W sensor ( example : -2563 or 4569)
eee : spindle speed in RPM ( example : -800 or 2569)

... génial, on y trouve eee qui est ce que je veux aussi visualiser... sauf que dans le code, eee n'est pas implémenté!
J'ai dans l'idée qu'il faut récupérer le timer de W par exemple (pas sûr qu'il y en ait d'autres disponibles, pas encore RTFM du bluepill ), mais les fonctions intégrées dans le code sont des monstres sortis d'une bibliothèque et à partir de là je coince!

Vais continuer plus tard

 

[Bernique]

De retour avec mon besoin d’adapter le hard/soft de Pailpoe + application TouchDRO à un tour conventionnel (un Crouzet en l’occurrence) afin d’avoir la lecture de la positions des axes ET de la vitesse de broche dans l’application TouchDRO de Yuriy.

Après quelques réflexions nocturnes, je pense avoir identifié deux façons de procéder. Rien ne dit que les deux idées sont viables, ça reste de la théorie, mais j’explore et j’espère aboutir .
Ce sera laborieux car je pars pratiquement de zéro en termes de connaissances quant à la programmation du Bluepill, cœur de la solution. De plus certains acquis risquent de voler en éclat en se frottant à la pratique (comme le format présupposé de la vitesse de broche à envoyer à l’application)… Bref, vos apports et votre indulgence seront les bienvenus

__________________​

Dénomination des axes :
Avant toute chose et pour essayer d’être à la fois compréhensible et portable sur toute architecture de tour, j’utilise le formalisme suivant pour nommer les axes. En m’inspirant des normes AFNOR NF Z 60-020 & NF Z 68-020 qui désignent les axes en tournage MOCN, j’ai choisi (et c’est critiquable bien entendu !) :

• Longitudinal : Z
• Transversal : X
• Porte outils : W
• Contre-pointe : R
• Broche : C’

(Réf : http://robert.cireddu.free.fr/Ressources/Prod/Cours sur le referentiel MOCN/index.htm)


Les forces en présence :
Le hard + soft de Pailpoe qui permettent en l’état de transmettre les valeurs de 4 règles linéaires en quadrature vers l’application ToucheDRO (envoi de steps = quantité de distances élémentaires parcourue).
La transmission de la vitesse de rotation de la broche n’est pas implémentée (documentée seulement, à priori directement en RPM).

L’appli TouchDRO peut recevoir cette vitesse de broche en plus des 4 axes linéaires. De plus, elle permet de choisir le format d’axe sur l’afficheur : linéaire ou rotation.

__________________​

Solution 1 : dite l’Elégante !
Avantages : permet d’avoir 4 axes de déplacement linéaires + vitesse rotation broche
Inconvénients : assez complexe et incertaine, devrait me tenir éveillé quelques nuits !

Principe :
Pratiquement, le programme actuel propose d’équiper 4 axes avec des règles en quadrature de phase. Dans le soft, ils sont nommés par défaut X, Y, Z et W.
L’idée ici est de ne pas y toucher, tout juste les identifier pour ce qu’ils sont, à savoir :

• L’axe X côté programme sera connecté à la règle posée en X sur le tour (transversal)
• L’axe Y côté programme sera connecté à la règle posée en R sur la contrepointe
• L’axe Z côté programme sera connecté à la règle posée en Z sur le tour (longitudinal)
• L’axe W côté programme sera connecté à la règle posée en W sur le tour (porte outil)

Pour récupérer la vitesse de broche, il va nous falloir :

• Un timer disponible sur le µ-processeur (Bluepill) pour faire une base de temps. Les 4 timers habituels sont déjà phagocytés par les 4 axes instrumentés… on va essayer d’utiliser un autre timer interne disponible sur le Bluepill et nommé SysTick (8Mhz, ultra précis) ;
• Un capteur d’impulsion simple (pas quadratique) qui va compter les tours (1 ou plusieurs impulsions par tour, on verra après calculs !). Le TCRT5000 (émetteur infrarouge couplé à un phototransistor) fera l’affaire, mais il faut aussi trouver une broche supplémentaire et disponible gérant les interruptions sur le Bluepill (point non vérifié au moment où j’écris)!

On trouve des capteurs intégrés avec traitement du signal par trigger de Schmidt inclus sur ce type de platine, comme par exemple ici (et aussi ailleurs, je n’ai pas de rétro-commission chez ce vendeur !) : https://opencircuit.fr/produit/tcrt5000-infrarood-lijn-detectie-module .

Avec ces deux oiseaux, on peut alors aisément faire un calcul simple du nombre d’impulsions reçues par unité de temps… ce qui nous donnera des RPM par règle de trois. Bingo, enfin j’espère, puisqu’il suffira de compléter la trame d’envoi du soft de Pailpoe pour y intégrer cette valeur à destination de l’appli TouchDRO

__________________​

Solution 2 : dite Dernier Recours !
Avantages : ne nécessite pas de broche d’interruption supplémentaire sur le Bluepill, a des chances d’aboutir, devrait suffire dans bien des cas (3 axes linéaires + rotation broche)
Inconvénients : ne permet pas d’instrumenter les 5 axes (il va falloir choisir de sacrifier la poupée ou le chariot port outil!)

Principe :
L’idée principale est d’utiliser le programme sans grosse modification en sacrifiant un axe linéaire au profit de la vitesse de broche.
Chacun fera son choix, mais j’ai décidé de panacher mes axes ainsi pour l'exercice :

• L’axe X côté programme sera connecté à la règle posée en X sur le tour (transversal)
• L’axe Y côté programme sera connecté au capteur de rotation sur C’ sur le tour (broche)
• L’axe Z côté programme sera connecté à la règle posée en Z sur le tour (longitudinal)
• L’axe W côté programme sera connecté à la règle posée en W sur le tour (porte outil)
• La contre-pointe ne sera pas instrumentée.

Pour récupérer la vitesse de broche, on va cette fois-ci :

• Utiliser le timer de l’axe Y pour faire la base de temps ;
• Utiliser un capteur de rotation identique à celui de la solution 1, câblé sur une des broches avec interruption désormais disponible du timer lui aussi libéré.

La suite est identique à celle de la solution 1.

__________________​

Voilà, j'espère ne pas vous avoir assommer... en retour je prends toute suggestion d'amélioration / refonte de ces élucubrations nocturnes!

 

[Bertitou]

Bonjour,
Très intéressant post que je viens de découvrir par mes recherches pour résoudre la mise en œuvre d'une règle linéaire chinoise sur une visue ANILAM Wizard 211.
La visue ne "voit" pas le raccordement (broche standard 9 pins) de cette règle(Vevor).
Serait-ce une mauvaise distribution des fils soudés aux pins?
Si oui, L'un de vous a-t-il une idée comment la modifier

 

[Bernique]

De retour avec mon besoin d’adapter le hard/soft de Pailpoe + application TouchDRO à un tour conventionnel (un Crouzet en l’occurrence) afin d’avoir la lecture de la positions des axes ET de la vitesse de broche dans l’application TouchDRO de Yuriy.

Après quelques réflexions nocturnes, je pense avoir identifié deux façons de procéder. Rien ne dit que les deux idées sont viables, ça reste de la théorie, mais j’explore et j’espère aboutir .

Bonsoir,

j'avais posté une première version de ce message que j'ai effacé puis repris ci-dessous... car après l'avoir validé, j'ai réalisé que j'avais écris des choses inutiles en me mélangeant les pinceaux. C'est la magie de coucher sur les octets ses pensés!

Bref, j'ai jeté quelques réflexions autour de la solution 1 pour le code ainsi que quelques chiffres de dimensionnement.

Côté code, j'ai pas mal avancé et je vais essayer de continuer. En résumé, à partir du signal cadencé à 1000Hz (1ms) du débordement de l'horloge Systick, je pense avoir trouvé comment déclencher des actions autour de la collecte du nombre de tours effectués par la broche. J’ai pu aussi vérifier qu’il reste des entrées sur la carte Bluepill pour faire l'interruption hardware souhaitée à partir du capteur pour générer ce nombre de tours. Plutôt cool.

Côté dimensionnement, pour résumer, si on veut avoir une valeur de rotation de la broche autre que zéro, il faut s'assurer qu'on aura au moins un passage devant le capteur de broche à la plus petite vitesse de rotation du tour durant chaque intervalle de scrutation. On a théoriquement plusieurs leviers pour cela :

• Jouer sur le temps de scrutation, i.e. on collecte le nombre de signaux sur un intervalle de temps plus ou moins grand ;
• Jouer sur le nombre de signaux par tour de broche, i.e. un capteur unique peut basculer plusieurs fois par tour et/ou on peut avoir plusieurs capteurs qui incrémentent le même compteur!

Point de départ : mon Crouzet fonctionne sur une plage 80-2660 RPM.

A 80 RPM, pour avoir au moins un passage devant un capteur générant une seule impulsion par tour (par exemple sur un front montant du signal), il faut un temps de scrutation d’au moins 750ms. Avec ce même temps, à 2660 RPM, on recevra un peu plus de 33 impulsions par tour.
Autrement dit, il ne faut pas espérer avoir un rafraichissement de l’affichage en dessous de 1,3Hz dans ces conditions, mais est-ce bien grave puisque cette vitesse de rotation de la broche n’est qu’indicative sur le DRO et ne sert pas à générer une quelconque trajectoire en temps réel !
On peut toutefois affiner un peu. En codant la détections des impulsions de broche sur les fronts montant et descendant du capteur (i.e. s’il est monté, il va bien falloir qu’il redescende avant le tour suivant !), on double déjà l’information… et on peut espérer un rafraichissement toutes les 0,375s.
Mais rien ne nous empêche d’avoir 4 impulsions du codeur de rotation par tour de broche et de descendre encore le rafraichissement… c’est encore aisé à mettre en œuvre (disque coupé en 4 secteurs alternés noir/blanc et qui passent devant notre capteur TCRT5000).

J’ai pour le moment pris une autre option : le rafraichissement à 1Hz me suffit amplement (on verra à l’usage), et un codeur délivrant 8 signaux par tour semble faisable sans gros soucis à prévoir. Avec ces données, je peux espérer avoir 10,67 impulsions par scrutation, gage de plus de stabilité dans la mesure (une variation de 1 impulsion me fera osciller entre 75 et 83 RPM, ce qui me semble acceptable vu l’usage encore une fois). A 2660 RPM, j’aurai alors 354,67 impulsions par scrutation (une variation de 1 impulsion me fera osciller entre 2655 et 2663 RPM).
Il me reste à vérifier que le capteur est capable de basculer dans la fenêtre de temps donnée à pleine vitesse.

A suivre...

Je joints mon Calc de calcul pour ceux que ça intéresse...

 

[furynick]

un 328p est cadencé à 16MHz, en considérant qu'il faut 200 cycles (au pif complet) pour gérer l'interruption et incrémenter le compteur le µC peut gérer jusqu'à 80kHz d'impulsions. A 2660 tr/mn on a un peu plus de 44 tours par seconde donc tu peux théoriquement monter à 1800 impulsions par tour.
Le timing d'envoi des infos est asynchrone (cf. ma proposition de code ci-dessus) c'est décorrélé du comptage et n'a pas d'incidence dessus.

Perso je te conseille de partir sur un disque/roue codeuse à 20 voire 32 dents. Tu seras très loin de saturer ton µC et tu auras une bien meilleure stabilité/précision.