CHAPITRE 5 LA SYNCHRONISATION
6.2 Programme d’acquisition
6.2.6 Analyse des résultats de tests réalisés avec certaines versions du programme
Les données acquises et enregistrées dans le fichier résultat sont analysées à la suite de chaque test. Chaque fichier contient deux colonnes de données dont chacune correspond aux mesures de l’un des deux capteurs. Ces mesures sont ordonnées en fonction du temps. Toute mesure du premier capteur correspond à celle en face d'elle (du deuxième capteur). Un exemple d’une partie d’un fichier résultat est présenté dans l’annexe J. Ce fichier est issu d’un test réalisé avec la version finale de notre programme, obtenu avec la configuration présentée à l’annexe I. Le fichier est trop volumineux pour être présenté en totalité.
Pour s’assurer de la synchronisation des deux acquisitions, il faut que chaque mesure de la première colonne soit exactement la même que la mesure de la deuxième colonne qui lui correspond vue que les deux compteurs perçoivent le même signal.
Au cours du processus, pour certain cas et en utilisant certaines des versions non optimisées du programme telles que la version initiale, la synchronisation était loin d’être atteinte et il était assez simple de s’en apercevoir juste en ouvrant le fichier résultat comme un fichier texte ordinaire et en inspectant les données qu’il contient. Ceci est illustré dans l’annexe K. À première vue la différence entre les éléments des deux colonnes était claire. Mais au fur et à mesure que nous améliorons le programme et que nous développons de nouvelles versions, nous nous approchons petit à petit de la synchronisation et les différences entre les mesures des deux compteurs deviennent moins élevées et moins fréquentes et par conséquent moins faciles à déceler. Ainsi, pour mieux analyser
les résultats plus en détail, mesure par mesure pour s’assurer s’ils sont bien synchronisés, nous avons recourt à des scripts développés en utilisant le logiciel Matlab. Nous cherchons à mettre en évidence toute différence existante entre les deux colonnes de mesure des fichiers résultats des tests. Pour cela, et pour chaque test, nous affichons les deux courbes d’évolution des deux signaux en fonction du temps dans un premier graphe et nous affichons la différence entre les deux signaux au cours du temps dans un deuxième graphe.
Nous présentons les analyses des résultats de tests réalisés avec certaines versions du programme pour mettre en évidence les améliorations apportées afin d’aboutir à la version finale assurant la synchronisation recherchée.
6.2.6.1 Version initiale
Pour la version initiale du logiciel, une simple inspection visuelle du fichier résultat présenté dans l’annexe K, révèle que les différences entre les deux comptages sont flagrantes. Ce diagnostic est confirmé par le graphe d’évolution des deux comptes au cours du temps présenté à la Figure 6.3 ainsi que le graphe de l’évolution de la différence entre eux au cours du temps illustré par la Figure 6.4.
Nous constatons que les comptages sont différents et dérivent l’un de l’autre causant un gap qui s’accentue au cours du temps.
6.2.6.2 Version intermédiaire 1
Les résultats des tests avec une autre version améliorée sont montrés aux figures 6.5 et 6.6. Figure 6.4 : Différences entre les comptes pour un test avec la version initiale du programme
Figure 6.3 : Évolution des comptes des deux compteurs pour un test avec la version initiale du programme
Figure 6.5 : Évolution des comptes des deux compteurs pour un test avec une version intermédiaire 1 du programme Figure 6.6 : Différences entre les
comptes pour un test avec une version intermédiaire 1 du programme
Figure 6.5 : Évolution des comptes des deux compteurs pour un test avec une version intermédiaire 1 du programme
Figure 6.6 : Différences entre les comptes pour un test avec une version intermédiaire 1 du programme
Figure 6.3 : Évolution des comptes des deux compteurs pour un test avec la version initiale du programme
Figure 6.4 : Différences entre les comptes pour un test avec la version initiale du programme
Pour atteindre cette version, plusieurs améliorations ont été apportées tels que la modification de certains blocs fonctionnels, leurs paramétrages et leurs emplacements. Nous constatons que les courbes de la figure 6.5 décrivant l’évolution des comptages au cours du temps des deux compteurs sont presque superposées et que le gap n’est plus aussi perceptible qu’avec la version précédente. Néanmoins, cela ne veut pas dire pour autant que l’acquisition est synchronisée. Ainsi nous ne pouvons plus nous fier à ce genre de graphe. En effet, à partir de la courbe de la figure 6.6 décrivant l’évolution de la différence des comptes au cours du temps nous remarquons que des sauts considérables se produisent et se manifestent par une différence soudaine impliquant que la synchronisation n’est pas atteinte.
6.2.6.3 Version intermédiaire 2
Cette nouvelle version implémente d’autre techniques de synchronisation notamment le cadencement matériel cité précédemment. Cette technique consiste à générer nous même le signal d’horloge qui sera utilisé par les deux compteurs grâce à un troisième compteur du matériel d’acquisition. Ceci permet d’avoir un signal d’horloge plus précis et pouvant atteindre des fréquences bien plus élevées que celui généré logiciellement par défaut par l’ordinateur. En réalisant des tests, les résultats s’améliorent. Ceci est illustré par la Figure 6.7 qui met l’accent sur la différence existante entre les comptages au cours du temps.
Figure 6.7 : Différences entre les comptes pour un test avec une version intermédiaire 2 du programme
Nous constatons que le saut n’existe plus et que la différence est presque constante au cours du temps. Mais cela ne signifie pas pour autant que notre objectif est atteint. En effet cette différence vaut -8.75±0.25 cycles. Nous ne pouvons pas tolérer une différence aussi élevée ce qui signifie que le programme n’est pas encore au point. Il semblerait que l’acquisition des deux compteurs ne soit pas déclenchée simultanément puisque la différence est existante depuis le début des acquisitions.
6.2.6.4 Version finale
Pour pallier au problème de déclenchement de la version précédente du programme, nous utilisons le Arm Start Trigger qui est l’une des techniques de synchronisation citées précédemment et qui permet de déclencher les acquisitions par un signal externe. En effet, pour s’assurer que l’acquisition se déclenche exactement au même instant pour les deux compteurs, nous ajoutons un déclencheur assuré par un signal 5V continu venant d’un générateur de tension stabilisée 5V et relié à l’une des entrées du module d’entrées/sorties numériques du matériel d’acquisition. Cette entrée est configurée dans l’interface de supervision en tant que déclencheur. À chaque test il faut activer le générateur pour commencer l’acquisition. C’est le passage de l’état 0 (0V) à l’état 1 (5V) qui provoque le début de l’acquisition et non pas le signal continu 5V en lui-même. Ce qui nous permet finalement d’atteindre notre objectif. Ceci est illustré dans la Figure 6.8.
Figure 6.8 : Différences entre les comptes pour un test avec une version finale du programme
En effet, nous remarquons que l’acquisition des deux compteurs se déclenche simultanément et que les différences entre les comptes se limitent à 0±0.25 cycles que nous estimons être tolérables pour notre application.
Ainsi, grâce à cette version développée et après avoir déterminé le paramétrage optimal de l’interface de supervision présentée dans l’annexe I, nous pouvons affirmer que nous avons atteint une synchronisation à un quart de cycle près et nous pouvons réaliser les mesures sur la machine avec une précision d’un quart de cycle. La valeur de cette précision dépend de la résolution de mesure. Ainsi, elle correspond à 0.5 μm pour l’encodeur et à 0.79 nm pour le laser.
Un schéma bloc simplifié de cette version finale est présenté à la Figure 6.9.