Délais de communication

Le test précédent nous montre que le contrôleur n’est plus utilisable à partir de 36 Hz. Notre hypothèse est que la taille des réponses peut être la cause de cette limite : puisqu’il y a beaucoup de caractères à transmettre, le canal de transmission est occupé pendant un temps non négligeable. En utilisant une fréquence de communication trop élevée, nous pouvons aboutir à une collision des messages.

C’est ce que nous souhaitons tester dans cette expérience en mesurant précisément les temps mis en jeu dans la communication série.

3.2.4.1 Procédure expérimentale

Nous connectons un oscilloscope sur les deux liens de la connexion série : nous surveillons donc en même temps les commandes envoyées par le serveur (TX) et les réponses du contrô- leur bas-niveau (RX).

La capture par l’oscilloscope (trigger ) se déclenche à chaque commande en provenance du serveur et nous mesurons les temps associés à l’échange :

– Longueur (en ms) de la commande ; – Longueur (en ms) de la réponse ;

– Délai entre la commande et sa réponse ; – Temps total pris par l’échange.

Ces mesures ont été effectuées sur les commandes les plus couramment utilisées : gs, gcx, \r, scx, (vide). . . ainsi que le message abc destiné à provoqué une erreur puisqu’il n’a pas de signification. La communication sur le port série avec le contrôleur se fait à la vitesse de 57 600 Baud en configuration 8-N-1, la vitesse de transmission théorique est de : 173.6 µs / caractère

3.2.4.2 Résultats

Le tableau 3.5 présente le résultat des mesures de temps de transmission. Nous indiquons la commande envoyée, sa taille en caractères (comprenant les caractères supplémentaires présentés à la section 3.1.3.2), les temps théoriques et mesurés de la transmission et le temps mesuré entre le début de la commande et le début de sa réponse.

Tableau 3.5. Mesures des temps de transmission sur la liaison RS232 avec le micro-contrôleur

Commande Taille réponse Temps commande (ms) Temps réponse (ms) Délai (ms) (caractères) Théorique Mesuré Théorique Mesuré

gs 92 0.53 0.70 15.97 17.60 0.2 gcx 168 0.71 0.87 29.16 33.40 0.2 gcy 168 0.71 0.87 29.16 33.40 0.2 gcz 168 0.71 0.87 29.16 33.40 0.2 gv 86 0.53 0.70 14.93 16.52 0.2 scx 0 43 1.06 1.25 7.46 8.40 0.2 scx -65500 48 1.94 2.12 8.33 9.32 0.2 vide (\r) 38 0.35 0.37 6.60 7.40 0.2 erreur (abc) 69 0.71 0.87 11.98 13.02 0.2

La différence entre le temps de transmission théorique à 57600 Baud et le temps mesuré est compris entre 8% et 12%. Les données mesurées nous permettent de déterminer que la vitesse de transmission réelle est de 196.1 µs / caractère. On constate que dans tous les cas, la réponse a été émise 0.2 ms après la réception de la commande. Ceci est permis par le fait que

le contrôleur commence avant tout par ré-émettre la commande qu’il a reçu (voir 3.1.3.2) : il n’a donc pas besoin d’avoir reçu tout le message pour commencer à émettre sa réponse.

La figure 3.9 présente deux exemples représentatifs des mesures effectuées. Les captures d’oscilloscope pour les commandes gs et gcx figurent en 3.9(a) et 3.9(b) (note : les échelles de temps sont différentes) et leurs interprétations détaillées en 3.9(c) et 3.9.

liaison RS232 (TX) liaison RS232 (RX) réponse

commande (gs)

(a) Trames transmises pour la commande gs

liaison RS232 (TX) liaison RS232 (RX) réponse

commande (gcx)

(b) Trames transmises pour la commande gcx

Envoi de la commande : gs 0 1 Temps TX 0

1 Envoi de la réponse : gs System in idle [...]

RX

Transmission commande : 700 µs Délai avant réponse : 220 µs

Durée totale : 17.72 ms Transmission réponse : 17.5 ms

(c) Représentation des temps mesurés pour la com- mande gs Envoi de la commande : gcx 0 1 Temps TX 0

1 Envoi de la réponse : gcx Channel X status [...]

RX

Transmission commande : 870 µs Délai avant réponse : 200 µs

Durée totale : 33.40 ms Transmission réponse : 33.20 ms

(d) Représentation des temps mesurés pour la com- mande gcx

Figure 3.9. Mesure des temps de transmission sur le port série.

3.2.4.3 Analyse & discussion

Si nous faisons l’hypothèse d’un taux d’échec de 10%, alors le temps moyen pris par un échange est de : tmoy= 0.9 tgs + tgcx + tgcy + tgcz 4  + 0.1 _t erreur+ tvide 2  = 0.9 17.6 + 33.4 × 3 4  + 0.1 13.0 + 7.4 2  = 0.9 × 29.45 + 0.1 × 10.20 tmoy= 27.53 ms.

Ce temps est incompressible pour une vitesse de transmission donnée (57600 Baud), on peut dès lors calculer la fréquence maximale atteignable sans collision des messages :

fmax=

1 tmoy

= 36.60 Hz.

Dans le cas d’un envoi de commandes en boucle gs gcx gcy gcz (qui représentent l’essentiel des commandes envoyées en utilisation normale), on obtient donc une fréquence d’envoi théorique ne pouvant pas dépasser 36.6 Hz sous peine de collision des messages. Ce résultat est en parfait accord avec les essais réalisés en 3.2.3. Il vient nous conforter dans l’hypothèse que la taille des messages est un obstacle à une haute fréquence de contrôle.

Nous pouvons extrapoler ce résultat en calculant la fréquence qu’il serait possible d’at- teindre en modifiant les réponses pour que seules les valeurs chiffrées soit échangées (et les valeurs « texte » converties en énumérations). Ainsi l’interrogation de l’axe X ne serait plus

1 > gcx

2 < gcx \r\n\ rChannel X status \n\ rFault : No\n\ rCurrent output : -0.0 A\n\ rVoltage output : -0.0 V\n\ rHeatsink temp : 22 C\n\ rState : Idle \n\ rP10

status : OK\r\n .\0 Error 0 x01 - incorrect command \r\n .\0

mais 1 > gcx

2 < gcx 0 0.0 0.0 21 0 0\0

L’interrogation du système (commande gs) ne serait plus 1 > gs

2 < gs\r\n\ rSystem in idle - AC OFF , Interlocks OK , Slope : 20 \r\n .\0 Error 0 x01 - incorrect command \r\n .\0

mais 1 > gs

2 < gs 0 0 0 20\0

Nous pouvons faire de même pour l’ensemble des commandes pour aboutir à une simpli- fication des commandes. En conservant la vitesse de transmission telle que mesurée (196.1 µs / caractère) ainsi qu’un taux d’erreur de 10%, mais en retirant les 34 caractères superflus décrits en 3.1.3.2, le temps de transmission moyen deviendrait ainsi

tmoy= 0.9 tgs + tgcx + tgcy + tgcz 4  + 0.1 _t erreur+ tvide 2  = 0.1961 ×  0.9 _{12 + 21 × 3} 4  + 0.1 _{6 + 1} 2  tmoy= 3.38 ms.

Ce qui nous permet d’espérer une communication pouvant aller jusqu’à la fréquence maxi- male de fmax = _tmoy1 = 296 Hz sans collision des messages. Il convient encore une fois de

mettre en perspective cette fréquence avec les capacités du système électrique : une telle modification ne deviendrait indispensable qu’en cas de mise à l’échelle des alimentations électriques.