Pourquoi la communication RS-485 S-Bus entre le PCD maître et l’esclave ne manque parfois, si FW 1.28.20... 1.28.33 est utilisé ?

FAQ #102026

Symptômes
Dispositifs PCD programmables qui agissent comme des S-BUS master sur RS485 avec PCD Firmware > = 1.28.20 et < = 1.28.33 n’obtenir aucune réponse de dispositifs esclaves sur certaines des demandes maîtres S-Bus, bien que S-BUS adresse, débit en bauds, la polarité et terminaison de ligne sont OK.

 

Effets possibles de la question

Jusqu'à présent, nous avons trouvé que la communication E-Line RIO semble être que plus préoccupé de ce problème que p. ex. transmission de données RS485 S-Bus entre CPU.

Dans certains cas, l’effet a été, qu’il n’était pas possible d’écrire aux sorties de la ligne E de RIO ou le changement des valeurs sur les entrées de RIO E-Line n’a pas été transféré au maître S-Bus.

Avec le Firmware concerné, il peut être très difficile, voire impossible de télécharger le programme utilisateur via une connexion à une passerelle.

PCD Firmware 1.28.x pour tous les types PCD programmables sont concernés.

 

Raison

La cause du problème est une erreur dans le Firmware du maître S-Bus.
Le problème sur le Firmware, c’est que télégrammes contenant des caractères DLE (B5 ou C5) comme dernier caractère du télégramme (CRC) où incorrect parce que le dernier caractère est manquant.

Étant donné que le CRC est calculé pendant l’exécution cette requête mal formée de S-Bus se produit en fonction du contenu de la demande de S-Bus.

Le CRC (incorrect) est transférée à la demande de S-Bus du maître à l’esclave.

Si maintenant l’esclave reçoit la demande de S-Bus et le CRC reçu ne correspond pas à la CRC calculé, puis l’esclave S-Bus rejettent le télégramme S-Bus.

 

Solution

Dans le cas où vous utilisez le Firmware concerné sur une installation avec la communication de données S-Bus RS485, mettre à jour le PCD maître S-Bus pour le nouveau Firmware disponible > = 1.28.34.