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

[Bernique]

merci pour le retour.
J'hésite effectivement à passer par un codeur du commerce, mais je ne sais pas trop quoi choisir et les prix ne risquent-ils pas de piquer un peu? C'est pourquoi j'étais parti avec mon codeur maison que j'ai déjà mis en œuvre sur un banc d'essai dynamique pour tester mes moteurs de Solex
je vais gratter un peu aussi... si qq'un à des suggestions abordables à proposer, il est le bienvenu... l'idée étant de rester dans l'esprit "TouchDRO à moins de 5€"

 

[Bernique]

pour étayer ma réponse précédente, voici ce que j'ai en tête en terme de capteur cheap:

• une platine intégrant un TCRT5000 et un trigger de Schmidt pour nettoyer le signal (qq piastres sur les sites du Far East),
• un disque imprimé au bon diamètre qui viendra se coller sur ma poulie en bout d'arbre de broche (voir photos ci-dessous).

Il restera à faire un petit montage avec l'imprimante 3D pour positionner le capteur à la bonne distance.

Le capteur:

Le disque gradué avec 24 positions par tour:

Le Crouzet et sa poulie supérieure (lors de son arrivée et avant remise en état )

 

[furynick]

Trop compliqué de faire avec un codeur du commerce.
Tu peux utiliser ton TCRT5000 mais fais un disque d'une 20aine ou 30aine de divisions.

 

[wika58]

AMHA il faut aussi rester raisonable et ne pas viser le RPM en résolution...

Sur ma P-C (perceuse-colonne) équipée d'un VdF et où je peux aussi faire du taraudage... quand j'ai fait l'affichage de la vitesse, je l'ai fait avec un afficheur standard.
A l'époque on trouvait plus facilement des fréquencemètre que des tachymètre (RPM) et j'ai fait un disque a 6 fentes et un codeur optique a fente (que l'on trouve dans tous les copieurs en CPS ou pour 3* rien sur A-E)...

Et j'ai un afficheur en dizaine de RPM...
Et c'est bien suffisant plutôt que d'avoir le dernier digit qui bagotte constamment...
c'est un peu comme le digit des micron sur les DRO qui bagotte sans qu'on ne puisse l'exploiter...

Enfin c'est AMHA...

Le capteur que tu montres avec un disque àvec secteur peints fonctionne aussi... il faut juste voir dans le temps avec la souillure du disque...
Mais il existe des capteurs par réflexion compactes qui intègrent tout (avec le trigger de Schmidt... ou au moins un etage Darlington) dans un petit boitier compact et etanche a la poussière...

Perso,.je préfère le detecteur à fourche que celui à reflexion...
Mais ca reste de l'optique et donc soumis à la poussière...
Et sinon tu as la solution de coller des petit aimants neodyne (2, 4, 6) et un petit détecteur magnetique (effet Hall).

 

[furynick]

Je préfères aussi la barrière optique avec un disque à fentes ou à ergots.
Le bagottage peut se gérer au niveau du code en moyennant un certain nombre de mesures ou plus simplement en arrondissant les valeur à 5 RPM par ex.

 

[Doctor_itchy]

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.

cela sur une pin , en codage AB tu a deux pulse donc tu divise ton calcul en 2

j'ai longuement tester du codeur sur du 328p , pour du servo dc "maison" ça va tres bien mais c'est pas rapide , enfin si tu prend les deux signaux AB tu peu tourné a 1500rpm avec un disque 200 "pulse" et tu est a la limite de la saturation du µC (entrée sur les timer ! )

si tu ne prend que un signal pulse et l'autre comme "sens" alors tu peu allez a 1500 rpm avec 800 pulse a la roue codeuse (mais tu divise la résolution lue par 4 donc kifkif )

cela demande aussi une mise au propre du signal codeur a l'entrée du 328p , sinon en fonction du signal ça perd des pulse

mais pour une dro linéaire sur une machine "manuelle" ça fera parfaitement le taf coté vitesse avec le328p pour un seul axe , meme 2 ou 3 , vu que tu ne les bouge pas en meme temps , mais pas assez d'entrée timer pour 2 axes !

c'est pour cela que le projet ici tourne sur un stm32 , plus d'entrée timer , plus de vitesse = pas de soucis (j'utilise le stm32 pour mon projet servo dc , roue codeuse a 2000 pulse tour , lue en 4x et moteur 3000rpm , j'ai pas encore pu saturé le µC )

 

[furynick]

J'ai jamais parlé d'encodeur, j'ai parlé d'une roue codeuse et d'un capteur optique, il n'y a bien qu'un seul signal donc une seule interruption.
Quand bien même, divisé un max de 1800 impulsions par tour par 4 (2 phases, 2 fronts) ça fait encore 450 impulsions par tour.

 

[wika58]

Je ne comprends vraiment pas pourquoi viser de tels nombre de pulses par tour...
Avec 2, 4 voir 6 ppr ca permet de filtrer électroniquement et d'avoir un signal propre en entrée du uC...

 

[furynick]

Ce n'est pas un objectif, c'est une estimation de la limite pour savoir quelles sont les possibilités plutôt que de choisir arbitrairement sans savoir si on est dans les clous ou pas ou si on a du mou.

2 ppr c'est clairement insuffisant, à 60 rpm ça fait seulement 2 impulsions par secondes donc tu afficheras 30rpm quand tu seras à 59.
A moins de calculer l'intervalle de temps entre deux impulsions mais j'évite ce procédé car il n'y a pas de moyen de savoir si ça tourne lentement ou si c'est à l'arrêt.

 

[Doctor_itchy]

oui a un seul pulse tour , bien entendu que ça ne satureras pas , je n'avais pas vu que c’était pour la broche

on peu allez tranquille sur 10 ou 20 pulse tour dans ce cas , le reste c'est du code pour avoir la bonne vitesse affichée mais un pulse tour suffit

 

[furynick]

1 ppr ça suffit si tu mesures le temps entre deux impulsions ... mais dans ce cas il faudra que ton code décide de la limite de temps à partir de laquelle il considère que le mouvement est inexistant.
Je trouve plus efficace d'échantillonner à intervalle régulier, le temps est une constante et s'il n'y a pas d'impulsions pendant ce laps de temps il n'y a mécaniquement pas de mouvement.

 

[Bernique]

ça discute ça discute ... j'ai profité de la pause de midi et de Inskcape pour me dessiner une roue de 130mm de diamètre à 48 interruptions, car j'ai fait des essais hier soir avec mon capteur sus-cité et des traits au marqueur noir sur une feuille blanche: à 1 ou 2mm de distance la discrimination est à priori correcte (relevé à l'oscillo de poche, pas avec l'ensemble du montage, capteur alimenté en 5Vdc). Ça devrait le faire avec ces 48 segments (il faudra vérifier pleine balle en rotation)
A suivre...

 

[wika58]

C'est toi qui voit...
Le futur nous dira...

 

[Doctor_itchy]

48 ? comme tu est en tour par minute il te faut plutôt des entier , la tu va "compliqué" le code pour rien

mais comme wika le dit , c'est toi quoi vois

 

[furynick]

Rien de compliqué dans le code.
Faudra juste renseigner 24 ou 48 selon le type de déclenchement de l'interruption (fall/rise ou change).

 

[Bernique]

oui, après on peut aussi se faire un multiple de 60, sauf que dans Inkscape c'est plus compliqué à faire simplement que les 7,5° nativement implantés dans la fonction rotation et qui permettent de construire le camenbert de base du cercle

 

[furynick]

Perso je me suis fait 15 dents sur ma roue codeuse.

 

[Bernique]

et tu as une lecture stable à plus ou moins 5 ?

 

[furynick]

Il faut que je modélise et que j'imprime le support d'étrier optique. Ensuite il faudra que je câble et que je code après avoir reçu l'afficheur 4 digit.

Pour la lecture stable rien de plus simple :

Vous devez être connecté pour voir ce contenu.

Dans le code du #231

 

[lebidule]

J'ai réussi à remonter les signaux de 1.65V à 3.3V. Ça marche plutôt bien. La qualité du signal n'est pas affectée, l'oscilloscope n'a eu aucun mal à faire un auto-set.
Plus qu'à travailler le firmware. Je vais garder si possible (je crois que ça l'est parce que ce sont toutes des pins configurables vers GPIO il me semble) la configuration des pins proposé par @Bernique

 

[Bernique]

Je vais garder si possible (je crois que ça l'est parce que ce sont toutes des pins configurables vers GPIO il me semble) la configuration des pins proposé par @Bernique

oui, elles sont toutes configurables (sauf à en utiliser certaines pour autres chose bien sûr!)... toutefois j'ai lu qu'il était préférable d'utiliser la pin PB15 avec les interruptions liées à Systick (pour la vitesse de broche)... mais je ne sais pas pourquoi.
Je vais changer mon code en conséquence, ça ne mange pas de pain!

 

[Bernique]

bon j'ai voulu charger mon soft modifié sur le Bluepill à partir de l'IDE Arduino 2.3.2.
J'arrive à compiler sans erreur, puis je tombe sur un os:

error while loading shared libraries: libusb-1.0.so.0: cannot open shared object file: No such file or directory

Pourtant, la librairie semble installée:

sudo sudo apt install libusb-1.0-0
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
libusb-1.0-0 est déjà la version la plus récente (2:1.0.25-1ubuntu2).

Une piste svp?

 

[furynick]

sudo apt install libusb-1.0-0-dev peut-être

 

[Bernique]

pas mieux... mais je n'ai plus le port disponible non plus dans l'IDE (avec ou sans le paquet dev)... pourtant je vois le ST-LINK V2 avec lsusb

 

[Bernique]

si ja passe en USB direct, je vois bien Leaflabs Maple serial interface et le port USB sous l'IDE Arduino, mais j'ai une erreur au téléchargement:

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: No DFU capable USB device available

Upload failed :(
Failed uploading: uploading error: exit status 1

 

[Bernique]

de même je vois le Bluepill via St-Link sur STM32CubeProgrammer
On verra ça demain...

 

[Doctor_itchy]

etrange , il manque une dépendance a la lib apparament , si les fichier son installer , et que ça marchais avant , peu etre une fausse manip ?

sous linux ta pas la chierie de maj auto qui zigouille une config spécifique ,donc a part une fausse manip ou install récente qui aurais changer un truc ?

tente aussi un sudo apt update voir si y a pas des chose qui vont se réinstaller puis sudo apt upgrade si y a des chose qui doivent se remetre

 

[Bernique]

merci... mais ça ne change rien après mise à jour.

je ne vois pas ce qui s'est passé hier soir qui me fasse perdre le port USB sous l'IDE Arduino avec le ST-Link connecté, c'est étrange.
Je note que mon module bluetooth HC-06 ne clignote plus non plus en branchant le montage (les leds du Bluepill elles clignotent comme attendu)... à se demander s'il n'y a pas qqch de briqué dans le bazar et qui me bloque le port usb sur le BluePill

En refaisant le film, ça a commencé à déconner après plusieurs tentatives de chargement via ST_Link / IDE Arduino en jouant avec le BOT0 et le Reset pour essayé de faire descendre le programme.
J'ai essayé de recharger le .bin de Pailpoe comme j'avais déjà réussi à le faire il y a deux ans via STM32Programmer: le connexion se fait, ça semble envoyer le programme, mais le module bluethooth ne clignote pas non plus. Je note que l'appairage avec la tablette n'est pas possible non plus, le montage demeurant invisible.

Vais voir comment je peux faire un reset du Bluepill qui me semble être à la source de quelque-uns de mes déboires (je ne parle pas de la lib manquante mais du reste).
Pour contourner mon soucis de lib, je pourrai toujours créer le .bin avec l'IDE Arduino et le faire descendre dans le Bluepill via STM32Programmer

 

[lebidule]

De mon côté c'est le package Arduino_STM32 qui pédale dans la semoule (je reste sur la version 1.8.x de l'ide), il ne trouve pas le compilateur. Tout est pourtant bien là où c'est censé ce trouver. Pour un truc simple, on finit toujours par se retrouver embêté par les à-côtés.

[edit] corrigé, faut pas hésiter à aller modifier les fichiers platform.txt dudit Arduino_STM32

 

[Doctor_itchy]

bha le stm32 sous arduino c'est une usine a gaz , pour le developpement oui sur l'ide et push rapide du code , mais pour la version "finale" il faut epuré le code et le poussé via stm32cube et viré le bootloader arduino !

si j'ai bien compris tu utilise l'ide arduino pour faire le code et le poussé sur le stm ?
si oui pour ton soucis c'est peu etre le bootloader "arduino" sur le stm qui a merdé , tente de le reflasher suivant les tuto ad'hoc puis de remettre ton code avec l'ide (oui c'est une usine a gaz ! )

cela dit entre parenthese j'ai déja eu un stm32 qui a subitement refusé de se laisser programmé , mais c'etait une "copie" chinoise il a fonctionné impec 10 fois puis .... mais les autre "copie" fonctionne tres bien meme apres + de 100 reflash divers !