Re: Modbusdoctor
Posté : 19 sept. 2024, 14:28
La trame de requête est composée de ces octets 0 0 0 0 0 6 1 3 0 135 0 2 avec ce découpage :
0 0 = numéro de transaction (non utilisé car on ne traite qu'une requête à la fois)
0 0 = identifiant de protocole (toujours égal à 0 en Modbus TCP)
0 6 = nombre d'octets qui suivent
1 = Unit ID (adresse de l'esclave Modbus dans le cas d'une passerelle)
3 = code fonction (ici, lecture de registres de maintien)
0 135 = adresse du registre
0 2 = nombre de registres consécutifs
et la trame de réponse 0 0 0 0 0 3 1 131 2 :
0 0 = numéro de transaction
0 0 = identifiant de protocole
0 3 = nombre d'octets qui suivent
1 = Unit ID
131 = code fonction en erreur (= code fonction + 128)
2 = code d'erreur (ici, adresse de données invalide)
On peut demander simultanément plusieurs variables au serveur OPC mais celui-ci va générer autant de requêtes Modbus qu'il y a de variables. Il a forcément été paramétré pour fonctionner ainsi. Pour le client OPC c'est transparent.
Vous vous faites des idées à propos des différences entre le serveur OPC et le driver Modbus de Panorama.
Le protocole de communication OPC classique (appelée maintenant OPC DA) c'est une communication entre logiciels. Mais le serveur OPC utilise son driver Modbus pour communiquer avec la chaudière.
Si Panorama a son propre driver Modbus, le traitement de l'information est a priori plus direct.
Au lieu d'avoir :
supervision <---OPC---> serveur OPC <---Modbus---> chaudière
vous aurez :
supervision <---Modbus---> chaudière
Là où il faut faire attention, c'est aux possiblités de paramétrage du serveur Modbus pour être certain d'être compatible avec le matériel.
Notamment il faut vérifier que le driver Modbus de Panorama permet de forcer la lecture d'un seul registre par requête.
0 0 = numéro de transaction (non utilisé car on ne traite qu'une requête à la fois)
0 0 = identifiant de protocole (toujours égal à 0 en Modbus TCP)
0 6 = nombre d'octets qui suivent
1 = Unit ID (adresse de l'esclave Modbus dans le cas d'une passerelle)
3 = code fonction (ici, lecture de registres de maintien)
0 135 = adresse du registre
0 2 = nombre de registres consécutifs
et la trame de réponse 0 0 0 0 0 3 1 131 2 :
0 0 = numéro de transaction
0 0 = identifiant de protocole
0 3 = nombre d'octets qui suivent
1 = Unit ID
131 = code fonction en erreur (= code fonction + 128)
2 = code d'erreur (ici, adresse de données invalide)
On peut demander simultanément plusieurs variables au serveur OPC mais celui-ci va générer autant de requêtes Modbus qu'il y a de variables. Il a forcément été paramétré pour fonctionner ainsi. Pour le client OPC c'est transparent.
Vous vous faites des idées à propos des différences entre le serveur OPC et le driver Modbus de Panorama.
Le protocole de communication OPC classique (appelée maintenant OPC DA) c'est une communication entre logiciels. Mais le serveur OPC utilise son driver Modbus pour communiquer avec la chaudière.
Si Panorama a son propre driver Modbus, le traitement de l'information est a priori plus direct.
Au lieu d'avoir :
supervision <---OPC---> serveur OPC <---Modbus---> chaudière
vous aurez :
supervision <---Modbus---> chaudière
Là où il faut faire attention, c'est aux possiblités de paramétrage du serveur Modbus pour être certain d'être compatible avec le matériel.
Notamment il faut vérifier que le driver Modbus de Panorama permet de forcer la lecture d'un seul registre par requête.