Finalement, je me rappelle qu’avec Open ModSim j’avais essayé 2 fois mais je ne voyais absolument aucun trafic. Dans tous les cas j’essayerai encore !
En lançant depuis le terminal j’obtiens enfin une piste d’erreur:
Il faudrait peut-être tester avec d’autres logiciels pour voir si t’as la même erreur (histoire que ce soit pas un bug). J’ai testé aussi ModRSsim2 qui a fonctionné chez moi.
Sinon c’est qu’on est sur une mauvaise piste avec le modbus via USB
ModRSsim2 avec une valeur mise sur 401057 qui correspond au holding 1056 :
Le truc c’est que je ne vois nulle part dans le logiciel pour configurer l’adresse sur 2 au lieu de 1.
Effectivement j’avais pas fait attention qu’on ne pouvait pas changer l’id de l’esclave vu que c’est 1 pour la télécommande… ça ne peut pas marcher du coup 
J’ai essayé Modbus Slave de nouveau, voici ce que j’obtiens en boucle :
Rx:000570-02 03 00 08 00 02 04 3A 30
Tx:000571-02 83 02 30 F1
Rx:000572-02 03 00 08 00 02 04 3A 30
Tx:000573-02 83 02 30 F1
Rx:000574-02 03 00 08 00 02 04 3A 30
Tx:000575-02 83 02 30 F1
Rx:000576-02 03 00 08 00 02 04 3A 30
Tx:000577-02 83 02 30 F1
Rx:000578-02 03 00 08 00 02 04 3A 30
Tx:000579-02 83 02 30 F1
Rx:000580-02 03 00 08 00 02 04 3A 30
Tx:000581-02 83 02 30 F1
Rx:000582-02 03 00 08 00 02 04 3A 30
Tx:000583-02 83 02 30 F1
Rx:000584-02 03 00 08 00 02 04 3A 30
Tx:000585-02 83 02 30 F1
Rx:000586-02 03 04 20 00 01 02 42 A2
Tx:000587-02 03 02 04 D2 7E D9
Mis dans Online Modbus / Analyzer / Simulator / Parser/ ça donne :
Pour le 1er RX:
Pour le 2ème RX:
Si je mets en ASCII je n’ai que la 2ème.
T’as essayé de mettre des valeurs au hasard dans ces registres j’imagine.
Le problème c’est qu’on ne sait pas ce qu’attend la passerelle pour aller plus loin.
Mais quand je vois ça je me dis que ça ne peut être que du modbus, c’est pas possible, un truc doit nous manquer pour que le T.One réponde.
Il n’y a pas moyen de sniffer l’USB avant le décodage par le driver série pour voir si ça ressemble à ce que voit @yanoooou une fois branché sur la carte mère ?
Sur Modbus Slave tu peux passer en mode incrémental à chaque lecture, ça peut permettre de tomber sur une valeur qui plait à la passerelle au bout d’un moment.
La capture qModbus m’embrouille car le slave ID est 4 et pas 2, alors que la function code est 32 et pas 3.
Oui j’ai essayé plusieurs valeurs (1234), j’essayerai l’incrémental mais demain car j’ai éteint le PC Windows.
C’est ce que j’étais en train de me dire, il dit n’importe quoi car quand tu regardes les trames « raw » au dessus ça correspond bien à ce que tu as décodé avec Online Modbus / Analyzer / Simulator / Parser/
En fait il ignore les 2 premiers octets, il commence à interpréter au 3e
Quand j’analyse la requête envoyée par la passerelle il y a un truc qui cloche.
02 03 04 20 00 01 02 42 A2
| Slave address | Function Code | Data | CRC |
|---|---|---|---|
| 1 octet | 1 octet | 0 – 252 octets | 2 octets: 1 CRC low byte and 1 CRC high byte |
| Adresse de l’esclave | holding registers | Adresse 1er registre - Nombre de registres à lire | CRC |
| 1 octet | 03 | 2 octets-2 octets | 2 octets |
| 02 | 03 | 04 20-00 01 | 02 42 A2 |
On a 1 octet en trop, d’où le checksum qui n’est pas bon quand tu regardes avec Online Modbus / Analyzer / Simulator / Parser/
Mais le checksum est bon avec Serial Port Monitor car il compte l’octet en trop pour calculer le checksum et obtient bien 0x42A2 dans ton post, ce qui signifie que le calcul est le même qu’avec Modbus.
Et c’est pour ça que Qmodbus dit n’importe quoi car il se désaligne dans la trame, il doit partir de la fin et ignore le début.
C’est bizarre cette trame envoyée, c’est presque du Modbus mais ça correspond pas à 100%. On en revient à ce que disait @yanoooou .
C’est pour ça que t’arrives pas à dialoguer avec le T.One, il faudrait envoyer la même chose avec une lib série plus bas niveau j’imagine.
Et il faudrait comprendre à quoi correspond cet octet en plus pour pouvoir accéder à tous les registres.
Selon npulse (l’outil en ligne), pour un read holding du registre 1056 sur le slave 2, la checksum devrait être 84C3, que ça soit sur l’affichage de la checksum corrigée comme sur la capture plus haut, ou sur la commande qu’il calcule en donnant les paramètres:
Selon https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/aussi :
Ni la trame de @yanoooou ni la mienne ne sont bonnes. La mienne est encore pire car comme tu dis @djtef il y a un octet en trop pour qu’elle soit même au format Modbus, sans même parler de CRC.
J’avais chopé des trames avec Wireshark, je vais réessayer pour voir.
Enregistrement Wireshark après avoir connecté la passerelle et lancé un Open ModSim avec une valeur sur 1056 au slave 2. Aucune idée de comment l’exploiter par contre…
En fait le CRC est bon si tu comptabilises l’octet en trop. Sur les 2 trames envoyées par la passerelle, c’est une trame modbus + un 7e octet spécifique constructeur.
Logiquement si t’envoies ces deux trames, le T. One devrait répondre, mais impossible de les envoyer avec un logiciel ou librairie modbus, il faut l’envoyer brute au niveau port série.
Si la passerelle envoie d’autres trames on pourra peut-être comprendre l’intérêt de cet octet.
D’ailleurs si le T. One répond aussi avec une trame modbus modifiée, on ne pourra pas non plus utiliser de logiciels style Modbus Slave qui répondent avec des vraies trames modbus.
OK, compris pour les CRC, merci !
Le format ne répond donc pas à une request 03. Mais en fait il correspond à une response à une request 03 ! Copié-collé dans npulse dans la partie de droite, la trame a la bonne CRC:
De plus quand on regarde le format attendu de la response à la request 03 sur Modbus Protocol, on se rend compte que c’est ce format.
On a bien correspondance, il n’y a plus un octet de trop :
Slave Address: 02
Function: 03
Byte Count: 04
Data Hi: 20
Data Lo: 00
Data Hi: 01
Data Lo: 02
Error Check Lo: 42
Error Check Hi: A2
A rapprocher au fait que j’obtenais des réponses sans faire de requêtes, quand je ne cochais pas « Monitor slave device » : Aldes T.One AIR / AquaAIR - #146 par guix77
Incompréhensible en effet.
Autre chose sinon, sur mon script python sur le Zero W j’ai ajouté le logging. J’obtiens:
20:08:45 DEBUG transaction:130 Current transaction state - IDLE
20:08:45 DEBUG transaction:134 Running transaction 1
20:08:45 DEBUG transaction:291 SEND: 0x2 0x3 0x0 0x1 0x0 0x1 0xd5 0xf9
20:08:45 DEBUG base:199 New Transaction state "SENDING"
J’ai changé l’appel en read holding 1 sur le slave 2 pour cet exemple mais peut importe ce que je fasse (1056 ou tout autre sur slave 2), ça reste bloqué, alors que ça devrait passer à :
pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
Avec le Zero W branché au PC ça marche. J’ai essayé de changer tous les paramètres notamment de délai, timeout, d’ajouter des pauses etc.
Effectivement 02 03 04 20 00 01 02 42 A2 pourrait être une trame de réponse modbus qui répondrait 4 octets 0x20000102, mais ce n’est plus vraiment le protocole modbus car c’est censé répondre à une requête.
Par contre pour la 2e trame 02 03 00 08 00 02 04 3A 30 ça ne correspond pas à une réponse car sinon ça signifierait répondre 0 octets avec une donnée de 4 octets 0x08000204.
Je reste persuadé que c’est normal que tu n’arrives pas à envoyer de requête tant que t’enverras pas la trame exacte de la passerelle qui n’est pas une requête modbus.
Vu ce qu’on voit je pense qu’ils ont modifié le protocole modbus, pour en avoir le coeur net il faut arriver à faire répondre le T.One.
Ce qui reste un mystère c’est la trame 02 03 04 00 01 02 0B a2 de @yanoooou qui elle a le bon nombre d’octets mais pas le bon CRC, je ne sais pas comment il l’a obtenue car ça ne correspond pas à ce qu’envoie la passerelle au démarrage quand elle est branchée au PC.
Cette trame est récupéré lorsque l’on branche la passerelle sur un port USB d’un PC puis en ouvrant un moniteur RS232 sur le port com.