Bonjour,
J’ai déjà présenté la famille de passerelles Hilscher netTAP dans mon introduction.
Dans cet article je me propose de développer les différentes options permettant la gestion des protocoles série, supportés sur les ports RS232, RS422 et RS485, configurable avec SYCON.net, des passerelles des gammes NT 100 et NT 50.
ASCII
Ce mode permet la gestion de tout protocole ASCII simple, comme celui d’un lecteur de code à barre par exemple.
Dans ce mode, la passerelle gère un tampon en émission et un en réception.
La passerelle peut travailler en réception seule, émission seule, client (émission / réception) ou serveur (réception / émission).
Depuis le bus de terrain, le contrôleur ou l’automate dispose les trames à émettre dans le tampon d’émission et commande l’émission via un registre de synchronisation dans sa zone de sorties.
Cette trame peut être complétée automatiquement par l’adjonction de caractères de début / somme de contrôle / fin de trame et l’émission peut être réitérée en cas d’erreur. Tout ce traitement est paramétrable avec l’outil de configuration SYCON.net.
A la réception d’une trame, les caractères de contrôle peuvent être traités selon le paramétrage effectué, les données sont déposées dans le tampon de réception et le contrôleur en est informé via le registre de synchronisation dans sa zone d’entrées.
Bien sûr, les erreurs sont signalées.
3964R
Ce mode permet la gestion du protocole 3964R, bien connu dans le monde Siemens.
Le fonctionnement de ce mode s’apparente à celui de l’ASCII.
Je ne vais pas le détailler plus avant.
Modbus RTU
Ce protocole est encore très répandu.
La pile de protocole Modbus RTU embarquée dans les passerelles peut être configurée soit en Maitre, soit en Esclave.
Lua
C’est là où je voulais en venir ! 😉
Lua est un langage de script puissant, léger et rapide :
http://www.lua.org/
Il est possible d’étendre Lua, ce que Hilscher a réalisé en rajoutant des fonctions spécifiques pour la communication, d’une part sur le port série, et d’autre part vers le bus de terrain choisi.
Lors de la configuration de la passerelle NT 100, il est possible de sélectionner un firmware embarquant un interpréteur Lua / netSCRIPT.
On choisit un bus de terrain primaire parmi (Maitre / Esclave) CANopen, DeviceNet, PROFIBUS, EtherCAT, Ethernet/IP, Modbus TCP, PROFINET, Sercos III ou POWERLINK (Esclave) et netSCRIPT côté réseau secondaire.
Avec ce langage, il est possible d’effectuer tout type de traitement sur les trames et de gérer l’émission et la réception selon le besoin.
Cela permet de pré-digérer les trames au niveau de la passerelle et de ne présenter au contrôleur que les données utiles à celui-ci.
Il découle de cette architecture où la passerelle assure l’intégralité de la gestion du protocole ASCII plusieurs avantages :
- Le programme du contrôleur se trouve soulagé d’autant.
- On peut utiliser le même script avec un contrôleur d’un autre fabricant et / ou un bus de terrain différent.
De nombreux exemples et des squelettes de code sont disponibles sur le DVD ainsi que des présentations et tutoriels.
– Et ça ressemble à quoi ?
– A ceci :
-- Hello World
--
-- A minimal script which prints "Hello World" to the RS232 interface.
--
-- Requirements:
-- netTap with netSCRIPT firmware,
-- serial console connected via RS232, 115200 Baud 8N1
--
--
-- Author Date Change
-- =================================================
-- S. Lesch Sep 16, 2009 removed German comments
-- S. Lesch Aug 27, 2009 added comments
--
-- We only want to execute the following block once.
if not run_once then
-- configure serial port
p = PortOpen({
interfacetype = port.INTERFACE_TYPE_RS232,
baudrate = 115200,
databits = 8,
stopbits = 1,
paritymode = port.PARITY_NONE
})
-- Print "Hello World"
p:PortSend("Hello World" .. string.char(10, 13))
-- Remember that the script has executed
run_once = true
end
– Trop cool ! C’est vraiment super mais je ne souhaite pas investir pour l’instant de ressources pour l’apprentissage de Lua / netSCRIPT.
– Nous pouvons prendre en charge le développement de vos scripts si vous nous fournissez la spécification du protocole série et celle de l’interface applicative que vous souhaitez. Cf. notre offre de services.
C’est ce que nous avons réalisé par exemple pour l’un de nos clients utilisant les pompes LEVITRONIX avec contrôleur LPC-200.3 (RS232) :
http://www.levitronix.com
Nous l’avons également réalisé pour le protocole des débitmètres GEMÜ C38 SonicLine :
http://products.gemue.de/fr/produits-high-purity/debitmetre/
Cordialement,
Stéphane