AN0502 – Connexion de votre interface graphique en tant que Modbus Slave
Les interfaces graphiques développées dans SHIPTide et fonctionnant dans SHIPEngine doivent communiquer avec le monde extérieur. En règle générale, votre interface graphique doit activer/désactiver des choses, trouver l’état des choses dans le monde extérieur et, de manière générale, échanger des informations.
Cette note d’application couvre la configuration et l’initialisation d’une interface graphique SHIP sur une carte SIM d’un simple périphérique virtuel slave Modbus.
Lectures obligatoires
Avant de procéder à cette demande de remarque, assurez-vous d’avoir examiné les éléments suivants :
Pour plus d’informations sur Modbus, consultez cette liste de ressources.
Liaison du protocole au matériel
La première étape de la connexion en tant que périphérique slave Modbus consiste à créer un nœud de liaison dans la zone Ressources.
Dans SHIPTide, allez dans la zone Ressources et faites un clic droit sur la section « Liens » et ajoutez un nouveau nœud de lien. Ce nœud liera le protocole slave Modbus à un canal de communication physique, alors configurez ce nouveau nœud de liaison avec des propriétés comme celle-ci :
Chaque canal d’une plate-forme ne peut être lié qu’une seule fois à un seul protocole. Par exemple, UART0 ne peut être lié qu’à un seul protocole (par exemple MODBUS_SLAVE_RTU).
Création d’un ou de plusieurs périphériques slaves virtuels
Au sein d’un lien donné, il peut y avoir un ou plusieurs nœuds d’ensemble de liens. Chaque ensemble de liens englobe tout le trafic entre deux points d’extrémité d’une liaison. Du côté slave des protocoles maître/slave (par exemple le MODBUS_SLAVE_RTU), l’interface graphique peut répondre en tant qu’un ou plusieurs slaves Modbus. Même si le protocole s’exécute sur un seul canal de communication physique (par exemple UART0), chaque ensemble de liens au sein de la liaison peut agir comme l’un des nombreux slaves virtuels indépendants.
L’ajout de deux ensembles de liens à notre exemple précédent pourrait ressembler à ceci :
Modbus attaché à UART0, potentiellement l’un des nombreux autres appareils slaves Modbus sur le réseau physique. Ce réseau physique (alias canal) pourrait être, par exemple, un réseau RS485 multi-points avec de nombreux slaves dont notre carte SIM n’est qu’un parmi d’autres. Notre interface graphique, parce qu’elle a les deux ensembles de liens créés à l’ID #1 et #13, répondra comme s’il s’agissait de deux de ces slaves sur le réseau.
Ajout de variables de lien partagé
L’interface graphique SHIP communique avec un périphérique réseau distant à l’aide du concept de variables de liaison. Il s’agit de variables dont les valeurs sont partagées, presque automatiquement, sur le lien de communication. Une partie doit posséder la valeur réelle de la variable, les autres parties du réseau ont simplement besoin d’obtenir des copies de la dernière valeur afin d’afficher, de réagir, de contrôler ou d’agir autrement sur cette valeur.
Par exemple, si un périphérique sur un réseau dispose d’un capteur de RPM de moteur, ce périphérique « possède » cette valeur, peut-être représentée par une valeur de RPM signée de 16 bits (pour la direction du moteur). D’autres appareils sur le réseau qui ont besoin de connaître le régime de ce moteur doivent d’une manière ou d’une autre accéder périodiquement à la « variable RPM » de cet appareil. Une interface graphique de SHIP, par exemple, peut avoir besoin de mettre à jour une valeur à l’écran indiquant le régime du moteur toutes les secondes ou même plus fréquemment.
Ces variables de réseau partagées sont représentées dans votre interface graphique SHIP, chacune sous forme de nœuds linkvar décrivant ces variables de réseau partagées au sein d’un ensemble de liens donné. Les propriétés linkvar disponibles dépendent du protocole sélectionné.
Les propriétés normales d’une linkvar sont les suivantes :
| Nom de la propriété | Description |
|---|---|
| name | Un nom de variable unique dans l'ensemble de liens |
| datatype | Le type de données de cette variable de lien peut être limité en fonction des protocoles |
| address | La plupart des protocoles exigent que chaque variable ait une adresse/emplacement/numéro d'identification unique attribué |
| direction | La plupart des protocoles ont besoin de comprendre s'il s'agit d'une variable d'entrée ou de sortie |
| enabled | La valeur par défaut est true, mais peut être définie à false dans SHIPTide. Seules les variables activées participent à l'interrogation (le cas échéant). |
La direction peut être un peu déroutante : elle concerne toujours SHIPEngine et l’interface graphique. Ainsi, une direction de sortie signifie que les données sont fournies par SHIPEngine à l’appareil sur le réseau à l’extrémité distante de l’ensemble de liens, que l’ensemble de liens soit un maître ou un slave dans un environnement maître/slave. De même, une direction d’entrée signifie que les données arrivent dans la variable à partir de l’extrémité distante de l’ensemble de liens. N’oubliez pas que « in » et « out » sont par rapport à votre interface graphique dans SHIPEngine.
Les types de données dépendent du protocole et, dans le cas de Modbus, peuvent être limités aux types de données Modbus de base booléens et courts.
En développant l’exemple ci-dessus avec quatre linkvars, on peut se présenter comme suit :
Notre exemple ici est, peut-être, une interface graphique hypothétique contrôlant une pompe. Notre interface graphique (dans un script Sail) pourrait allumer la pompe en définissant la fenêtre de liaison booléenne de sortie pumpOnRequest sur « true ». Étant donné que les maîtres Modbus interrogent leurs slaves, la prochaine fois que le maître interroge l’adresse de l’slave #1 0x4000 (« pumpOnRequest », un booléen), il lira un « true » à cet emplacement de variable partagée, indiquant au maître (la pompe) d’allumer. Il peut également interroger l’adresse de l’slave #1 0x2000 (« pumpRPMRequest », un court-métrage) pour déterminer le régime demandé avant de mettre la pompe en marche. Il peut continuer à interroger ces deux emplacements pour surveiller une demande d’arrêt de la pompe ou de modification du régime. De plus, lorsque la pompe s’allume et s’éteint, et que son régime réel change, elle peut envoyer ces valeurs à l’adresse slave #1 0x4001 (« pumpOn », un booléen) et 0x2002 (« pumpRPM », un court-circuit) respectivement.
Notez que ce n’est pas parce que l’interface graphique « demande » qu’un périphérique distant effectue une action que le périphérique distant le fait réellement. L’interface graphique (dans un script Sail) peut demander à la pompe de se mettre en marche, mais cela peut ne pas se produire pour une raison quelconque (la pompe est en surchauffe, par exemple). Des délais d’expiration et d’autres mécanismes peuvent être effectués dans l’interface graphique pour surveiller ces conditions.
Une bonne pratique consiste à avoir des indicateurs visuels sur l’interface graphique qui reflètent l’état distant réel, plutôt que l’état demandé. Par exemple, une lecture RPM dans l’interface graphique doit refléter la valeur de « pumpRPM », et non « pumpRPMRequest ».
