Le sujet a été abordé le mois dernier, mais seulement une solution de contournement à été trouvé.
Aujourd’hui, ayant moi aussi a gérer des valeurs négatives reçu par ModBus, j’ai fait quelques test supplémentaire.
Le contexte : je reçois via ModBus la température de la sonde extérieur de ma PAC. C’est l’hiver, les températures sont négatives.
La doc de mon module ModBus précise que les données transmises respecte la norme CiA301. Une rapide recherche à ce sujet n’a rien donné.
Il semblerait toutefois que les données négatives que je reçois utilises le complément à 2 pour la transmission en binaire.
Lorsque que je paramètre ma variable 16 bits en RAW, je reçois la valeur 65387 :
1111111101101011 (Binaire) = 65387 (décimal) = -149 (décimal signé complément de 2)
La doc précisant que je dois appliquer un gain de 0,01 : il fait -1,49°C à l’extérieur. tout est cohérent jusqu’ici.
Pour faire entrée cette valeur directement sous la bonne forme dans la variable, je paramètres donc ma variable en REAL. et là, ça coince : La variable se met à 32767 au lieu de -149
J’ai l’impression que l’objet ModBus de l’IPX prend simplement la valeur brut (65387) et essaye de la faire rentrer au chausse pied dans la variable REAL. évidemment, ça passe pas et fixe la variable a sont maximum possible (32767).
Est-ce que certain d’entre vous ont réussi à recevoir des valeurs négative via ModBus ?
ai-je raté quelque chose ?
Je suis votre sujet vraiment bien expliqué et détaillé avec attention car j’ai le même genre de donnée sur une PAC et pas d’affichage de température négative.
Bonjour à tous,
Je me réponds à moi même après un échange avec @Kevin_GCE sur le Help Desk.
En fait, et malgré ce qu’on pourrait penser, l’objet MobBus ne s’adapte pas aux variables qu’il alimente.
Les données binaire reçu par Modbus sont simplement transféré en décimale dans les variables.
Valeur Négative :
Pour une valeur sur 8 bits par exemple :
Donnée reçu par Modbus : 11111111
Conversion en décimal = 255
Transfère dans une variable 8 bits RAW = 255 >> OK
Transfère dans une variable 8bits REAL = 128 >> PAS OK, la variable se met a son maximum.
Il me semblerais logique que l’objet ModBus s’adapte à la variable qu’il alimente au moment ou il traite (converti) la donnée binaire qu’il reçoit.
Selon mes recherches, la méthode du complément à 2 est la plus répandu pour transférer des nombre négatif en binaire. Dans mon exemple précédent, si la variable à remplir est paramétré en REAL, l’objet ModBus devrait, à mon avis, la fixer à « -1 ».
La seule méthode que j’ai trouvé est d’utiliser des objets Comparateur et Fonction pour convertir les données. J’avais décrit ma méthode dans ce post :
Précision décimale :
De la même façon, si la variable est paramétré pour avoir une virgule, l’Objet ModBus n’en prend pas compte.
Par exemple, pour une variable 16bits paramétré avec 2 chiffres après la virgule, l’IPX nous informe que la plage disponible est -327,68 <> 327,67.
Si la donnée reçu par ModBus est 0000000110010000, 400 après conversion en décimale, la variable se fixera à 327,67 (son maximum).
Il me semblerait logique, à partir du moment où les donnée reçu en binaire sont forcément entier, que la variable se fixe à 4,00 puisqu’on a paramétré la variable avec 2 chiffre après la virgule.
Tout cela est vrai jusqu’à la version actuelle de l’IPXv5 (5.5.6). @Kevin_GCE m’informe que la demande est passé aux développeurs.
J’espère que @GCE se penchera sur le sujet. Dans l’état c’est un peu compliqué (mais pas impossible) de gérer les données reçu par ModBus. Cela impose un grand nombre d’objet Formule pour les différente conversion à faire. D’autant qu’actuellement, l’IPX ne sait pas correctement faire une division ni une soustraction.
