Faire communiquer 2 m3 ensemble
Modérateurs : ramses, Balajol, monteric, j2c
- Pasquall
- Modérateur
- Messages : 264
- Enregistré le : mer. avr. 09, 2008 20:04 pm
- Localisation : Vizille (38)
- Contact :
Bonjour
Alors pour le coup, depuis peux j'ai été énormément renseigné sur le sujet.
Premièrement : solution sans équipement tiers
Matériel nécessaire :
Un M3 custom (adapté) extensible + une extension de communication modbus maitre XN07
Un M3 normal extensible + une extension de communication modbus standard XN06
La description du fonctionnement se trouve dans le fichier en pièce jointe.
Deuxièmement : solution avec équipement tiers
Matériel nécessaire :
Deux M3 quelconques + un équipement informatique ou il faudra développer un système d'échange (donc avec deux ports série/USB)
Le problème de cette solution est qu'il n'existe actuellement aucun programme prévu pour réaliser l'échange entre deux M3 via la liaison série. Cela demande donc de développer un module logiciel qui lira les blocs SL OUT d'un M3, pour écrire les valeurs dans les blocs SL IN du second M3, et inversement, en prévoyant un système de signal de vie afin que les programmes M3 puissent à tout moment connaitre l'état de la communication (afin de pouvoir palier à une panne en prévoyant un mode "par défaut" si la communication est en panne)
Alors pour le coup, depuis peux j'ai été énormément renseigné sur le sujet.
Premièrement : solution sans équipement tiers
Matériel nécessaire :
Un M3 custom (adapté) extensible + une extension de communication modbus maitre XN07
Un M3 normal extensible + une extension de communication modbus standard XN06
La description du fonctionnement se trouve dans le fichier en pièce jointe.
Deuxièmement : solution avec équipement tiers
Matériel nécessaire :
Deux M3 quelconques + un équipement informatique ou il faudra développer un système d'échange (donc avec deux ports série/USB)
Le problème de cette solution est qu'il n'existe actuellement aucun programme prévu pour réaliser l'échange entre deux M3 via la liaison série. Cela demande donc de développer un module logiciel qui lira les blocs SL OUT d'un M3, pour écrire les valeurs dans les blocs SL IN du second M3, et inversement, en prévoyant un système de signal de vie afin que les programmes M3 puissent à tout moment connaitre l'état de la communication (afin de pouvoir palier à une panne en prévoyant un mode "par défaut" si la communication est en panne)
- Fichiers joints
-
- NTRxx_XN07 UE.doc
- Fonctionnement communication multi M3 via XN07
- (107 Kio) Téléchargé 123 fois
En Normandie, ça vole entre deux pluies
En Isère ça vole du tonnerre!!!
Expert en M3 (enfin programmation M3 ^^)
Site de SmartApp
En Isère ça vole du tonnerre!!!
Expert en M3 (enfin programmation M3 ^^)
Site de SmartApp
- Pasquall
- Modérateur
- Messages : 264
- Enregistré le : mer. avr. 09, 2008 20:04 pm
- Localisation : Vizille (38)
- Contact :
En tant que développeur logiciel, je considère qu'un micro contrôleur fait partie de l'informatique, puisque je code dessus presque de la même manière que sur un PC. enfin après c'est qu'une question de point de vue (bah oui pour l'électronicien ca reste un truc électronique).
Discussion futiles mises à part, oui un micro ferai bien l'affaire : peu consommateur d'énergie, grande stabilité. Reste la couche de communication à développer (puisque ce n'est pas un protocole standard).
Discussion futiles mises à part, oui un micro ferai bien l'affaire : peu consommateur d'énergie, grande stabilité. Reste la couche de communication à développer (puisque ce n'est pas un protocole standard).
En Normandie, ça vole entre deux pluies
En Isère ça vole du tonnerre!!!
Expert en M3 (enfin programmation M3 ^^)
Site de SmartApp
En Isère ça vole du tonnerre!!!
Expert en M3 (enfin programmation M3 ^^)
Site de SmartApp
-
- Etudiant Solaire
- Messages : 278
- Enregistré le : lun. févr. 08, 2010 14:42 pm
- Localisation : 61 - Perche
Si je peux me permettre je dirais que c'est une solution stupide. Si l'échange dois se faire dans les deux sens ça monopoliserais une quantité considerable d'entrée/sortie sur chaque M3.
Sachant qu'un entier dans le sens informatique du terme fait 16 bits, il faudrait utiliser 16 sorties, et 16 entrées sur chaque automate. Même en perdant beaucoup de précision et en réduisant à 8 bits, ça consomerais presque toutes les entrées/sortie sur chaque M3.
Je ne sais pas a quoi vont servir ces automates, mais ça ne me semble pas rationnel comme solution.
@Pasquall : ok vu comme ça on est d'accord. C'est juste que pour beaucoup de gens "equipement informatique" = ordinateur. Et je me disais que de dédier un ordinateur à ce genre de tache c'est pas ce qu'il y a de plus economique.
A mon avis le devellopement du protocole ne doit pas être bien compliqué. J'ai un peu regardé comment fonctionnent les blocs SLin et SLout, c'est finalement assez simple. Le point le plus délicat c'est la vitesse, vu que la communication se fait à 115kbps il faut juste un microncontrôleur assez rapide.
J'aurais le temps c'est un projet qui me plairait bien de tenter.
En tout cas si un jour quelqu'un fabrique un jour ce genre de "coupleur" je suis sûr que ça pourrait interesser pas mal de monde ici.
Sachant qu'un entier dans le sens informatique du terme fait 16 bits, il faudrait utiliser 16 sorties, et 16 entrées sur chaque automate. Même en perdant beaucoup de précision et en réduisant à 8 bits, ça consomerais presque toutes les entrées/sortie sur chaque M3.
Je ne sais pas a quoi vont servir ces automates, mais ça ne me semble pas rationnel comme solution.
@Pasquall : ok vu comme ça on est d'accord. C'est juste que pour beaucoup de gens "equipement informatique" = ordinateur. Et je me disais que de dédier un ordinateur à ce genre de tache c'est pas ce qu'il y a de plus economique.
A mon avis le devellopement du protocole ne doit pas être bien compliqué. J'ai un peu regardé comment fonctionnent les blocs SLin et SLout, c'est finalement assez simple. Le point le plus délicat c'est la vitesse, vu que la communication se fait à 115kbps il faut juste un microncontrôleur assez rapide.
J'aurais le temps c'est un projet qui me plairait bien de tenter.
En tout cas si un jour quelqu'un fabrique un jour ce genre de "coupleur" je suis sûr que ça pourrait interesser pas mal de monde ici.
- Pasquall
- Modérateur
- Messages : 264
- Enregistré le : mer. avr. 09, 2008 20:04 pm
- Localisation : Vizille (38)
- Contact :
Salut
Alors sur le multiplexage, pour moi ca ne vaut vraiment pas le coup, je m'explique :
- Premièrement, un M3 standard possède des sorties relais. Si tu fait du multiplexage, cela signifie que tu vas avoir des changements d'états de tes relais très fréquement ce qui va provoquer une forte usure prématurée.
- Deuxièmement, avec un M3 à sorties statiques, cette fois si on ne peut accuser une usure des relais (un transistore n'a pas la même notion d'usure), mais il reste un argument important. Un M3 (sorties relais ou statique) n'a que 10 sorties au maximum (base sans extensions), et le M3 utilise des valeurs sur 16 bits (il faudrai donc 16 sorties pour chacun des bits).
Alors oui y'a mille et une façon de ruser par exemple en envoyant que 4 bits à chaque fois, histoire de garder des sorties pour faire un peu autre chose...ce qui reste le but principal du M3, mais on ralentis alors énormément la vitesse de transfert des infos entre les deux M3.
Pour finir la dessus, la complexité du multiplexage à mettre en oeuvre pour passer des valeurs ANA entre deux M3 via les sorties/entrées TOR est tel que l'ont va consommer énormément de mémoire programme.
Donc avant d'en arriver à des solutions comme ca, je pense qu'il vaut mieux réflchir à deux fois au "pourquoi j'ai besoins que mes deux M3 s'envoient des valeurs ANA" afin de voir si quelques (2 ou 3) signaux TOR ne seraient pas suffisant.
Alors sur le multiplexage, pour moi ca ne vaut vraiment pas le coup, je m'explique :
- Premièrement, un M3 standard possède des sorties relais. Si tu fait du multiplexage, cela signifie que tu vas avoir des changements d'états de tes relais très fréquement ce qui va provoquer une forte usure prématurée.
- Deuxièmement, avec un M3 à sorties statiques, cette fois si on ne peut accuser une usure des relais (un transistore n'a pas la même notion d'usure), mais il reste un argument important. Un M3 (sorties relais ou statique) n'a que 10 sorties au maximum (base sans extensions), et le M3 utilise des valeurs sur 16 bits (il faudrai donc 16 sorties pour chacun des bits).
Alors oui y'a mille et une façon de ruser par exemple en envoyant que 4 bits à chaque fois, histoire de garder des sorties pour faire un peu autre chose...ce qui reste le but principal du M3, mais on ralentis alors énormément la vitesse de transfert des infos entre les deux M3.
Pour finir la dessus, la complexité du multiplexage à mettre en oeuvre pour passer des valeurs ANA entre deux M3 via les sorties/entrées TOR est tel que l'ont va consommer énormément de mémoire programme.
Donc avant d'en arriver à des solutions comme ca, je pense qu'il vaut mieux réflchir à deux fois au "pourquoi j'ai besoins que mes deux M3 s'envoient des valeurs ANA" afin de voir si quelques (2 ou 3) signaux TOR ne seraient pas suffisant.
En Normandie, ça vole entre deux pluies
En Isère ça vole du tonnerre!!!
Expert en M3 (enfin programmation M3 ^^)
Site de SmartApp
En Isère ça vole du tonnerre!!!
Expert en M3 (enfin programmation M3 ^^)
Site de SmartApp
Exact c'est juste une piste de reflexion que j'abordais avec vous,
qui n'est effectivement pas très pertinente.
J'ai maintenant deux M3 à la maison et je voulais leur faire échanger des infos de relevé de températures, je vais réflechir à la question avec les idées que vous m'avez donné et je vous tiendrai au courant
Merci !
qui n'est effectivement pas très pertinente.
J'ai maintenant deux M3 à la maison et je voulais leur faire échanger des infos de relevé de températures, je vais réflechir à la question avec les idées que vous m'avez donné et je vous tiendrai au courant
Merci !