Bloc système

Communication — TSEND_C / TRCV_C, MB_CLIENT / MB_SERVER

Échanger des données avec un équipement tiers — un autre automate, un PC, une passerelle MODBUS — sans passer par le bus de terrain cyclique décrit ailleurs sur ce site.

TSEND_C / TRCV_CMB_CLIENT / MB_SERVER

À quoi ça sert

Tous les guides IO-Link et PROFINET de ce site portent sur des données process cycliques, échangées automatiquement à chaque cycle bus via un GSDML. Ces blocs couvrent un besoin différent : une communication point à point, souvent aperiodique, déclenchée par le programme lui-même — typiquement vers un PC de supervision ou un équipement qui ne parle pas PROFINET.

TSEND_C / TRCV_C — Communication ouverte S7 (TCP, ISO-on-TCP, UDP)

TSEND_C envoie des données, TRCV_C en reçoit, sur une connexion TCP/IP ouverte qu'ils établissent et surveillent eux-mêmes (le « _C » signifie « avec gestion de connexion intégrée » — pas besoin d'un bloc de connexion séparé comme sur les anciennes versions TSEND/TRCV). Chaque extrémité de la liaison doit avoir un rôle cohérent : l'une active (qui initie la connexion), l'autre passive (qui l'accepte).

Paramètre	Type	Rôle
CONNECT	structure	Paramètres de connexion — IP distante, port, rôle actif/passif
REQ / EN_R	BOOL	Déclenche l'envoi / active la réception en continu
DATA	variable	Zone mémoire à envoyer ou à recevoir
DONE / NDR	BOOL	VRAI un cycle quand l'envoi / la réception a réussi
BUSY	BOOL	Opération en cours
ERROR	BOOL	Échec — voir STATUS
STATUS	WORD	Code d'erreur détaillé

Quand l’utiliserÉchanger des données libres avec un PC de supervision, un autre automate S7, ou tout équipement qui parle TCP ouvert — situation qui sort du monde IODD/GSDML couvert par le reste de ce site.

PiègeUn rôle actif/passif mal apparié entre les deux extrémités (les deux configurées en actif, ou les deux en passif) ne remonte pas toujours une erreur explicite côté programme : la connexion ne s'établit tout simplement jamais, et STATUS reste souvent sur un code générique de timeout.

MB_CLIENT / MB_SERVER — MODBUS TCP natif

Implémentation MODBUS TCP directement intégrée aux CPU S7-1200/S7-1500 (pas de module matériel dédié nécessaire pour la variante TCP). MB_CLIENT interroge un serveur MODBUS distant, MB_SERVER fait de la CPU un serveur MODBUS interrogeable par un tiers.

Paramètre	Type	Rôle
REQ	BOOL	Déclenche une requête (MB_CLIENT)
MB_MODE	USINT	Fonction MODBUS demandée — lecture ou écriture, bits ou registres
MB_DATA_ADDR	UDINT	Adresse de départ dans l'espace MODBUS de l'équipement distant
MB_DATA_LEN	UINT	Nombre de bits ou de registres concernés
DATA_PTR	variable	Zone locale source ou destination des données
DONE / BUSY / ERROR / STATUS	BOOL / WORD	Mêmes principes que les blocs de communication ouverte

Quand l’utiliserPiloter ou lire un équipement MODBUS TCP tiers — variateur, centrale de mesure, passerelle d'un fabricant qui ne fournit pas de GSDML PROFINET.

PiègeMB_DATA_ADDR encode à la fois le type de zone MODBUS et l'adresse. La confusion la plus fréquente vient de la documentation constructeur : certaines notices indexent leurs registres à partir de 1 (convention historique MODBUS), alors que le protocole réel les adresse à partir de 0 — un décalage d'une adresse qui fait lire ou écrire le mauvais registre sans erreur visible.

Programmation

Réseau 1 — Requête de lecture MODBUS TCP
              ┌──────────────────┐
              │     MB_CLIENT     │
              │    "client"       │
──────────────┤REQ           DONE ├──────────────( lectureOK )
 lancerLecture│                   │
         0────┤MB_MODE      ERROR ├──────────────( enErreur )
         0────┤MB_DATA_ADDR       │
         2────┤MB_DATA_LEN        │
  registres────┤MB_DATA_PTR        │
              └──────────────────┘

// Un front sur lancerLecture déclenche une tentative — pas une
// lecture continue. Pour interroger en boucle, relancer REQ sur
// une temporisation (voir la page « Temporisateurs »).

// Lecture de 2 registres de maintien (holding registers) sur un
// équipement MODBUS TCP tiers, à l'adresse MODBUS 0 (souvent notée
// "40001" côté documentation constructeur — décalage de 1 à vérifier).

FUNCTION_BLOCK "FB_LectureModbus"
VAR_INPUT
    lancerLecture : BOOL;
END_VAR
VAR_OUTPUT
    lectureOK   : BOOL;
    enErreur    : BOOL;
END_VAR
VAR
    client      : "MB_CLIENT";
    registres   : ARRAY[0..1] OF WORD;
END_VAR

BEGIN
    #client(REQ := #lancerLecture,
            MB_MODE := 0,              // 0 = lecture
            MB_DATA_ADDR := 0,          // premier registre
            MB_DATA_LEN := 2,
            MB_DATA_PTR := #registres,
            DONE => #lectureOK,
            ERROR => #enErreur);
END_FUNCTION_BLOCK

CONT ou SCL ?La mise à l’échelle est plus lisible en SCL. L’usage courant est d’écrire ce bloc en SCL et de l’appeler depuis le programme CONT. La version CONT existe pour les sites où le SCL n’est pas autorisé.

Code non validé sur installationGénéré depuis la documentation. À confirmer sur matériel avant mise en production.

Les pièges

Ces blocs sont asynchrones, pas des lectures instantanées	Un front sur REQ ne déclenche qu'une tentative ponctuelle. Le programme doit surveiller DONE/ERROR et relancer l'appel (souvent via un temporisateur ou un séquenceur) tant que l'échange n'est pas terminé — contrairement aux données cycliques PROFINET, disponibles en permanence sans appel explicite.
Pas de diagnostic automatique comme sur un GSDML	Un équipement MODBUS ou en communication ouverte ne remonte pas de bits de diagnostic standardisés comme le fait un maître IO-Link ou un GSDML PROFINET. Toute la détection de défaut (équipement déconnecté, valeur hors plage) doit être reconstruite dans le programme à partir de STATUS et d'une éventuelle temporisation de timeout.

Sources

Documentation TIA Portal — instructions de communication ouverte S7 et MODBUS TCP natif (SIMATIC S7-1200/S7-1500), aide en ligne Siemens.