dsDRO

[romteb]

Je regardais les derniers devellopements du projet avec des yeux embués par l'admiration lorsque j'eu un choc

Usinages.fr est le site d'Isathor

Ici c'est usinages.com


Ouais je sais j'aurais du prendre le .fr aussi

 

[wika58]

J'en ai parlé avec mon ami le W-E dernier et lui ai fait un mini cahier des charges avec la façon dont ce serait bien de voir les infos à l'écran et avec ta specif. de la Comm.

Il ne devrait pas y avoir de problème...

Et l'on pourra faire pas mal de fonctions supplémentaires.

Pour le moment, il a quelques soucis avec sa voiture alors ...
mais ça devrait aller vite après...

 

[wika58]

...
Ici c'est usinages.com
Ouais je sais j'aurais du prendre le .fr aussi ...

Mais c'est bien mieux " .com"
ça fait plus international...
regarde le nombre de Belges que nous sommes...et il y a même un ami Suisse...

 

[Fred8]

Oh, je suis nul Absolument désolé Pas fais d'exprès...meuhhhhhhouinnnnnnn

Eh ben oui, je me plante encore souvent entre les deux.
Bon, pas difficile à corriger, mais çà va rajouter un caractère et déséquilibrer la ligne.

 

[sambogosse]

Salut,

affiche le nom du soft et la version en dessous plutot, ca devrait tenir

A+

 

[MaX-MoD]

Je regardais les derniers devellopements du projet avec des yeux embués par l'admiration lorsque j'eu un choc

Usinages.fr est le site d'Isathor

Ici c'est usinages.com


Ouais je sais j'aurais du prendre le .fr aussi

c'est toi qui danse avec la tondeuse?


Sinon ce soir je devrais bosser un peu dessus et fournir un code stable.
Parce que pour l'instant ça compile nickel, mais y'a plus rien sur le terminal série...
quel petit rigolo ce C30

 

[Fred8]

T'as pas des soucis de stabilité avec MPLab 8?
Chez moi, et avec le compilo CCS, il plante et replante.

Pour le militaire gay qui danse derrière la tondeuse, c'est bien lui, je vois que tu l'avais reconnu aussi !

 

[MaX-MoD]

pas de soucis de stabilité ac MPLAB 8 (8.01b pour moi)
avec C30 du moins...

pour CCS, c'est bizarre. y'a pas une update de CSS par hazard?
mais c'est un crash ou simplement ça veut plus compiler?
si ça veut plus compiler, ça peut être du au fait que MPLAB (depuis la V8) ajoute automatiquement (il parait) le linker associé à ton PIC.
ça avait posé de pb d'ailleurs pour certains PIC dont le linker était pas bon (raison d'un "device update" quelques temps après la sortie de la V8)

Ah, oui, petite blague de la part de MICROCHIP: le Visual Device Initializer était sensé être (enfin) fonctionnel dans cette version


Mais sinon c'est bien que romteb assume

(on te taquines, hein )

 

[Fred8]

Non, c'est pas un pb de linker. Des crashes purs et simples, le logiciel se ferme lors de certaines compilations. Je vais voir pour mettre Mplab à jour, parceque CCS, je peux pas, c'est une version d'essai.
Bon, çà m'empêche pas de programmer non plus.

Edit : bon, piqué au vif par mes compatriotes, j'ai décidé d'agir, vite :

 

[Fred8]

De quoi tester les messages sur le LCD sans s'embêter à flasher le PIC :

truc de geek
il manque plus qu'une police "5x7" et l'immersion est totale^^

Max

J'ai pas trouvé la police dans Excel ! J'en avais une plus ressemblante, mais elle ne supportait pas les chiffres colorés en blanc (encore un truc bizarre tient...). Si t'en as une meilleure, suis preneur !
En tout cas, geek, peut-être, mais bien pratique...

 

[MaX-MoD]

Bon, ça avance.
La gestion des menus a encore qqs bug mais rien de tragique.
La mise en forme des données reste à tester.
La partie capture des données n'est pas encore commencée, et je me demandes comment je vais faire ss oscillo, car les PAC c'est un peu la lotterie apparemment: 2*24 ou 7BCD...

Et pour le routeur, voila une ébauche du schéma.

PS: le signal DATA4 est en commun, avec le port série, c'est une erreur.

Il n'ya pas de restrictions quant à la polarité des signaux, et on est pas obligé de respecter les No des entrées: on pourra mettre le signal DATA du 3e PAC à l'entrée du premier, au plus facile à router.

Broche est le signal tachy.
le rapport de cycle n'a pas vraiment d'importance.

voila.

A+
Max

Voir la pièce jointe dsDRO.zip

 

[MaX-MoD]

Pour les plus aveugles d'entre nous ( ), j'ai trouvé un truc assez intéressant: http://www.baghli.com/dspic_vga.php


A+
Max

 

[Otatiaro]

Salut,

Je viens de lire un peu le projet, c'est marrant.

Quelle précision on peut avoir avec un PAC ?

A ton avis, ca serait viable de s'en servir comme entrée d'un PID pour faire une régulation boucle fermée ?

++

 

[wika58]

Le pour et le contre des PAC utilisés en régles, on peut en discuter des pages entières...
Cela dépend de ce que tu veux, ...si toutes tes réalisations sont au 1/100° alors il te faut des règles pro et y mettre le prix...
Pour moi, le 1/10° me suffit dans 99,99% des cas

Et de toute façon comment usines-tu pour le moment?
Avec quoi prends-tu tes mesures???...
Le tout est une question de rapport entre prix et besoin...

J'ai mis des PAC sur ma X2 et ça le fait...
Un petit DRO la-dessus pour ne plus avoir à se pencher pour lire les valeurs sur les afficheurs des PAC et ce sera le top.

Bon,... pour la CNC et le travail en boucle fermée avec de grandes vitesses de déplacement, ça c'est différent...

 

[Yann]

Otatiaro, Max_Mod a déjà répondu à ta question un peu plus haut dans le fil.

 

[Otatiaro]

Otatiaro, Max_Mod a déjà répondu à ta question un peu plus haut dans le fil.

Salut,

Vu ... enfin c'est a peine effleuré

Pour la précision, on dit donc dans les 1/10e pour un PAC pas cher, et du 1/100e pour une règle a plein de $$$$.

Et pour le temps de réponse ?

On peut avoir combien de "sample per second" a la sortie d'un pac numérique (un positionnement complet) ?

Parce que si on espere y mettre 40KHz en entrée (Mach3 par exemple) et qu'on ne connait la position du PAC que 1000 fois pas seconde, c'est pas gagné ...

++

 

[coredump]

Attention, ca ne veut rien dire "on est précis au 1/10eme".
Les PACs chinois ont une bonne précision, largement en dessous du 1/10, reste a voir la répétabilité et l'uniformité de cette mesure.
Mais une fois encore, c'est une erreur de croire qu'une regle en verre est forcement plus precise, peut etre mais pas proportionnellement au prix.
L'interet d'une regle en verre n'est pas la: c'est plus robuste (liquide), rapide et standard.

 

[bebert2611]

Les spécifications indiquées pour les PAC chinois n'ont pas l'air si pourries : 0.01 en répétabilité, 0.02 en précision (0.03 sur 150mm).

Donc si les déplacements ne sont pas trop grands, on doit pouvoir espérer 0.02, voire 0.01 en rusant siouxxe sur les déplacements.

Et puis pourquoi pas mettre 2 ou 3 PAC en //, et exploiter judicieusement les mesures fournies ?

Si quelqu'un a plusieurs PAC (même marque), ce serait intéressant de faire l'expérience : que donnent 2 ou 3 PACs montés de telle sorte qu'ils mesurent simultanément la même grandeur ?

Pour ce qui est de la fréquence des mesures, on peut obtenir 50Hz, je crois.

Donc, en adaptant les vitesses de déplacements avec les précisions attendues, je ne vois pas ce qui pourrait interdire un asservissement.

 

[coredump]

Le fait qu'il n'est pas possible d'avoir des mesures 50 fois par seconde qui soient fiables tout simplement, et du délai entre la prise de mesure et la reception/décodage par le PC.
Les regles en verre sont en quadrature, ce qui permet un delai tres court.

 

[bebert2611]

Désolé, je ne compends pas.

Un PAC peut fonctionner en émettant 50 fois par secondes.

On peut parfaitement interpoler les mesures sur N mesures précedentes, et obtenir un polynôme de degrès N-1.
On peut aussi, au besoin, extrapoler sur un ou 2 pas de temps à venir, sans trop de souci si N assez grand (et un polynôme de degrès 4 ou 5 doit déjà donner une courbe super précise).

Un PIC fonctionne à 20 ou 40 Mhz, un PC fonctionne à 2 ou 3 Ghz, et les connections se font à 400 fois 50Hz.

Sans parler de monter 2 ou 3 PACs en //, et de moyenner sur les valeurs reçues...
Voire : obtenir un signal en quadrature, puisque vous semblez les affectionner, avec 1 seul PAC, dont le signal est déphasé du temps qui vous semble le mieux

Donc, je ne comprends pas.

 

[MaX-MoD]

La précision électronique des PAC est inférieure au micron, mais ils ne sont utilisés qu'à 0.01 car il y de grandes fluctuations (parasites, tempo du circuit peu fiable...)
mettre 2 PAC en // ne veut pas dire qu'on multiplie la précision par 2...
on resserre les valeurs en sortie autour de la valeur réelle, mais l'imprécision reste la même (moyenne sur 2 variables aléatoires indépendantes)
C'est un peu comme le micropas sur les pap

Pour faire du système bouclé, les PAC peuvent être utilisés, mais seulement pour des vitesses faibles et avec un algo plus évolué que le classique PID... qui va voir des pics énormes de la sortie D.
Pour de la CN, c'est plus que limite, à moins de ne faire que des lignes droites à faible vitesse, ou pour corriger une erreur sur le pas de la visse, mais même la trapézoïdale la moins chère a une meilleure précision que 0.01mm/150mm...

Même si les PAC sont peu chers il sera plus rentable et plus efficace de prendre de bonnes visses avec un bon encodeur rotatif dessus.

Enfin, les PAC fonctionnent par résonance électro-magnétique apparemment, je pense qu'il y ait pas un délais de stabilisation
ou même un retard assez important dans la puce elle-même.

au final on va avoir 60 échantillons/s mais peut-être un retard de 4 ou 5 échantillons, surtout si on va traiter le signal pour sortir un signal quadra dont la fréquence est "lissée". Je n'en sais rien, je ne connais pas plus ces PAC, mais c'est plus qu'une simple intuition.

Pour éviter une oscillation il faut alors un algorithme d'asservissement plus évolué, capable de reconnaître une oscillation et de la couper.
C'est pas la même quantité de boulot qu'un simple PID lol!

Perso je dirais que l'utilisation de PAC pour l'asservissement amène plus de problèmes qu'autre chose...
Par contre pour un affichage sur une machine manuelle (ce qui est l'unique but de dsDRO d'ailleurs), pas de problèmes évidemment


EDIT: au fait, qq1 a commencé le routage?

 

[bebert2611]

mettre 2 PAC en // ne veut pas dire qu'on multiplie la précision par 2...
on resserre les valeurs en sortie autour de la valeur réelle, mais l'imprécision reste la même (moyenne sur 2 variables aléatoires indépendantes)

Elles sont quand même un peu corrélées, les 2 valeurs, non ?
Ou alors j'économise en achetant 2 dés, plutôt que 2 PACs...

Pour éviter une oscillation il faut alors un algorithme d'asservissement plus évolué, capable de reconnaître une oscillation et de la couper.

Une interpolation polynomiale, de degrès 2, ou 3, sur les 10 dernières valeurs, par exemple, voilà un lissage qui devrait commencer à donner des trucs exploitables.
Mais ce n'est qu'une simple intuition. C'est vrai aussi qu'il y a plus de boulot pour traiter cet asservissement.
Interpoler une cubique sur 10 valeurs, c'est manipuler une matrice 10x4, avec 300 ou 400 instructions (au pif).

Une simple droite, à la place de la cubique, c'est la droite des moindres carrés, qui doit aussi commencer à donner des trucs ....

 

[coredump]

Un aservissement n'est pas qu'un lissage. Le standard c'est la regulation PID (proportionnelle integrale dérivée). J'avoue que mes cours d'automatique discrete sont trop loin pour que je me rapelle l'effet d'un délai dans la boucle de retour

 

[bebert2611]

Un aservissement n'est pas qu'un lissage. Le standard c'est la regulation PID (proportionnelle integrale dérivée).

Je n'ai jamais écrit cela.
Mais si les données ont le hoquet, il faut leur taper dans le dos avant de les utiliser pour asservir via un PID ou autre chose.

 

[MaX-MoD]

Elles sont quand même un peu corrélées, les 2 valeurs, non ?
Ou alors j'économise en achetant 2 dés, plutôt que 2 PACs...

Ben justement si elles sont corrélées les valeurs, y'a plus de chance que l'erreur des deux PAC soit la même... on aurait beau moyenner, ça reviendrais exactement au même

Une interpolation polynomiale, de degrès 2, ou 3, sur les 10 dernières valeurs, par exemple, voilà un lissage qui devrait commencer à donner des trucs exploitables.
Mais ce n'est qu'une simple intuition. C'est vrai aussi qu'il y a plus de boulot pour traiter cet asservissement.
Interpoler une cubique sur 10 valeurs, c'est manipuler une matrice 10x4, avec 300 ou 400 instructions (au pif).

Une simple droite, à la place de la cubique, c'est la droite des moindres carrés, qui doit aussi commencer à donner des trucs ....

Là ça sort de mon domaine de compétences (pas vraiment pris le temps de me pencher sur le traitement numérique du signal, bien que ça m'intéresse pas mal)
Mais si tu te sens de faire des tests pour utiliser des PAC pour asservire une CN, tu auras une bonne base pour commencer, et en C en plus!

Un aservissement n'est pas qu'un lissage. Le standard c'est la regulation PID (proportionnelle integrale dérivée). J'avoue que mes cours d'automatique discrete sont trop loin pour que je me rapelle l'effet d'un délai dans la boucle de retour

Tout à fait, mais il faut aussi pouvoir exploiter les informations qu'on a.
EDIT:Je préfère comment bebert l'a dit
Un délai sur la boucle de retour peut au moins entrainer une oscillation autour de la position désirée.
Gommer des détails aussi certainement...

 

[bebert2611]

Ben justement si elles sont corrélées les valeurs, y'a plus de chance que l'erreur des deux PAC soit la même... on aurait beau moyenner, ça reviendrais exactement au même

un PAC qui a une précision de 0.01 donne :
- soit la bonne mesure
- soit une erreur de -0.01
- soit une erreur de +0.01

Il y a donc une chance sur 3 pour que la mesure soit exacte, et 2/3 pour qu'il y ait 0.01 d'erreur.

Avec une précision de 0.02, il y a 5 cas possibles, tous équi-probables.

Désolé, mais 2 PAC mesurant la même grandeur permettent d'améliorer la précision.
Preuve :
il y a 0.4 chance que l'erreur soit de 0.02 sur l'un des PAC.

il y a :
0.2 chance pour avoir la même mesure sur l'autre PAC
0.2 chance pour avoir 0.01 d'erreur
0.2 chance pour avoir 0.00 d'erreur
0.2 chance pour avoir -0.01 d'erreur
0.2 chance pour avoir -0.02 d'erreur

Amélioration moyenne :
0.2x0+.2x.01+.2x.02+.2x.03+.2x.04=.016

ceci 4 fois sur 10, soit 0.006/2 d'amélioration, si on utilise la moyenne des 2 PAC

On a aussi 96% de chance de détériorer une mesure exacte.

Détérioration moyenne
0.2x.02+0.2x0.02+0.2x0.01+0.2x0.01=.012

ceci 2 fois sur 10 (un PAC donne la mesure exacte), soit 0.002/2 de dégradation moyenne.

Si un des 2 PAC a une erreur de 0.01, l'autre PAC a :
0.2 chance d'avoir la même valeur
0.2 chance d'avoir une mauvaise mesure de 0.02 dans le même sens
0.2 chance d'avoir une mesure exacte
0.2 chance d'avoir une mesure à 0.01 dans l'autre sens
0.2 chance d'avoir une mesure à 0.02 dans l'autre sens.

Soit un bilan moyen :

-0.2x.01+0.2x0+.2x.01+.2x.02+.2x.3 = 0.01 d'amélioration, ceci 4 fois sur 10 (1 PAC a une erreur de 0.01)

Le bilan total est donc loin d'être nul, on a même une amélioration de 0.003-0.001+.002=0.004.

On ne n'améliore pas la précision d'un facteur 2 avec 2 PAC, mais on s'en rapproche. Encore plus avec 3 PAC.

Comme quoi ....

Voilà pourquoi les grenouilles des météorologues mesurent 3 fois la température, pour savoir sur quel échelon se percher, pourquoi les vaches comptent 3 fois les trains, les bergers 3 fois les moutons, etc, etc...

 

[Fred8]

D'accord avec Bebert2611, c'est le principe de toute vérification d'appareil (mis à part le degré de précision lié au niveau de l'étalon utilisé) : si on a un doute sur un, on en met plusieurs en //, et on réduit l'erreur globale.

Pour ce qui est de l'optimisation du code, une interpolation sera gourmande. Je fais le plus souvent des moyennes glissantes sur un nombre pair de valeurs et si possible multiple de 8. Par exemple, une valeur affichée à un instant t est la moyenne des 8 valeurs précédentes relevées. La moyenne glisse donc à chaque t, avec 8t de retard, ce qui est négligeable à 50Hz.
Le soft (je le faisais en asm) était très optimisé et la fiabilité de la mesure bonne.
Le dsPIC n'est pas non plus une bête de traitement du signal, et il sera assez chargé avec les encodeurs, le formattage des données, la liaison série vers le PC et l'écran, l'éventuel clavier, et autre si affinité. Autant lui laisser un peu de marge.

 

[wika58]

Toutes les démonstrations sont exactes.
J'ai fait de la régulation de process pendant plus de 15 ans...
Pour des régulations de câges sur des laminoirs, du positionnement de ponts roulants dans le nucléaire, ou de la mesure dimensionnelle, c'est ce qui se fait partout... mais souvent, il y a un DSP en tête ...

Mais revenons au but initial de ce DRO.
Visualiser de façon confortable les positions X,Y,Z de notre fraiseuse et tout cela en s'affranchissant des jeux dans les différentes vis mère...


Je ne critique en rien tout ce qui se dit et s'il fallait faire un système d'acquisition pour faire une CNC en boucle fermée à partir d'un PC pour de la production de précisison, cela serait tout à fait justifié.

Mais aujourd'hui, comment faisons-nous.
Nous prenons notre PàC d'une main et faisons une mesure qui n'est peut-être pas optimale (paralaxe,...).

Mais ce forum est là pour débattre.

Ce que je ne voudrais pas c'est qu'on fasse un mouton à 5 pattes pour un projet qui au début avait un but bien précis et qui intéressait une grande partie des membres de ce forum...

Pour ma part, la partie PC est en route (par mon ami informaticien... )
Je vous tiens au coourant...

 

[bluegate]

Pour avoir réalisé un système DRO comme le votre. Je poste ces différentes considérations. Pour moi, le reste n'est que littérature.

J'utilise des règles chinoises de 150 mm à 800 mm.

Le protocole de toutes ces règles chinoises (pas des PAC) est le protocole Sylvac 2x24 bits. Cela veut dire que la résolution est 20480 pas dans 1 pouce.

==> résolution théorique : (1/20480) * 25.4 mm = 0.00123 mm

MAIS :

Il y a du bruit sur les trois ou quatre derniers bits du mot de 24 bits. Le bruit sur les trois derniers bits ne peut pas être supprimé car il est inhérant à la répétabilité et la précision "mécanique et électronique" des règles.

Le bruit sur le quatrième bit est plus lié à la "sensibilité électronique", càd filtrage, routage du PCB, blindage, masse etc....

Si vous avez du bruit sur les trois derniers bits la précision est alors de
(7/20480) * 25.4 = 0.00868 mm

Si vous avez du bruit sur les quatre derniers bits la précision est alors de
(15/20480) * 25.4 = 0.0186 mm

une chose pour terminer le montage des règles est primordiale et je peux vous dire que monter une règle de plus de 500 mm parfaitement parallèle dans les deux plans n'est pas si simple.

En conclusion, en tenant compte de tous le paramètres, il y a moyen d'avoir une précision de + ou - 1/100 mm. Quel bricoleur va au-delà ????

maintenant pour les PAC chinois, jamais utilisé ... Donc pas de commentaires.

Bluegate

PS : échantillonner au "falling edge" de la clock car il y a parfois des glitches sur la data mais apparemment jamais au "falling edge"

 

[MaX-MoD]

pour répondre à bebert:

Bien sur, la précision (au sens mathématique du terme) est améliorée.
Mais ce n'est pas car on met deux PAC en // que l'erreur maximale entre position vraie et position affichée va être diminuée.
Au final, l'erreur maximale sera toujours de 0.01mm, même avec un milion de PAC.
MAIS les valeurs affichées seront plus souvent plus proches de la valeur vraie.

de la même façon, il ne faut pas croie qu'on peut avoir une précision de 1.23µm en moyennant les valeurs envoyées par le PAC, la construction mécanique du PAC et la non linéarité de circuit de mesure font qu'au total on se retrouve toujours à 0.01mm de précision (0.02 à partir des PAC de 300mm apparemment), mais on aura augmenté la RESOLUTION.
La distinction est plutôt immatérielle et dure à concevoir, on a tendance à vite faire l'amalgame, c'est pourquoi j'appuie bien là dessus.

Cependant, moyenner plusieurs valeurs apporte un confort certain, n'offusque pour ne pas voir les derniers chiffres bouger tout le temps (ce qui, bien sur, sera intégré à dsDRO).

Wika, ravi d'apprendre que ton ami a commencé de son coté

A+
Max