DRO DRO sur base Arduino

  • Auteur de la discussion erolhc
  • Date de début
E
Guest
  • Auteur de la discussion
  • #1
Bonjour

Pour un projet n'ayant que peu de rapport avec la CNC j'ai besoin de récupérer les info d'une règle digital type PAC. Pour mes premiers essais et bien que que je vais en final utiliser une carte µP beaucoup plus puissante j'ai décidé d'utiliser une carte arduino sans utiliser la programmation assembleur : je reste donc dans l'environnement de travail IDE 1.04 de l'arduino et avec le bootloader classique.
Voici les premiers résultats à l'arrache :
La mission semble accomplie
La vidéo montre l'utilisation de la règle en mode "normal" (3 mesures par seconde) puis en mode "rapide" (env. 30 mesures par seconde) qui sera l'utilisation nécessaire pour mon projet.
Le nombre en binaire correspond à la mesure brute. Les dernier bits sont très fluctuant et sortent tels que du PAC. Heureusement qu'il s'agit d'une valeur en 1/20480 de pouce qu'il faut donc multiplier par 25.4/20480 pour avoir la mesure en mm.
La ligne "échec" représente le nombre d’échecs pour récupérer le signal sur le nombre de tentatives. Que ce soit en mode "normal" ou rapide " cela tourne aux alentour de 1% de rejets.

Pour le fun et bien que j'en ais aucune utilité, après nettoyage du code je vais faire un DRO 3axes sur base de carte mini pro dont je publiais le code afin que tout le monde puisse s'amuser avec et personnaliser (dont le choix de l'écran et la présentation).
Tel que, la place occupée sur la carte mega est de 5380 octets (sur 258 048)
 
Dernière édition par un modérateur:
toff
toff
Compagnon
1 Nov 2008
884
FR-60 Elincourt ste Marguerite
Ah c'est top !
N'étant pas fan de Pic, je m'était posé la question de recycler mon Arduino en DRO....
Je suis donc très intéressé par cette super mise en pratique :prayer:
 
D
du4
Apprenti
6 Mai 2012
81
38 Grasianapolis
Bravo ! c'est une bonne idée, courage pour la suite :lol:
 
JieMBe
JieMBe
Compagnon
17 Mai 2009
1 160
Maine et Loire
+1 je trouve cela extrêmement intéressant. J'avais eu l'idée d'en faire une aussi mais, c'est assez loin dans la liste des projet, d'abord terminer les projets en cours. Juste pour info est qu'il y beaucoup de composants entre le PAC et l'Arduino ?
Il serait aussi intéressant de standardiser les appels de la procédure qui lit les valeurs des du PAC pour pouvoir adapter rapidement le code au différents protocoles de PAC utilisés.

JMB
 
E
Guest
  • Auteur de la discussion
  • #5
Bonjour
Il y a exactement le même nombre de composants qu'avec les solutions à base de pic :
- LM393/LM358 + condo+résistances pour les lignes Data/Clock,
- pont de resistances ou LM317 + résistances ou CI spécial 1.5V+condo pour l'alim 1.5V,
- CD4066 ou assimilé pour la simulation bouton RAZ et mise en mode "rapide" (dans la video j'ai un BS170 pour le RAZ et un simple bouton pour le mode rapide en direct sur la ligne "Data"),
etc ... bref tout ce qui est obligatoire à cause du "1.5V" des PAC
Les seuls "moins" qui peuvent y avoir c'est l'environnement microprosseur (quartz etc ...) puisque intégré sur la carte arduino
L'avantage de l'arduino c'est que pour peu que l'utilisateur ait quelques notion de programmation c'est facilement modifiable pour faire l'interface d'affichage alors que les solutions PIC s'est figé à moins d'avoir un programmateur etc .. sans compter que les sources dispo pour les pics sont soit pas disponibles soit sont en assembleur ...ce qui limite un peu :wink:
Pour les autres protocoles de PAC je laisse ça à d'autres , déjà que l'arduino ne va pas me servir dans mon projet (tout au moins comme prévu) mais était une mise en bouche pour voir si je peux utiliser un PAC dans mon projet avant d'avoir le µprocesseur définitif
 
F
flo12
Nouveau
22 Jan 2012
42
Bonjour à vous :-D ,

Etant très intéresse par le système, je me demandais si on ne pourrait pas utiliser un encodeur rotatif à la place de la règle pour avoir une buté numérique pour pas trop cher (c'est pour un scie a ruban, je pense que la précision n'a pas besoin de dépasser le millimètre :lol: )

Bonne soirée à vous
 
LETARTARE
LETARTARE
Ouvrier
27 Sept 2010
442
Haute-Savoie
bonjour,
réalisation très intéressante et une vidéo très probante.
Pourriez-vous nous indiquer comment se procurer le cordon de liaison pour récupérer les informations sur le DRO ?
Bien cordialement
 
E
Guest
  • Auteur de la discussion
  • #8
Bonjour

Le cordon sur la vidéo avait été acheté chez RC-machines mais :
- c'est très cher pour ce que c'est
- ce n'est pas fiable sur une machine, déjà que c'est limite sur un bord de table, car ça a tendance à se détacher ou tout au moins à avoir de mauvais contacts

@flo12 : oui on peut sans soucis remplacer la regle par un encodeur rotatif mais ce n'est plus le même programme
 
E
Guest
  • Auteur de la discussion
  • #9
Bon j'ai un peu travaillé ces jours ci et j'ai un peu optimisé le code mais ... je n'ai qu'environ 97.4% de bonnes valeurs . Le reste est soit je loupe la mesure (env. 1%), ce qui n'est pas grave puisque je le sais, soit j'ai une mauvaise valeur (1.6%) et là c'est plus problématique. Certaines mauvaises valeurs sont très simple à filtrer d'autres plus délicates car cohérentes.

Pour un DRO ça n'a pas une grande incidence : juste que pendant une fraction de seconde (en gros 1/3) la valeur affichée est fausse :) par contre c'est gênant pour mon projet

Le signal envoyé par les règles semble correct à l'oscilloscope (hormis les bits de poids faibles qui dansent la java mais cela n'a aucune conséquence notable sur la valeur en mm) donc il y a quelque chose dans mon code qui n'est pas fiable (ou le code généré par le compilateur :???: )

J'ai laissé tomber le fait de passer en mode rapide car sur 3 règles en ma possession, achetées à des moments différents, toutes ne réagissent pas de la même façon aux commandes "mode rapide" (une se met en "mode maxi" : la valeur change qui si la nouvelle valeur est supérieure à l'ancienne) alors que rien ne les distingue extérieurement

La vidéo ci dessous montre un arduino mini pro (16MHz) avec 2 règles et un comparateur au 1/1000. Ce dernier est sur le même protocole que les règles mais la fréquence de mesure normale (je n'ai pas cherché le "mode rapide") est d'environ 10 mesures/s soit 3 fois plus rapide que les règles. Les principales différences résident dans l’intervalle entre les deux mots de 24 bits qui est un peu plus court que les règles et la fréquence de l'horloge plus rapide. De plus les derniers bits (poids faible) sont beaucoup plus stables que ceux des règles.

L’intérêt de l'arduino mini pro c'est que l'on peut faire un DRO 3 axes plus mesure de vitesse de broche (LM 2917) sur quelques cm² et à cout très modeste

 
Dernière édition par un modérateur:
lion10
lion10
Compagnon
7 Mai 2010
4 725
bonjour

Décidément les ventes d'aficheurs de dro pour les amateurs vont baisser!

Le protocole pour dialoguer avec vos règles, le comparateur ou un pied à coulisse à 10 euros lidl est il le même ?

Quand vous parlez d'échec c'est une erreur de réception du genre mauvais checksum ?

Le mode rapide ou lent est à l'initiative de votre carte qui interroge plus ou moins fréquemment le pac afin qu'il délivre sa mesure ?

cdlt lion10
 
E
Guest
  • Auteur de la discussion
  • #11
La différence entre mon comparateur et les règle est expliqué ci dessus. Pour les PAC lidl je n'en sais rien ...Les 2 pac en ma possession sont sur le même protocole que les règles mais ils ne viennent pas de chez lidl.

Les règle ont plusieurs mode d'envois ( et d'affichage aussi d'ailleurs) des données : mode "hold" mode "normal", mode "rapide", etc . La différence entre normal et rapide est que les séries d' impulsions (que j’appelle mesures) sont soit sur une fréquence d'environ 3 fois/s ou bien de 40 fois/s.

Ce que j’appelle échec c'est que je ne parvient pas à chopper la série d'impulsion car je n'attend pas assez longtemps (pour laisser leur chance aux autres règles) pour garder une fréquence de rafraichissement de l'affichage assez rapide.

Voici une série d'impulsions sur mes règles : 2 groupes de 24 bits, le premiers groupe étant une valeur absolue arbitraire choisie par le PAC a la mise sous tension et le deuxième groupe correspond à la valeur affichée (et donc relative) sur le PAC.
channel(0) correspond à l'horlode et channel(1) (en vert) aux valeurs
Dso3.jpg
 
B
beetle bug 64
Apprenti
30 Juil 2009
217
64
Bonjour, je découvre l'univers Arduino et ne connaissant pas grand choses en electronique et surtout en programmation je suis étonné par ce que peuvent faire les amateurs (éclairé) à la maison. J'ai donc parcouru en entier le super site : http://www.siteduzero.com/sciences/tutoriels/arduino-pour-bien-commencer-en-electronique-et-en-programmation pour mieux comprendre ce monde qui me fascine.
Ma question est donc, pourrait-on avoir un aperçu du cœur du programme pour pouvoir mesurer la complexité de celui-ci? Comment nomme -t-on l'entrée (input) sur la carte? Vous l'avez branché sur la sortie PWM? Est-ce le CI qui permet de séparer la lecture des 3 axes ou suis-je à côté de la plaque :oops:
Je suis désolé de poser des questions aussi basique sur votre post et si vous avez un lien qui me permettrais d'apprendre plus précisement Arduino je vous remercie d'avance.
 
Dernière édition par un modérateur:
lion10
lion10
Compagnon
7 Mai 2010
4 725
bonsoir

ok c'est plus clair. Le chronogramme provient d'un analyseur logique inclu dans le debuuger arduino ?

C'est pas mal.

cdlt lion10
 
amurianum
amurianum
Compagnon
21 Jan 2013
956
lion10 a dit:
Le chronogramme provient d'un analyseur logique inclu dans le debuuger arduino ?
non il s'agit d'un autre programme, peut être un petit analyseur logique comme on en trouve aujourd'hui sur ebay

chlore, tu dis que le channel 1 correspond aux valeurs, mais lesquelles :wink:
 
E
Guest
  • Auteur de la discussion
  • #15
Bonjour

Le chronogramme provient de l'analyseur logique 16 voies 66MHz intégré à mon oscilloscope.
Pour le canal 1 je ne vois pas trop ce qu'il faut rajouter à ce qui a été écrit plus haut à part peut être qu'il faut multiplier par 25.4 et diviser par 20480 la valeur (dernier groupe correspondant au déplacement du PAC après remise à zéro donc valeur relative) pour avoir la mesure en 1/100mm pour les règles ou *25.4/204800 pour avoir la valeur au 1/1000mm pour le comparateur.

Je publierais le code quand j'estimerais que je suis arrivé à fiabiliser le bidule ou bien que j'en aurais marre et qu'en fait je continuerais sur le µP qui correspond à mon projet
Le code pour la lecture d'une règle (donc hormis le code pour l'affichage etc ...) fait une 30 lignes incluant les déclarations de variables spécifiques à cette lecture.
Pour apprendre l'arduino il suffit de taper arduino dans google (ou autre) pour trouver de quoi apprendre et en français qui plus est.
Oui le montage tel que représenté sur la dernière vidéo permet la lecture de 3 axes (regles) et est malheureusement nécessaire pour remettre les signaux en 1.5V issus des règles à un niveau (+5V) compréhensible par l'arduino.

L'utilisation une arduino mini pro (équivalent chinois à moins de 5€) + afficheur comme le mien (grande taille = double d'un "normal") + quelques composant revient à moins de 30€ hors circuit imprimé, ou à moins de 20 € avec un afficheur 4*20 "normal" (plus petit) ou bien à moins de 10 € si on se contente d'envoyer les mesures sur un PC.
L'avantage de la solution arduino sur les les solutions à PIC (ou autres) c'est que le code sera libre et donc laissera la possibilité à l'utilisateur de modifier facilement le programme pour correspondre à ses besoins spécifiques surtout en terme d'affichage (sur afficheur LCD, écran tactile, PC, ...)
 
M
metalux
Compagnon
11 Jan 2009
5 348
nord
je (on ) attend la suite avec impatience :P
 
E
Guest
  • Auteur de la discussion
  • #17
Ouaip ben là je cherche à comprendre comment il se fait qu'avec le même programme aujourd'hui j'ai un taux de bonnes valeur de 99.1% et moins de 0.01% de loupé (28 loupés sur 385000 mesures) ... alors que le signal est même moins "propre" : deux beau bug électronique envoyé par la règle :hum:
9-47.jpg
 
Charly 57
Charly 57
Compagnon
21 Déc 2008
5 266
FR-57330 Moselle
chlore a dit:
Ouaip ben là je cherche à comprendre comment il se fait qu'avec le même programme aujourd'hui j'ai un taux de bonnes valeur de 99.1% et moins de 0.01% de loupé (28 loupés sur 385000 mesures) ... alors que le signal est même moins "propre"
Bonjour

Sans rien comprendre à la programmation, se peut il que tes difficultés viennent des circuits d’adaptation (couplage / découplage HF ? ) suivant ce que tu as dit ?
"le montage tel que représenté sur la dernière vidéo permet la lecture de 3 axes (regles) et est malheureusement nécessaire pour remettre les signaux en 1.5V issus des règles à un niveau (+5V) compréhensible par l'arduino."

C'est peut être une autre piste: A la vitesse de sortie des créneaux, vu le cablage en fils volant, l’absence de blindage, l'humidité du jour peut influer en HF. As tu filtré toutes tes alims avec de petits condensateurs céramique de l'ordre de 100 pf ?
 
E
Guest
  • Auteur de la discussion
  • #19
Il n'y aucun condensateur, zero, que dale, nothing, nada .... et les signaux sont quand même très propres tel que l'oscillogramme ci dessus. Les bug montrés sont visibles même avec les sondes d'oscillo en direct sur le PAC : c'est un bug électronique connu sur ce matériel mais ne vient en rien entacher les mesures : ces bugs sont toujours sur la ligne Data et jusqu'à présent je ne les ai vu que quand le signal d'horloge est au niveau bas.

On est loin de la HF : la fréquence max (signal d'horloge) tourne à 80kHz environ

Je pense que j'ai trouvé d’où vient une partie des problèmes ... à voir après enregistrement d'environ 100000 valeurs
 
E
Guest
  • Auteur de la discussion
  • #20
Ca va dans le bon sens : sur 105 000 relevés j'en suis maintenant à 99.76% de bonnes valeurs (à+/-0.01mm près) le reste étant composé de valeurs complétement aberrantes facilement éliminables par filtrage mais je vais voir s'il s'agit de mon code ou si c'est "normal"
Je vais faire un test en bloquant la valeur (mode "hold")
 
P
pierrepmx
Compagnon
24 Sept 2010
3 617
Alpes & Drôme
Salut Cl,

les oscillogrames sont-ils pris en sortie de règle ou après les comparateurs ? (je dirais après les comparateurs, vu les fronts bien raides...)

Comme on échantillonne sur les fronts d'horloge, les "glitches" de l'oscillogramme ne sont pas vus. Donc - dans ce cas - sans influence.
Par contre, ceux qui tomberaient sur le front d'horloge foutraient la pagaille, c'est sur.

Visiblement, le signal d'horloge n'a pas de problème.
La ligne "data" est bidirectionnelle (par court-circuit), donc circuit de sortie différent de celui de l'horloge. Plus vulnérable ?

On vit dans un environnement électromagnétique de plus en plus pollué.
Donc, si les erreurs augmentent quand ton téléphone sonne ou que le voisin utilise la télécommande radio de son portail...
 
E
Guest
  • Auteur de la discussion
  • #22
Bonsoir

Cela a été pris après les comparateurs et même au bout du câble à l'entrée de l'arduino.
Je ne pense pas que les glitches soient liés à des parasites mais plutôt à l'algo de conversion analogique-digital : ils sont toujours à la même place pour des valeurs bien définies et toujours entre deux bit haut ou bas consécutifs comme si le µP se disait "à mer... le suivant est aussi à l'état haut (ou bas)" après être descendu ou remonté alors que normalement quand deux bit consécutifs sont au même état il n'y pas de changement d’état entre deux cycles d'horloge.
J"ai trouvé une valeur ou il y a 5 glitches !

435 000 mesures et même taux de réussite que précédemment ! 99.74 %. Je lance pour la nuit le mode "hold" au lieu d'avoir une dizaine de valeurs (24bits) qui couvrent le +/-0.01 mm je ne devrais trouver qu'une seule valeur (il n'y a pas de bit qui danse la samba dans ce mode là)
 
P
pierrepmx
Compagnon
24 Sept 2010
3 617
Alpes & Drôme
OK, donc les glitches sont un pb de conception du chip (je n'aurais pas été fier de sortir un truc pareil !!), mais sans influence sur la mesure.
 
N
nexty
Ouvrier
28 Jan 2011
330
Silenrieux (Belgique)
interressant;

en plus d'avoir le code en licence libre, l'emcombrement est minimal!!

vite la suite qu'on puisse commander la meme chose et metre ca en place (je suis null en electronique)
 
coredump
coredump
Compagnon
8 Jan 2007
4 489
FR-06
Tu as opendro comme DRO en opensource: http://sourceforge.net/projects/opendro/
C'est basé sur le hardware shumatec
Mais ca tourne sur du ARM et utilise des afficheurs 7 segments (et un tas de boutons).
 
Dernière édition par un modérateur:
E
Guest
  • Auteur de la discussion
  • #26
Bonjour

@nexty : l'utilisation une arduino mini n'apporte pas un grand gain de place par rapport à d'autres solutions : il lui faut comme les autres des composants électroniques périphériques donc aussi un circuit imprimé.
L"avantage de l'arduino c'est la souplesse que cela apporte à l'utilisateur pour faire son propre DRO selon ses besoins pour peu que celui-ci connaisse un peu la programmation, celle de l'arduino n’étant vraiment pas compliqué.
De plus pas besoin d'un programmateur puisque que celui -ci est intégré à la carte : on branche sur le port USB (il faut quand même un câble de conversion série/USB) et c'est tout.

Bon après modif du code et sur plus 1 050 000 mesures j'ai un taux de "bon résultat" de 100% et un taux de loupé de 0.7%
Sur un autre règle j'ai quelques valeurs (5/ 100 000) qui ne sont pas bonnes à 2/10 eme près avec un même taux de loupés. Par contre en "bloquant" la valeur (mode "hold") aucun problème, il semble donc que les quelques erreurs soient dues à la danse des "bit" donc au PAC plutôt qu'au code.

Je laisse donc là les essais sur l'arduino. Je remet tout en forme pour un DRO basique avec 3 boutons de RAZ, documente un peu le code, crée un schéma basique aussi sous eagle et je le publie. Aux autres de compléter
 
F
francois13
Nouveau
25 Mai 2013
11
bonjour , suis tres interesse par votre montage de DRO pour regles "chinoises" ,l electronique est pour moi un domaine assez obscure et je voulais savoir si vous aviez déjà publier un schema de votre montage et / ou un circuit imprime qui me serais facile de suivre , j ai un tour avec 2 regles de chez RC machine mais les afficheur deviennent de plus en plus difficile a lire (huile de coupe ) et moyennement accessible a la lecture d ou la centralisation de lecture serait un reel plus et je pourrais enfin proteger ces regles efficacement . je sais lire un schema et realiser un montage "" bêtement "" en suivant les infos ....merci d avance si vous avez qlq chose de concret a me proposer
 
E
Guest
  • Auteur de la discussion
  • #28
Bonjour

Comme promis voici le programme pour faire un DRO 3 axes sommaire : à savoir l'affichage des valeurs X,Y,Z envoyées par les règles et la remise à zéro ; c'est tout. Si vous voulez d'autres fonctions c'est à vous de les faire et donc d'adapter le programme et éventuellement le schéma électronique.

Les règles travaille en mode "normal", c'est à dire en envoyant les valeurs environ 3 fois par seconde. L'utilisation du mode "rapide" (40 envois /seconde) est à mon avis superflu pour un DRO. Le seul avantage que je vois c'est que l'on peut réaliser une moyenne glissante des valeurs et donc - peut-être - stabiliser l'incessant clignotement du dernier digit (+/- 1/100).
Pour le mode "rapide" il faut appliquer pendant 100ms (env) 1.5V sur la sortie "Data" de la règle (on passe alors en mode "hold" puis 1.5V aussi 100 ms sur la sortie "clock" .
Cela peut-être réalisé avec 74HC4051 ou un CD4066 (interrupteur analogique) mais occupe 3 sorties sur l'arduino.

En raison de la lenteur de la lecture/écriture sur les sorties de l'arduino lié à l'IDE, le programme fourni lit en accès direct sur les ports I/O. L’avantage c'est que c'est très rapide, l’inconvénient c'est que le code n'est pas applicable sur toute la famille arduino sans modification des valeurs de pin. De même il faut pour chaque règle une routine spécifique qui ne diffère que par les valeurs de pin. Il est certainement possible de faire une librairie mais le jeu n'en vaut pas la chandelle à mon avis.

Comme le timing de lecture du signal des règles est crucial il déconseillé d'utiliser les interruption logicielle ou matérielle dans le programme comme par exemple lire (et affichée) une vitesse de broche par exemple : pour cela il sera préférable d'utiliser un convertisseur fréquence/tension (tel le LM2917) et d'utiliser un broche de mesure analogique de l'arduino.

Le programme fourni fonctionne tel que sur arduino min/mini pro. Il peut fonctionner (et a fonctionné) )sur Mega2560 en changeant les pin d'entrée dans le programme ou en choisissant les entrées sur la carte (on se servira du pin mapping de la carte pour cela). Du moment que le processeur "tourne" à 16MHz, ça roule. Plus ou moins et cela oblige à revoir les "timing".

Je joins au programme, le schéma électrique à titre indicatif. Les amp-op LM393 indiqués sur le schéma sont la version "D" c'est à dire en SOIC, La version normale en boitier DIP utilise le même brochage. De même le régulateur de tension 1,5V indiqué est une version CMS . La façon d'obtenir la tension de 1.5V importe peu du moment qu'on l'ait. Tout mon schéma est en CMS (y compris les résistances et les condensateurs) car j'avais commencé à placer quelques composants pour mon application avant de penser à joindre un schéma pour le programme. Il n'y a donc pas d'image du circuit imprimé correspondant

Ce qui est fourni l'est "tel que", Je laisse à d'autres le soin d'améliorer le cas échéant le programme, de faire un circuit imprimé correspondant et de les rendre public.

Je n'assure pas le SAV et surtout pas par MP qui seront effacés systématiquement. S'il y a des questions, j'y répondrai sur le forum ou laisserais à d'autre le soin de le faire.
Voir la pièce jointe ArduiDRO.zip
 
toff
toff
Compagnon
1 Nov 2008
884
FR-60 Elincourt ste Marguerite
Encore merci pour le travail et le partage :smt023
 
danastro
danastro
Compagnon
8 Jan 2008
1 616
Belgique pas loin de Givet 08 (F)
Bonsoir,

Super boulot et un grand bravo et merci pour ton généreux partage

Ça va me redonner gout a l’électronique ce genre de montage :-D
 
Haut