DocumentationProblèmes connus du WB-MRM2-mini
ERRMODBUS001 : l’appareil répond à l’adresse 0xFD
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.21.1.
Description
Les appareils Fast Modbus peuvent perturber des appareils tiers du même bus si ceux-ci utilisent des commandes spéciales commençant par 0xFD.
Cause et détails
Fast Modbus réserve 0xFD aux commandes spéciales en diffusion. Si une requête tierce commence par 0xFD mais utilise une commande extérieure à Fast Modbus, les appareils Wiren Board concernés répondent MODBUS_ERR_ILLEGAL_FUNCTION, perturbant l’autre échange. Le pilote du bus traite à tort le paquet comme du trafic Modbus ordinaire.
Solution de contournement
Évitez de partager un bus entre les appareils Wiren Board concernés et des appareils tiers.
Résolution
Corrigé dans le micrologiciel 1.21.1.
ERRMODBUS002 : réponse incorrecte à la commande de détection 0x46
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.20.4.
Description
Fast Modbus utilisait initialement la fonction 0x60, remplacée ensuite par 0x46 parce que 0x60 se trouvait dans une plage réservée. La rétrocompatibilité conservait les deux codes de requête, mais l’appareil répondait toujours avec 0x60. La correction fait répondre avec la même fonction que celle de la requête : 0x46 ou 0x60.
Mesure corrective
Mettez à jour vers le micrologiciel 1.20.4.
Résolution
Corrigé dans le micrologiciel 1.20.4.
ERRMODBUS003 : comportement inattendu lors de l’écriture de valeurs invalides dans certains registres
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.21.6.
Description
Lorsque des valeurs dans la plage [256 ... 65535] sont écrites dans certains registres, les 8 bits de poids fort sont supprimés et le micrologiciel reçoit la valeur modulo 256. Par exemple, écrire 257 a le même effet qu’écrire 1.
Le registre d’adresse de l’appareil (128) fait partie des registres concernés.
Tous les registres fonctionnent comme prévu dans leurs plages documentées. Le problème survient lors de l’écriture de valeurs invalides supérieures à 255.
Mesure corrective
Mettez à jour vers le micrologiciel 1.21.6.
Résolution
Corrigé dans le micrologiciel 1.21.6.
ERRMODBUS004 : réponses incorrectes à champs de bits
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.20.4.
Description
Les réponses contenant des champs de bits, notamment les lectures de bobines/entrées discrètes et la gestion des événements, pouvaient contenir des bits de poids fort incorrects.
Mesure corrective
Mettez à jour vers le micrologiciel 1.20.4.
Résolution
Corrigé dans le micrologiciel 1.20.4.
ERRMODBUS006 : réponses aux requêtes avec parité incorrecte
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.21.4.
Description
L’appareil répondait aux requêtes avec parité incorrecte au lieu de les ignorer.
Mesure corrective
Mettez à jour vers le micrologiciel 1.21.4.
Résolution
Corrigé dans le micrologiciel 1.21.4.
ERRMODBUS007 : perte d’événements lorsque deux appareils émettent simultanément sur un même bus
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.26.4.
Description
Lorsque deux appareils d’un même bus ont simultanément des événements en attente, l’un d’eux peut transmettre un paquet d’événements incomplet.
Cause et détails
Dans Fast Modbus, le maître demande les événements. Tous les appareils ayant des événements en attente participent à l’arbitrage ; le gagnant répond et les autres attendent la requête suivante.
Un événement généré attend sa transmission. Après que l’appareil a placé sa trame sur le bus, l’événement est marqué comme envoyé. Le prochain acquittement du maître destiné à cet appareil retire les événements envoyés de sa file. C’est le mécanisme normal d’acquittement.
Le défaut marquait les événements comme envoyés trop tôt, dès la réception de la requête d’événements, avant la fin de l’arbitrage. Si l’appareil gagnait l’arbitrage, le fonctionnement était normal. S’il le perdait, aucun paquet n’était transmis, mais ses événements étaient déjà marqués comme envoyés. Un acquittement ultérieur destiné à cet appareil acquittait aussi ces événements non envoyés, les retirant de la file avant qu’ils n’atteignent le maître.
La valeur dans l’interface web n’est pas mise à jour et aucun message MQTT n’est publié, alors que les registres de l’appareil restent corrects. La notification de changement est perdue.
Par exemple, si des entrées de deux modules à relais du même bus se ferment simultanément, un module peut se mettre à jour correctement dans l’interface web tandis que l’autre perd certains événements et apparaît encore dans son état précédent malgré la commutation physique.
Solution de contournement
Désactivez temporairement le fonctionnement par événements pour les registres concernés en réglant sporadic sur false dans le modèle d’appareil. Les registres seront alors interrogés à l’intervalle configuré.
Résolution
Corrigé dans le micrologiciel 1.26.4.
ERRMODBUS008 : comportement inattendu avec de longues trames de requête
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.26.5.
Description
La réception d’une trame de plus de 265 octets, longueur maximale d’une trame Fast Modbus, peut bloquer et redémarrer l’appareil ; les paramètres peuvent aussi être perdus dans certains cas.
Cause et détails
L’algorithme de réception ne gérait pas les requêtes invalides trop longues, provoquant un débordement de tampon et une corruption de la mémoire adjacente. L’appareil se bloque et le chien de garde le redémarre. Des trames très longues, au-delà d’environ 500 octets, peuvent aussi corrompre les paramètres, provoquant un redémarrage avec les paramètres de communication par défaut : 9600 8N2, adresse 1.
Solution de contournement
- N’envoyez pas de requêtes dépassant les limites de Modbus RTU ou Fast Modbus (265 octets pour Fast Modbus).
- Ne raccordez pas l’appareil à un bus transportant du trafic autre que Modbus ou des messages de plus de 265 octets.
Résolution
Corrigé dans le micrologiciel 1.26.5.
ERRMODBUS009 : comportement inattendu lors de lectures près de l’adresse 0xFFFF en mode de lecture continue
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.26.5.
Description
Lorsque le mode de lecture continue est activé, une plage de lecture atteignant ou franchissant l’adresse 0xFFFF peut bloquer et redémarrer l’appareil.
Cause et détails
L’algorithme de lecture continue ne gérait pas le débordement du compteur d’adresses de registres sur 16 bits. La lecture de 0xFFFF faisait reboucler le compteur et provoquait une boucle infinie, suivie d’une réinitialisation par le chien de garde.
Solution de contournement
Lorsque le mode de lecture continue est activé, ne lisez pas de plage comprenant 0xFFFF. Les appareils Wiren Board n’ont aucun registre implémenté à cette adresse.
Résolution
Corrigé dans le micrologiciel 1.26.5.
ERRMODBUS010 : validation incorrecte des requêtes et traitement incorrect des requêtes invalides
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.26.5.
Description
L’appareil peut accepter ou mal traiter des requêtes dont la syntaxe est invalide, renvoyer un code d’exception incorrect ou imposer une limite incorrecte de nombre de registres.
Cause et détails
L’algorithme de validation gère incorrectement les cas suivants :
1) Les requêtes de lecture de zéro registre réussissent avec une réponse vide contenant uniquement un en-tête et un CRC. Modbus exige l’exception 0x03 (ILLEGAL_DATA_VALUE).
2) Une limite unique de 125 registres est appliquée à toutes les fonctions de lecture/écriture ; son dépassement renvoie 0x02 (ILLEGAL_DATA_ADDRESS). Modbus spécifie au contraire des limites de 2000 bits pour les lectures de bits, de 125 registres pour les lectures d’entrée/de maintien, de 1968 bobines pour les écritures multiples de bobines et de 123 registres de maintien pour les écritures multiples de registres. Le dépassement de la limite applicable devrait renvoyer 0x03 (ILLEGAL_DATA_VALUE).
3) Byte Count n’est pas validé pour les écritures multiples (0x0F et 0x10). Une différence entre Byte Count et le nombre de registres devrait renvoyer 0x03 (ILLEGAL_DATA_VALUE).
4) Les écritures d’une bobine ne valident pas la valeur et utilisent le bit de poids fort de la valeur de requête. Modbus n’autorise que 0x0000 et 0xFF00 ; toutes les autres valeurs devraient renvoyer 0x03 (ILLEGAL_DATA_VALUE).
5) Les requêtes de structure invalide avec un CRC valide, comme les requêtes trop longues, sont traitées normalement. Ces requêtes mal formées devraient au contraire être ignorées.
6) Des trames de structure valide mais trop longues, de 257–265 octets, sont traitées. Les trames Modbus standard de plus de 256 octets sont invalides et devraient être ignorées.
Solution de contournement
N’envoyez que des requêtes de structure correcte conformes à la spécification Modbus.
Résolution
Corrigé dans le micrologiciel 1.26.5.
ERRMODBUS011 : traitement incorrect des requêtes invalides de configuration d’événements Fast Modbus
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.26.5.
Description
Une commande de configuration d’événements (EVENT_CTRL, cmd=0x46, sub_cmd=0x18) comportant des champs de longueur invalides peut configurer incorrectement les notifications d’événements et produire une réponse de longueur imprévisible.
Cause et détails
Le gestionnaire de configuration d’événements Fast Modbus ne validait pas les champs de taille et de longueur des blocs de données internes. Des longueurs invalides peuvent l’amener à traiter des données au-delà de la trame reçue, avec pour conséquences :
1) Des paramètres incorrects de notification d’événements, notamment des changements spontanés de priorités ou de masques d’événements.
2) Une réponse de configuration d’événements de longueur imprévisible.
Solution de contournement
N’envoyez que des commandes Fast Modbus valides et conformes à sa spécification.
Résolution
Corrigé dans le micrologiciel 1.26.5.
ERRMODBUS012 : l’appareil cesse de transmettre des événements Fast Modbus
Appareils concernés
WB-MR* avec un micrologiciel antérieur à 1.27.0.
Description
L’appareil cesse d’envoyer des événements Fast Modbus et signale continuellement qu’il n’y a aucun événement (sub_cmd=0x12) en réponse aux requêtes d’événements (cmd=0x46, sub_cmd=0x10). Les commandes de l’interface web se figent alors que les registres de l’appareil continuent de changer.
Plus une valeur avec événements activés change souvent, plus le problème survient tôt. Lors d’essais avec un anti-rebond de 1 ms, la transmission d’événements s’est arrêtée après 23 minutes à 200 impulsions d’entrée par seconde et après plusieurs heures à 100 impulsions par seconde. Le problème peut aussi survenir avec des changements peu fréquents, mais c’est beaucoup moins probable. Le pilote ne journalise aucune erreur, car l’appareil indique valablement qu’aucun événement n’est en attente.
Pour le diagnostic, lisez directement le registre sans événements, par exemple le compteur d’impulsions d’entrée :
modbus_client_rpc -mrtu -pnone -s2 /dev/ttyRS485-1 -b115200 -a1 -r32 -t0x03
Si le registre augmente mais que la commande de l’interface web reste inchangée, ce problème est présent.
Cause et détails
Le compteur d’événements non envoyés est partagé entre un gestionnaire d’interruptions et la boucle principale sans synchronisation correcte. Une interruption pendant une opération de lecture-modification-écriture de la boucle principale peut faire perdre un incrément du compteur. Cet incrément ne peut pas être récupéré, car il n’a lieu qu’à la première insertion d’un événement dans la file. L’appareil croit alors n’avoir rien à envoyer malgré les événements en attente.
Cet état persiste jusqu’au redémarrage de l’appareil. Un autre événement peut temporairement vider la file accumulée et mettre à jour la commande une fois, mais l’incohérence réapparaît immédiatement. Une installation sans autres changements semble donc figée.
La probabilité augmente avec la fréquence des événements et la charge du bus, car les accès simultanés deviennent plus probables.
Solution de contournement
Redémarrer l’appareil rétablit les événements jusqu’à la réapparition du problème. Redémarrer le contrôleur ou relancer wb-mqtt-serial n’aide pas : l’état est conservé dans l’appareil, et reconfigurer les événements ne le réinitialise pas.
Réduisez la probabilité en augmentant le temps d’anti-rebond des entrées ou en désactivant les événements pour les registres qui changent souvent. Jusqu’à la mise à jour du micrologiciel, lisez les valeurs directement dans les registres.
Résolution
Corrigé dans le micrologiciel 1.27.0.
ERRMR01 : les registres d’entrées numériques contiennent 0 après démarrage au lieu de l’état réel
Appareils concernés
WB-MR (sauf WB-MRPS6) et WB-MWAC avec les micrologiciels 1.9.x ou 1.10.x
Description
Au démarrage, les entrées ne sont pas lues et leurs registres numériques contiennent 0 même pour une entrée active. Ils deviennent corrects après la première transition de l’entrée.
Résolution
Corrigé dans 1.11.1.
Avec la correction, les états des entrées au démarrage sont écrits dans les registres. Les sorties ne réagissent pas : elles restent désactivées ou restaurent leur état sauvegardé si le registre 6 l’autorise. La matrice d’affectation n’est pas traitée au démarrage, sauf en mode d’entrée 5 (capteurs de fuite avec répétition toutes les 20 minutes). Les autres actions surviennent aux changements ultérieurs des entrées.
ERRMR02 : Safety Mode désactive les relais indépendamment des communications Modbus
Appareils concernés
Tous les WB-MR avec les micrologiciels 1.15.0 ou 1.15.1
Description
Écrire une valeur non nulle dans le registre 8 lance une temporisation qui désactive tous les relais à son expiration. Les paquets Modbus reçus ne relancent pas la temporisation.
Résolution
Corrigé dans 1.15.2.
La temporisation redémarre désormais après chaque paquet Modbus reçu.
ERRMR03 : l’appareil se bloque après environ six semaines de fonctionnement continu
Appareils concernés
Tous les WB-MR avec les micrologiciels 1.15.0, 1.15.1 ou 1.15.2
Description
Après environ six semaines, l’appareil cesse d’exécuter les commandes et de mettre à jour les registres, mais continue de répondre par Modbus.
Résolution
Corrigé dans 1.15.3
ERRMR04 : mesures incorrectes de température et de tension d’alimentation du microcontrôleur
Appareils concernés
Matériel WB-MR à base de GD32 avec le micrologiciel 1.16.0
Résolution
Corrigé dans 1.16.1
ERRMR05 : surveillance incorrecte de la tension d’alimentation
Appareils concernés
Tous les WB-MR avec le micrologiciel 1.16.0
Description
Le CAN échantillonne la tension d’alimentation toutes les 100 ms. Si l’état d’un relais change juste avant une coupure, les condensateurs peuvent se décharger avant que l’échantillon suivant ne détecte la perte, et le nouvel état n’est pas sauvegardé.
Résolution
La tension d’alimentation est désormais mesurée en continu.
Corrigé dans 1.16.1
ERRMR06 : les mesures de fréquence tombent par intermittence à zéro
Appareils concernés
Tous les WB-MR avec les micrologiciels 1.15.0 à 1.16.2 inclus
Description
En mode mesure de fréquence, les valeurs tombent parfois à zéro lorsque l’entrée est proche de 1 kHz.
Résolution
Corrigé dans 1.16.3
ERRMR07 : interrogation Modbus instable
Appareils concernés
Tous les WB-MR avec un micrologiciel jusqu’à 1.16.2 inclus
Description
L’appareil cesse par intermittence de répondre aux commandes Modbus. Ce phénomène a été observé à 115200 bauds.
Résolution
Corrigé dans 1.16.3
ERRMR08 : des relais activés se désactivent inopinément lorsque la tension d’alimentation du module baisse
Appareils concernés
Tous les WB-MR et WB-MWAC avec un micrologiciel jusqu’à 1.17.1 inclus
Description
Défauts observés :
- Lorsque la tension d’alimentation baisse, par exemple lors du passage d’une alimentation principale de 24 V à un secours de 12 V, des relais activés peuvent se désactiver inopinément.
- Lorsqu’il est alimenté par Vout du contrôleur avec restauration d’état activée (registre 6 = 1), le module peut redémarrer à cause d’un creux de tension.
Solution de contournement
- Utilisez des alimentations principale et de secours de même tension.
- Utilisez une alimentation séparée de puissance suffisante.
Résolution
Corrigé dans 1.17.2.
ERRMR09 : pointes dans les mesures de fréquence des entrées
Appareils concernés
Tous les WB-MR et WB-MRWM2 avec un micrologiciel jusqu’à 1.17.4 inclus
Description
Si une fréquence d’entrée élevée descend sous 1 Hz, les mesures peuvent brièvement revenir à une valeur élevée. Le problème ne survient pas lorsque les impulsions cessent complètement. Le WB-MRWM2 utilisant un convertisseur tension-fréquence pour mesurer la puissance, déconnecter une charge peut de même provoquer des pointes transitoires de puissance à la valeur précédente.
Résolution
Corrigé dans 1.17.5.
ERRMR10 : le WB-MRWM2 ne compte pas l’énergie
Appareils concernés
Concerne uniquement le WB-MRWM2 avec les micrologiciels 1.19.0 à 1.20.1 inclus ; détails : ERRMRWM0001
ERRMR11 : réponses à toutes les requêtes étendues à l’adresse 0xFD
Appareils concernés
WB-MRWL3, WB-MR3LV/K(I), WB-MR6LV/K(I), WB-MR3LV/S, WB-MR6LV/S, WB-MRPS6, WB-MR6C v.2, WB-MR6C v.3, WB-MR6CU v.2 et WB-MRM2-mini avec un micrologiciel antérieur à 1.21.1.
Description
L’adresse 0xFD transporte les commandes Fast Modbus nécessitant une réponse de données et d’autres requêtes en diffusion. Les appareils concernés répondaient à tous les paquets à 0xFD, y compris ceux sans commandes Fast Modbus.
Mesure corrective
Mettez à jour vers le micrologiciel 1.21.1.
Résolution
Corrigé dans le micrologiciel 1.21.1.
ERRMR12 : l’appareil se bloque avec tous les voyants éteints
Description
La commutation de certains contacteurs peut bloquer le module et éteindre tous ses voyants. Couper puis rétablir son alimentation restaure le fonctionnement.
Appareils concernés
- WB-MR3LV/S lot v4.3A
- WB-MR3LV/I lots v4.0I–v4.2A
- WB-MR6LV/S lots v4.3B–v4.5C
- WB-MR6LV/I lots v4.0M–v4.2C
- WB-MR6C v.2 lots v3.6M–v3.7C
- WB-MR6C v.3 lots v4.3H–v4.4C, sauf v4.3H/1
- WB-MR6CU v.2 lots v1.4A–v1.6A
- WB-MRPS6/S lots v1.3B–v1.4A
- WB-MRWL3 lots v1.4F–v1.5B
Cause et détails
Un verrouillage parasite de l’EEPROM abaisse la tension d’alimentation du microcontrôleur. Couper puis rétablir l’alimentation de la carte le supprime. La probabilité est faible et dépend de plusieurs facteurs.
Solution de contournement
Les appareils concernés présentant ce défaut sont remplacés sous garantie.
Correction
Les lots ultérieurs n’utilisent plus et ne comportent plus d’EEPROM.
ERRMR13 : défaillance de la résistance fusible de l’alimentation haute tension du WB-MR6C v.3
Description
Très rarement, la résistance fusible tombe en panne lors de l’utilisation de l’alimentation intégrée 220 V.
Appareils concernés
Tous les WB-MR6C v.3 avant le lot v4.4H.
Cause et détails
Le démarrage de l’alimentation près de la crête de la sinusoïde secteur peut, dans de rares cas, surcharger la résistance fusible pendant la charge de la capacité interne. Les variations de tolérance à la puissance de pointe provoquent l’ouverture de la résistance et la déconnexion de l’alimentation interne. Le fonctionnement avec une alimentation externe de 9–28 V n’est pas affecté.
Solution de contournement
Le module à relais est remplacé sous garantie.
Résolution
Corrigé à partir du lot v4.4H.
ERRMR14 : mesure de tension d’alimentation du WB-MR6C v.3 inférieure d’environ 0.3 V
Description La tension d’alimentation indiquée est inférieure d’environ 0.3 V à la valeur réelle.
Appareils concernés
WB-MR6C v.3 lot v4.4J/2.
Liste des numéros de série
Cause et détails
Sur certains appareils, une diode de protection inutilisée du circuit d’alimentation n’a pas été shuntée à l’assemblage.
Solution de contournement
Le module à relais est remplacé sous garantie.
Résolution
Corrigé au sein du lot v4.4J/2.
ERRMRM2_NC001 : le WB-MRM2-mini/NC ne respecte pas la tension d’isolement spécifiée des contacts
Description Sur le WB-MRM2-mini/NC, le contact NO inutilisé du relais est très proche de la piste NC et isolé par un vernis épargne dont la tension de claquage est de 500 V, inférieure aux 1000 VAC annoncés.
Appareils concernés
Tous les appareils des versions 2.3–2.4K.
Cause et détails
Omission lors de la conception de l’appareil.
Solution de contournement
Le module à relais est remplacé sous garantie.
Résolution
Corrigé dans les lots postérieurs à 2.4K.