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...
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...
sambogosse
Nouveau
Salut,
affiche le nom du soft et la version en dessous plutot, ca devrait tenir
A+
affiche le nom du soft et la version en dessous plutot, ca devrait tenir
A+
romteb a dit: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
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 )
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
)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 :
Bon, çà m'empêche pas de programmer non plus.
Edit : bon, piqué au vif par mes compatriotes, j'ai décidé d'agir, vite :
MaX-MoD a dit:Fred8 a dit:
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...
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
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
Pour les plus aveugles d'entre nous ( ), j'ai trouvé un truc assez intéressant: http://www.baghli.com/dspic_vga.php
A+
Max
), j'ai trouvé un truc assez intéressant: http://www.baghli.com/dspic_vga.phpA+
Max
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...
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 a dit:
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é ...
++
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.
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
Apprenti
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.
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.
bebert2611
Apprenti
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.
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.
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?
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
Apprenti
MaX-MoD a dit:
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...
MaX-MoD a dit:
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 ....
bebert2611
Apprenti
coredump a dit:
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.
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êmebebert2611 a dit:
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)bebert2611 a dit:
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!
Tout à fait, mais il faut aussi pouvoir exploiter les informations qu'on a.coredump a dit:
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
Apprenti
MaX-MoD a dit: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...
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.
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.
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...
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...
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"
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"
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
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
