Définition d'un protocole
La complexification progressive de l'IHM côté PC, la réalisation de tâches ou de séquences de tâches de plus en plus entremêlées oblige à mieux scénariser l'usage et le protocole entre l'IHM et le M5 pilotant le banc.
La première difficulté est la construction itérative qui a amené à des incompatibilités dans les messages envoyés et reçus : par exemple IZ, compris comme 'demande d'initialisation de l'axe Z' envoyé par l'IHM et compris comme 'résultat de la séquence précédente' envoyé par le M5. D'un côté comme de l'autre, l'utilisation de serialEvent pour gérer l'arrivée des chaînes de commandes semble en effet déclencher l'analyse, y compris quand c'est l'émetteur qui vient d'écrire sur le port série.
(autrement dit : l'IHM fait un serial_port.println("IZ") et cela déclenche -toujours du côté IHM !- l'analyse de la chaîne reçue).
Plus embêtant encore, cela dénote que ni l'IHM, ni le M5 ne sont l'un maître, l'autre esclave : ils sont, selon les cas, l'un ou l'autre. On est tenté de mettre l'IHM en maître : c'est centré utilisateur, c'est logique. Sauf que pendant qu'un mouvement est en cours, pour l'instant, on est nécessairement M5 maître. Ou alors, il faut que le M5 accomplisse des tâches de plus haut niveau, et ne fasse que retourner des résultats d'action... Ou envoie en permanence des données sur l'état (mais on risque d'avoir du scintillement côté IHM si on fait ça).
Les messages sont constitués d'une chaîne de caractères, terminée par un LF (ASCII 10), le différents éléments du message sont simplement séparés par des espaces.
Liste des messages :
|
Emetteur |
Message | Signification | Arguments | Remarques |
| IHM | S | stop moteurs | aucun | |
| IHM | E | état des capteurs | aucun | |
| IHM | +Z | mise en route moteur Z | aucun | contrôle manuel |
| IHM | -Z | mise en route moteur Z | aucun | contrôle manuel |
| IHM | +X | mise en route moteur X | aucun | contrôle manuel |
| IHM | -X | mise en route moteur X | aucun | contrôle manuel |
| IHM | IZ | initialisation Z | aucun | va chercher le Z=0 (position haute) |
| IHM | IX | initialisation X | aucun | va chercher le X=0 (position en butée) |
| IHM | Z | aller à une distance Z donnée de la surface | distance voulue |
[0; 220] (en mm, 0 au contact) |
| IHM | GX | aller à la position X donnée | position voulue |
[0;1500] (en mm, 0 à "gauche", butée carotte) |
| IHM | VX -> FX | changer la |
fréquence | [1000;15000] |
| IHM | VZ -> FZ | changer la |
fréquence | [1000;15000] |
| Emetteur | Message | Signification | Arguments | Remarques |
| M5 | K | valeurs retournées par les capteurs | end_stop_up distx distz moving | renvoie donc K suivi de 4 valeurs séparées par un espace |
| M5 | P |
déplacement bloqué par un capteur (end_stop_up ou end_stop_down ou distz ou distx) |
non implémenté | |
| M5 | R |
résultat d'une action |
action result | action = MX, MZ ou IZ, result = success ou failed |
Il est nécessaire de ne se déplacer en X qu'après une remontée en Z=0.butée. On ne redescendra qu'à X fixe, en mesurant distz tout au long de la descente.