Archives de catégorie : netTAP

netTAP : firmware spécifique Modbus TCP – CANopen Maitre / SDO + NMT

Bonjour,

Je vous avais présenté dans cet article le firmware spécifique Modbus TCP – CANopen Maitre / SDO + NMT.

Je rappelle rapidement que ce firmware permet les fonctions de lecture / écriture de SDO et la commande NMT CANopen via Modbus TCP.

Ce firmware était disponible pour la passerelle Hilscher NT 100-RE-CO. Nous l’avons porté sur la version économique NT 50-CO-EN.

Vous disposez donc de deux options, l’une pour raccorder un réseau CANopen constitué de plusieurs esclaves, la seconde pour raccorder un seul équipement.

Le manuel utilisateur pour ce firmware est disponible ici :
Manuel%20Utilisateur%20Passerelle%20NetTAP%20Modbus%20TCP%20CANopen%20V02.pdf

Un projet de configuration exemple SYCON.net est également fourni :
NT-OMBCOM-ACYC%2020130718.zip

Enfin, le projet de test avec un automate Schneider Electric M340 est téléchargeable là :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/SchneiderElectric/nt-ombcom-acyc.sta

Le firmware est disponible auprès de Hilscher France.

N’hésitez pas à solliciter Hilscher France si besoin.

Cordialement,
Stéphane

netTAP : firmware spécifique Modbus TCP – CANopen Maitre / SDO + NMT

Bonjour,

Hilscher propose avec ses passerelles netTAP 100, netTAP 50 et netBRICK et les firmwares standard disponibles, environ 300, un éventail de solutions pour la conversion de protocoles particulièrement large.

Cependant, si les firmwares standard couvrent très bien les besoins pour les données échangées cycliquement, comme les PDO pour CANopen, les communications acycliques ne sont à ce jour pas supportées.

Ces échanges acycliques sont utilisés pour la configuration, le paramétrage et le diagnostic précis des équipements connectés.

En visant l’exhaustivité en matière de combinaisons protocolaires, il n’est pas aisé de concevoir un mécanisme générique susceptible de supporter l’ensemble des fonctions quel que soit le protocole. Les concepts sont bien similaires mais les disparités sont irréductibles, volume, type de données, adressage…

D’où la nécessité de concevoir spécifiquement un mécanisme permettant cet échange acyclique. C’est ce que nous avons réalisé avec ce firmware.

Le produit standard Hilscher NT 100-RE-CO possède les interfaces physiques nécessaires et Hilscher France fournit le firmware spécifique.

Les outils de configuration standard Hilscher sont utilisés.

Ce firmware permet les fonctions de lecture / écriture de SDO et la commande NMT CANopen via Modbus TCP.

Le manuel utilisateur pour ce firmware est disponible ici :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/Manuel%20Utilisateur%20Passerelle%20NetTAP%20Modbus%20TCP%20CANopen%20V01.pdf

Un projet de configuration exemple SYCON.net est également fourni :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/Hilscher/NT-OMBCOM-ACYC%2020121123.zip

Enfin, le projet de test avec un automate Schneider Electric M340 est téléchargeable là :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/SchneiderElectric/nt-ombcom-acyc.sta

Il est à noter que le principe retenu pour la gestion des échanges acycliques dans ce firmware peut être aisément transposé à d’autres combinaisons protocolaires et nous pouvons donc réaliser chez Hilscher France la combinaison dont vous auriez besoin comme :

  • PROFINET Maitre ou Esclave – CANopen SDO + NMT
  • Ethernet/IP Maitre ou Esclave – CANopen SDO + NMT
  • PROFIBUS Maitre ou Esclave – CANopen SDO + NMT
  • DeviceNet Maitre ou Esclave – CANopen SDO + NMT

N’hésitez pas à solliciter Hilscher France si besoin.

Cordialement,
Stéphane

netTAP : Protocoles série – ASCII – 3964R – Modbus RTU – Lua

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

netLINK-netTAP-MPI-DVD-2012-03

Bonjour,

Certains chanceux sont sans doute encore en vacances, je profite du calme relatif de cette fin de semaine pour vous glisser un article sur les nouveautés dans la gamme netLINK / netTAP MPI.

Le nouveau DVD contenant documentation et logiciels de configuration est disponible ici. Je ne vais pas détailler le contenu de celui-ci, je l’ai déjà fait pour le précédent et il n’y a pas d’évolution majeure hormis les mises à jour usuelles.

La nouveauté la plus saillante tient dans le netTAP NT 50-MPI, une version du netLINK NL 50-MPI dans un format netTAP, qui se monte sur rail DIN.

NT 50-MPI

Ce produit offre la même fonctionnalité que le NL 50-MPI, le même firmware est d’ailleurs utilisé, et remplace avantageusement le NT 40-MPI.

Comme le NL 50-MPI, il permet donc de raccorder des automates Siemens S7-200®, S7-300® ou S7-400® sur Ethernet.

Pour une présentation de cette fonctionnalité vous pouvez consulter l’article introductif.

On peut dorénavant configurer le netLINK / netTAP MPI également grâce au serveur web intégré.

Un point très intéressant : il est possible de sélectionner un port TCP supplémentaire, le port 1099 restant toujours accessible.

Quand on utilise une connexion distante, – modem RTC, ADSL… – il n’était pas possible jusqu’alors de connecter plusieurs netLINK derrière un routeur sauf à créer un VPN. Un port configurable, cela permet lors de la configuration du routeur d’associer au niveau de NAT (translation d’adresse) un port différent à une adresse IP locale différente.

Le support de NTP est une autre nouveauté. Cela permet de synchroniser l’heure de votre automate ou réseau d’automates sur un serveur de votre choix.

Cordialement,
Stéphane

netTAP : Schneider Electric meets Siemens

Bonjour,

Après avoir présenté d’une manière générale les passerelles Hilscher netTAP, je souhaite vous fournir un exemple emblématique de leur utilisation.

Dans ce qui suit je vais donc m’attacher à démontrer que les mondes Schneider Electric et Siemens ne sont pas si étanches qu’il y parait.

Étant donnée la diffusion des équipements de ces fabricants on conçoit qu’il soit nécessaire de temps à autre de les faire communiquer ensemble. Ce qui n’est pas automatique car les protocoles de communication supportés en standard par ces équipements ne sont pas directement compatibles.

Parmi les protocoles disponibles dans les automates Schneider Electric figure en bonne place Modbus, en version série (Modbus RTU) ou en version Ethernet TCP/IP (Open Modbus TCP).

Récemment Ethernet/IP, protocole développé par le consortium ODVA que Schneider Electric a rejoint, a fait son entrée dans le monde Schneider Electric.

Côté Siemens PROFIBUS est disponible depuis la gamme S5 et PROFINET, son descendant sur Ethernet est présent sur la plupart des CPU récentes.

S’il existe des solutions intégrées comme les coupleurs PROFIBUS pour automates Schneider Electric ou Modbus RTU / TCP pour les automates Siemens, elles ne sont pas nécessairement faciles à mettre en œuvre ou très économiques.

Aussi, la solution passerelle Hilscher netTAP peut-elle tirer son épingle du jeu en proposant toute sorte de combinaison protocolaire adaptée au besoin. Chaque camp conserve sa technologie, outils et licences optionnels ne sont plus requis.

On trouve dans la gamme Hilscher netTAP les solutions suivantes :

  • PROFIBUS / Modbus RTU
  • PROFINET / Modbus RTU
  • PROFIBUS / Modbus TCP
  • PROFINET / Modbus TCP
  • PROFIBUS / Ethernet/IP
  • PROFINET / Ethernet/IP
  • Etc…

L’exemple proposé met en œuvre une combinaison Open Modbus TCP côté Schneider Electric et PROFIBUS DP côté Siemens.

D’un côté nous avons donc une configuration automate Modicon M340 composée de :

  • BMX P34 1000 / CPU 340-10 Modbus
  • BMX NOC 0401 / Coupleur Ethernet/IP et Modbus TCP

De l’autre, une CPU S7 315-2DP Siemens équipée donc d’un port PROFIBUS que nous configurerons en maitre :

  • 6ES7 315-2AG10-0AB0

Au milieu, une passerelle Hilscher netTAP disposant d’une connectivité Ethernet et d’une connectivité PROFIBUS :

  • NT 100-RE-DP

Le programme exemple pour l’automate Schneider Electric M340 contient :

  • la configuration de l’automate avec la fonction IO Scanning montrant les requêtes suivantes :
    • lecture seule de 32 mots (FC3),
    • écriture seule d’un mot (FC6),
    • écriture seule de 64 mots (FC16),
    • lecture de 32 mots / écriture de 32 mots combinées (FC23).
  • une table d’animation présente les variables relatives aux requêtes.

Il est disponible ici.

Le programme de la CPU Siemens S7 contient :

  • la configuration de la CPU, on aura pris soin d’importer le fichier GSD de la passerelle dans le catalogue matériel.
  • le programme principal OB1 utilise les fonctions DPRD_DAT (Read Consistent Data of a Standard DP Slave) et DPWR_DAT (Write Consistent Data to a Standard DP Slave).
  • une table de variables affiche les données des modules définis.

Il est à votre disposition .

Enfin, la configuration de la passerelle :

  • après avoir chargé le firmware qui va bien, NTOMBDPS.NXF, comme évoqué ici,
  • on configure les paramètres côté Open Modbus TCP,
  • puis côté PROFIBUS DP. Ce n’est pas obligatoire mais on a inséré un module PROFIBUS pour chaque requête Modbus TCP, c’est plus cohérent, et on a intégré les états (status) de chaque côté dans les données de l’autre.
  • on termine par l’affectation (le mapping) des données,
  • et on n’oublie pas de transférer la configuration dans le netTAP.

La configuration de la passerelle peut être obtenue en suivant ce lien.

I can help…

Cordialement,
Stéphane