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).
Liste des messages :
| Emetteur | Message | Signification | Arguments | Remarques |
| IHM | S | stop moteurs | aucun | |
| IHM | +Z | mise en route moteur Z | aucun | |
| IHM | -Z | mise en route moteur Z | aucun | |
| IHM | +X | mise en route moteur X | aucun | |
| IHM | -X | mise en route moteur X | aucun | |
| IHM | IZ | initialisation Z | aucun | |
| IHM | IX | initialisation X | aucun |