Bonjour,

Quel que soit le bus de terrain utilisé on retrouve des principes communs.

La communication a pour but d’échanger différents types de données, des données procédé, des données de configuration ou de paramétrage, des données d’alarme ou de diagnostic, etc.

Selon le type de données, certaines doivent être échangées cycliquement, les données procédé, comme les consignes ou les commandes, les mesures et les états, les autres seront échangées suivant la nécessité.

Ainsi des données plus ou moins structurées, – table de registres pour Modbus, enregistrements pour PROFIBUS ou PROFINET, dictionnaire d’objets pour CANopen, EtherCAT, POWERLINK, SERCOS, Ethernet/IP… – sont accessibles en lecture ou écriture selon deux mécanismes distincts, l’un cyclique pour lequel il est nécessaire de garantir un temps de cycle borné et répétable, l’autre acyclique grâce à des méthodes implémentées sous la forme de requêtes.

J’ai déjà présenté la passerelle au format DIL32 Hilscher netIC. Cette passerelle permet donc d’interfacer un équipement nativement Modbus RTU avec les principaux bus de terrain du marché, qu’ils soient classiques ou Ethernet Temps Réel.

Vous pouvez vous procurer la documentation la plus importante pour la compréhension de cet article ici :
netIC – Real-Time Ethernet and Fieldbus Gateways User Manual

Si l’on examine le modèle de données implémenté dans les firmwares standard du netIC, on y remarque les zones de données cycliques ou image procédé et les deux boites aux lettres qui permettent de poster les requêtes acycliques.

Ces requêtes acycliques sont fonction de la pile de protocole mise en œuvre et sont documentées dans le manuel correspondant.

Le dictionnaire d’objet standard implémenté par défaut dans les piles de protocole CANopen, EtherCAT, POWERLINK, SERCOS, Ethernet/IP, etc. convient dans la plupart des cas, mais il peut s’avérer nécessaire de l’étendre afin de rajouter des objets spécifiques à l’application ou à un profil d’équipement, ce qui correspond à une classe d’équipements. C’est possible via la messagerie Hilscher. Vous disposez des services nécessaires pour créer ces objets, les configurer pour recevoir les indications de lecture et écriture et répondre à ces indications.

Bien sûr, cela implique de gérer tous ces messages du côté Hôte, ce qui peut s’avérer plus ou moins délicat si l’hôte ne dispose pas d’une capacité de traitement importante ou si l’on veut gérer plusieurs protocoles avec un même firmware.

Aussi il peut être plus judicieux de réaliser un firmware spécifique gérant ce dictionnaire d’objet en interne. Il suffit alors de mettre en place une table Modbus adaptée à votre application que l’hôte vient interroger à son rythme.

Vous pouvez confier à Hilscher France votre besoin et obtenir une offre raisonnable pour ce service. Que cette gestion soit réalisée côté Hôte ou côté netIC, il faudra réaliser le développement correspondant.

La solution « développement spécifique netIC » est sans aucun doute un choix à étudier car il dispose d’avantages certains comme une meilleure séparation de la fonction communication .

Pour terminer et illustrer mon propos, nous avons réalisé pour l’un de nos clients un firmware spécifique implémentant le profil « EtherCAT Semiconductor Device Profile 5003:2070 – Turbo Pump ».

Ainsi, l’impact de l’intégration de ce profil sur le code de son application est minimal et le firmware du netIC peut évoluer indépendamment comme par exemple pour intégrer une nouvelle version de la pile EtherCAT.

Cordialement,
Stéphane