Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Adaptateur de RTU protocole Modbus
Le composant adaptateur de RTU protocole Modbus (aws.greengrass.Modbus) interroge les informations des appareils Modbus RTU locaux.
Pour demander des informations à un RTU appareil Modbus local avec ce composant, publiez un message dans la rubrique où ce composant est abonné. Dans le message, spécifiez la RTU demande Modbus à envoyer à un appareil. Ce composant publie ensuite une réponse contenant le résultat de la RTU demande Modbus.
Note
Ce composant fournit des fonctionnalités similaires à celles du connecteur d'adaptateur de RTU protocole Modbus de la version AWS IoT Greengrass 1. Pour plus d'informations, consultez la section Connecteur d'adaptateur de RTU protocole Modbus dans le guide du développeur de la AWS IoT Greengrass V1.
Rubriques
Versions
Les versions de ce composant sont les suivantes :
-
2,1x
-
2,0.x
Type
Ce composant est un composant Lambda () aws.greengrass.lambda. Le noyau Greengrass exécute la fonction Lambda de ce composant à l'aide du composant Lambda Launcher.
Pour de plus amples informations, veuillez consulter Types de composants.
Système d’exploitation
Ce composant ne peut être installé que sur les appareils principaux de Linux.
Prérequis
Ce composant répond aux exigences suivantes :
-
Votre appareil principal doit répondre aux exigences pour exécuter les fonctions Lambda. Si vous souhaitez que le périphérique principal exécute des fonctions Lambda conteneurisées, le périphérique doit répondre aux exigences requises. Pour de plus amples informations, veuillez consulter Exigences relatives à la fonction Lambda.
-
Python
version 3.7 installé sur le périphérique principal et ajouté à la variable d'PATHenvironnement. -
Connexion physique entre le périphérique AWS IoT Greengrass principal et les appareils Modbus. Le périphérique principal doit être connecté physiquement au RTU réseau Modbus via un port série, tel qu'un USB port.
-
Pour recevoir les données de sortie de ce composant, vous devez fusionner la mise à jour de configuration suivante pour l'ancien composant routeur d'abonnement (
aws.greengrass.LegacySubscriptionRouter) lorsque vous déployez ce composant. Cette configuration indique le sujet dans lequel ce composant publie les réponses.Pour de plus amples informations, veuillez consulter Créer des déploiements.
-
L'adaptateur de RTU protocole Modbus est compatible pour fonctionner dans unVPC.
Dépendances
Lorsque vous déployez un composant, il déploie AWS IoT Greengrass également des versions compatibles de ses dépendances. Cela signifie que vous devez satisfaire aux exigences relatives au composant et à toutes ses dépendances pour réussir le déploiement du composant. Cette section répertorie les dépendances des versions publiées de ce composant et les contraintes de version sémantiques qui définissent les versions des composants pour chaque dépendance. Vous pouvez également consulter les dépendances de chaque version du composant dans la AWS IoT Greengrass console
Pour plus d'informations sur les dépendances des composants, consultez la référence de la recette des composants.
Configuration
Ce composant fournit les paramètres de configuration suivants que vous pouvez personnaliser lorsque vous déployez le composant.
Note
La configuration par défaut de ce composant inclut les paramètres de la fonction Lambda. Nous vous recommandons de modifier uniquement les paramètres suivants pour configurer ce composant sur vos appareils.
Données d'entrée
Ce composant accepte les paramètres de RTU demande Modbus sur le sujet suivant et envoie la RTU demande Modbus à l'appareil. Par défaut, ce composant s'abonne aux messages de publication/d'abonnement locaux. Pour plus d'informations sur la façon de publier des messages vers ce composant à partir de vos composants personnalisés, consultezPublier/souscrire des messages locaux.
Rubrique par défaut (publication/abonnement local) : modbus/adapter/request
Le message accepte les propriétés suivantes. Les messages d'entrée doivent être au JSON format.
request-
Les paramètres de la RTU demande Modbus à envoyer.
La forme du message de demande dépend du type de RTU demande Modbus qu'il représente. Les propriétés suivantes sont requises pour toutes les demandes.
Type :
objectqui contient les informations suivantes :operation-
Nom de l'opération à exécuter. Par exemple, spécifiez
ReadCoilsRequestde lire les bobines sur un appareil ModbusRTU. Pour plus d'informations sur les opérations prises en charge, consultezRTUDemandes et réponses Modbus.Type :
string device-
L'appareil cible de la requête.
Cette valeur doit être un entier compris entre
0et247.Type :
integer
Les autres paramètres à inclure dans la demande dépendent de l'opération. Ce composant gère le contrôle de redondance cyclique (CRC) afin de vérifier les
demandes de données pour vous. Note
Si votre demande inclut une
addresspropriété, vous devez spécifier sa valeur sous forme d'entier. Par exemple,"address": 1. id-
ID arbitraire de la demande. Utilisez cette propriété pour associer une demande d'entrée à une réponse de sortie. Lorsque vous spécifiez cette propriété, le composant définit la
idpropriété de l'objet de réponse sur cette valeur.Type :
string
Exemple d'entrée : demande de lecture de bobines
{ "request": { "operation": "ReadCoilsRequest", "device": 1, "address": 1, "count": 1 }, "id": "MyRequest" }
Données de sortie
Ce composant publie par défaut les réponses sous forme de données de sortie sur le MQTT sujet suivant. Vous devez spécifier cette rubrique subject dans la configuration de l'ancien composant routeur d'abonnement. Pour plus d'informations sur la façon de s'abonner à des messages sur ce sujet dans vos composants personnalisés, consultezPublier/souscrire AWS IoT Core MQTT des messages.
Rubrique par défaut (AWS IoT Core MQTT) : modbus/adapter/response
La forme du message de réponse dépend de l'opération de demande et de l'état de la réponse. Pour obtenir des exemples, consultez Exemples de demandes et de réponses.
Chaque réponse inclut les propriétés suivantes :
response-
Réponse de l'RTUappareil Modbus.
Type :
objectqui contient les informations suivantes :status-
Le statut d'une demande. Le statut peut avoir l'une des valeurs suivantes :
-
Success— La demande était valide, le composant l'a envoyée au réseau Modbus et le RTU réseau Modbus RTU a renvoyé une réponse. -
Exception— La demande était valide, le composant l'a envoyée au réseau Modbus et le RTU réseau Modbus RTU a renvoyé une exception. Pour de plus amples informations, veuillez consulter Statut de la réponse : Exception. -
No Response— La demande n'était pas valide et le composant a détecté l'erreur avant d'envoyer la demande au RTU réseau Modbus. Pour de plus amples informations, veuillez consulter Statut de la réponse : Pas de réponse.
-
operation-
Opération demandée par le composant.
device-
L'appareil sur lequel le composant a envoyé la demande.
payload-
Réponse de l'RTUappareil Modbus. Dans l'
statusaffirmativeNo Response, cet objet contient uniquement uneerrorpropriété avec la description de l'erreur (par exemple,[Input/Output] No Response received from the remote unit).
id-
L'ID de la demande, que vous pouvez utiliser pour identifier quelle réponse correspond à quelle demande.
Note
Une réponse pour une opération d'écriture est simplement un écho de la demande. Bien que les réponses écrites n'incluent pas d'informations pertinentes, il est recommandé de vérifier le statut de la réponse pour voir si la demande aboutit ou échoue.
Exemple de sortie : réussite
{ "response" : { "status" : "success", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 1, "bits": [1] } }, "id" : "MyRequest" }
Exemple de sortie : échec
{ "response" : { "status" : "fail", "error_message": "Internal Error", "error": "Exception", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 129, "exception_code": 2 } }, "id" : "MyRequest" }
Pour obtenir plus d’exemples, consultez Exemples de demandes et de réponses.
RTUDemandes et réponses Modbus
Ce connecteur accepte les paramètres de RTU demande Modbus en tant que données d'entrée et publie les réponses en tant que données de sortie.
Les opérations communes suivantes sont prises en charge.
| Nom de l'opération dans la demande | Code de fonction dans la réponse |
|---|---|
| ReadCoilsRequest | 01 |
| ReadDiscreteInputsRequest | 02 |
| ReadHoldingRegistersRequest | 03 |
| ReadInputRegistersRequest | 04 |
| WriteSingleCoilRequest | 05 |
| WriteSingleRegisterRequest | 06 |
| WriteMultipleCoilsRequest | 15 |
| WriteMultipleRegistersRequest | 16 |
| MaskWriteRegisterRequest | 22 |
| ReadWriteMultipleRegistersRequest | 23 |
Voici des exemples de demandes et de réponses pour les opérations prises en charge.
- Bobines de lecture
-
Exemple de requête :
{ "request": { "operation": "ReadCoilsRequest", "device": 1, "address": 1, "count": 1 }, "id": "TestRequest" }Exemple de réponse :
{ "response": { "status": "success", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 1, "bits": [1] } }, "id" : "TestRequest" } - Lire les entrées discrètes
-
Exemple de requête :
{ "request": { "operation": "ReadDiscreteInputsRequest", "device": 1, "address": 1, "count": 1 }, "id": "TestRequest" }Exemple de réponse :
{ "response": { "status": "success", "device": 1, "operation": "ReadDiscreteInputsRequest", "payload": { "function_code": 2, "bits": [1] } }, "id" : "TestRequest" } - Lire les registres de détention
-
Exemple de requête :
{ "request": { "operation": "ReadHoldingRegistersRequest", "device": 1, "address": 1, "count": 1 }, "id": "TestRequest" }Exemple de réponse :
{ "response": { "status": "success", "device": 1, "operation": "ReadHoldingRegistersRequest", "payload": { "function_code": 3, "registers": [20,30] } }, "id" : "TestRequest" } - Lire les registres d'entrée
-
Exemple de requête :
{ "request": { "operation": "ReadInputRegistersRequest", "device": 1, "address": 1, "count": 1 }, "id": "TestRequest" } - Écrire une seule bobine
-
Exemple de requête :
{ "request": { "operation": "WriteSingleCoilRequest", "device": 1, "address": 1, "value": 1 }, "id": "TestRequest" }Exemple de réponse :
{ "response": { "status": "success", "device": 1, "operation": "WriteSingleCoilRequest", "payload": { "function_code": 5, "address": 1, "value": true } }, "id" : "TestRequest" } - Écrire un registre unique
-
Exemple de requête :
{ "request": { "operation": "WriteSingleRegisterRequest", "device": 1, "address": 1, "value": 1 }, "id": "TestRequest" } - Écrire plusieurs bobines
-
Exemple de requête :
{ "request": { "operation": "WriteMultipleCoilsRequest", "device": 1, "address": 1, "values": [1,0,0,1] }, "id": "TestRequest" }Exemple de réponse :
{ "response": { "status": "success", "device": 1, "operation": "WriteMultipleCoilsRequest", "payload": { "function_code": 15, "address": 1, "count": 4 } }, "id" : "TestRequest" } - Écrire plusieurs registres
-
Exemple de requête :
{ "request": { "operation": "WriteMultipleRegistersRequest", "device": 1, "address": 1, "values": [20,30,10] }, "id": "TestRequest" }Exemple de réponse :
{ "response": { "status": "success", "device": 1, "operation": "WriteMultipleRegistersRequest", "payload": { "function_code": 23, "address": 1, "count": 3 } }, "id" : "TestRequest" } - Masque, écriture, registre
-
Exemple de requête :
{ "request": { "operation": "MaskWriteRegisterRequest", "device": 1, "address": 1, "and_mask": 175, "or_mask": 1 }, "id": "TestRequest" }Exemple de réponse :
{ "response": { "status": "success", "device": 1, "operation": "MaskWriteRegisterRequest", "payload": { "function_code": 22, "and_mask": 0, "or_mask": 8 } }, "id" : "TestRequest" } - Lecture et écriture de plusieurs registres
-
Exemple de requête :
{ "request": { "operation": "ReadWriteMultipleRegistersRequest", "device": 1, "read_address": 1, "read_count": 2, "write_address": 3, "write_registers": [20,30,40] }, "id": "TestRequest" }Exemple de réponse :
{ "response": { "status": "success", "device": 1, "operation": "ReadWriteMultipleRegistersRequest", "payload": { "function_code": 23, "registers": [10,20,10,20] } }, "id" : "TestRequest" }Note
La réponse inclut les registres que le composant lit.
Des exceptions peuvent se produire lorsque le format de la demande est valide, mais la demande échoue. Dans ce cas, la réponse contient les informations suivantes :
-
Le
statusest réglé surException. -
Le
function_codeest égal au code de fonction de la requête + 128. -
Le
exception_codecontient le code d'exception. Pour plus d'informations, consultez les codes d'exception de Modbus.
Exemple :
{ "response": { "status": "fail", "error_message": "Internal Error", "error": "Exception", "device": 1, "operation": "ReadCoilsRequest", "payload": { "function_code": 129, "exception_code": 2 } }, "id": "TestRequest" }
Ce connecteur effectue des vérifications de validation sur la demande Modbus. Par exemple, il vérifie les formats non valides et les champs manquants. Si la validation échoue, le connecteur n'envoie pas la demande. A la place, il renvoie une réponse qui contient les informations suivantes :
-
Le
statusest réglé surNo Response. -
L'
errorcontient la raison de l'erreur. -
Le
error_messagecontient le message de l'erreur.
Exemples :
{ "response": { "status": "fail", "error_message": "Invalid address field. Expected <type 'int'>, got <type 'str'>", "error": "No Response", "device": 1, "operation": "ReadCoilsRequest", "payload": { "error": "Invalid address field. Expected Expected <type 'int'>, got <type 'str'>" } }, "id": "TestRequest" }
Si la demande cible un appareil inexistant ou si le RTU réseau Modbus ne fonctionne pas, vous pouvez obtenir unModbusIOException, qui utilise le format No Response.
{ "response": { "status": "fail", "error_message": "[Input/Output] No Response received from the remote unit", "error": "No Response", "device": 1, "operation": "ReadCoilsRequest", "payload": { "error": "[Input/Output] No Response received from the remote unit" } }, "id": "TestRequest" }
Fichier journal local
Ce composant utilise le fichier journal suivant.
/logs/aws.greengrass.Modbus.log/greengrass/v2
Pour consulter les journaux de ce composant
-
Exécutez la commande suivante sur le périphérique principal pour afficher le fichier journal de ce composant en temps réel. Remplacez
/greengrass/v2sudo tail -f/greengrass/v2
Licences
Ce composant inclut les logiciels/licences tiers suivants :
-
pyserial
//Licence BSD
Ce composant est publié dans le cadre du contrat de licence logicielle Greengrass Core
Journal des modifications
Le tableau suivant décrit les modifications apportées à chaque version du composant.
|
Version |
Modifications |
|---|---|
|
2.1.9 |
Version mise à jour pour la version 2.13.0 de Greengrass Nucleus. |
|
2.1.8 |
Version mise à jour pour la version 2.12.0 de Greengrass Nucleus. |
|
2.1.7 |
Version mise à jour pour la version 2.11.0 de Greengrass Nucleus. |
|
2.1.6 |
Version mise à jour pour la version 2.10.0 de Greengrass Nucleus. |
|
2.1.5 |
|
|
2.1.4 |
Version mise à jour pour la version 2.9.0 de Greengrass Nucleus. |
|
2.1.3 |
Version mise à jour pour la version 2.8.0 de Greengrass Nucleus. |
|
2.1.2 |
Version mise à jour pour la version 2.7.0 de Greengrass Nucleus. |
|
2.1.1 |
Version mise à jour pour la version 2.6.0 de Greengrass Nucleus. |
|
2.1.0 |
|
|
2.0.8 |
Version mise à jour pour la version 2.5.0 de Greengrass Nucleus. |
|
2.0.7 |
Version mise à jour pour la version 2.4.0 de Greengrass Nucleus. |
|
2.0.6 |
Version mise à jour pour la version 2.3.0 de Greengrass Nucleus. |
|
2.0.5 |
Version mise à jour pour la version 2.2.0 de Greengrass Nucleus. |
|
2.0.4 |
Version mise à jour pour la version 2.1.0 de Greengrass Nucleus. |
|
2.0.3 |
Première version. |
