01-30-2014, 10:10 AM
(Modification du message : 07-17-2014, 12:21 PM par Domoconnect.)
Voilà mon projet en 2 mots.
J'ai une box LD qui supervise un automate industriel WAGO en modbus TCP.
Dans mes équipements, j'ai déclaré un bit en écriture pour le pilotage d'une lampe. Jusque là tout va bien.
Le problème vient de la lecture. J'ai déclaré dans mon équipement un bit en lecture pour le retour d'état. Cela fonctionne sans problème pendant une dizaine de minutes et ensuite le widget que j'utilise pour la visualisation est en erreur. Le pilotage fonctionne toujours donc la commande de d'écriture est ok mais plus la lecture.
J'ai fait quelques essais :
- En redémarrant le connecteur, cela fonctionne, mais également quelques minutes.
- Avec un autre logiciel, pas de problème, ce qui me permet de dire que la com du WAGO n'est pas plantée.
J'ai donc plusieurs questions :
- Quelle est le temps (polling) entre les différentes trames? Par expérience un temps de 200ms est un bon compromis entre réactivité et transmission sûre des trames.
- Serait il possible de pouvoir le paramétrer? Les différents systèmes ne réagissent pas de la même façon.
- Il serait pratique d'avoir un debuggeur pour analyser les trames envoyées et reçues.
J'ai une box LD qui supervise un automate industriel WAGO en modbus TCP.
Dans mes équipements, j'ai déclaré un bit en écriture pour le pilotage d'une lampe. Jusque là tout va bien.
Le problème vient de la lecture. J'ai déclaré dans mon équipement un bit en lecture pour le retour d'état. Cela fonctionne sans problème pendant une dizaine de minutes et ensuite le widget que j'utilise pour la visualisation est en erreur. Le pilotage fonctionne toujours donc la commande de d'écriture est ok mais plus la lecture.
J'ai fait quelques essais :
- En redémarrant le connecteur, cela fonctionne, mais également quelques minutes.
- Avec un autre logiciel, pas de problème, ce qui me permet de dire que la com du WAGO n'est pas plantée.
J'ai donc plusieurs questions :
- Quelle est le temps (polling) entre les différentes trames? Par expérience un temps de 200ms est un bon compromis entre réactivité et transmission sûre des trames.
- Serait il possible de pouvoir le paramétrer? Les différents systèmes ne réagissent pas de la même façon.
- Il serait pratique d'avoir un debuggeur pour analyser les trames envoyées et reçues.