Bonjour,
J'aimerai mettre en réseau deux variateurs de vitesse. Le problème c'est que leur CU utilise une communication USS via Rs485... Selon vous c'est possible de connecter les deux variateurs en RS485 à un convertisseur RS485/ethernet passer par un VLAN puis un PC pour faire de l'affichage. Par exemple remonter les alarmes et certaines données comme la vitesse etc.
Qu'est ce que vous en pensez ?
Hello,
Bonjour, il existe des convertisseurs Ethernet/RS485 OU rs232 pas de problème, ils permettent de passer des données ans un sens ou un autre, pas de problème.Selon vous c'est possible de connecter les deux variateurs en RS485 à un convertisseur RS485/ethernet passer par un VLAN puis un PC pour faire de l'affichage. Par exemple remonter les alarmes et certaines données comme la vitesse etc.
En revanche passer par un VLAN ? tu te trompes de couche, le VLAN inclut une notion de routage qui , a mon avis n'est pas prévue sur les machins en RS485; Ils offre le mode de fonctionnement tcp client ou serveur coté tcpip c'est déjà pas mal.
Les transducteurs Ethernet/RS485 permettent de passer des données dans les deux sens , c'est tout. Avec un peu de chanse tu pourra même avec la même ligne RS485 je crois adresser plusieurs équipements distants dns l'usine par exemple. Mais il faudra faire des développements complémentaires sur PC pour gérer tes VLANS.
A plus
C'est l'étincelle qui a fait déborder le vase !
Bonjour,
Merci pour ta réponse ! Alors ce que je "crois avoir compris" c'est que je peux mettre plusieurs variateurs en réseau (31 max d'après la doc) avec le support RS485 et protocole USS (ça moi pas connaitre mais bon ça se configure). Ensuite je connecte mon maître qui est mon "transducteur" à ce petit réseau RS485 et l'autre bout à mon réseau Ethernet. Et la tu me dis que je peux pas passer par un switch, c'est obligatoirement un ordinateur (ou API) ?
la doc uss (pour les curieux):
https://cache.industry.siemens.com/d...53_spec_76.pdf
c'est assez daté comme protocole...
le big problème, c'est qu'il y a des tempos inter octets à respecter, du genre, il faut un silence avant un stx (caractère de début de message), et ça, ce n'est pas dans le standard de com rs485, donc pas prévu dans les adaptateurs Ethernet/RS485.
donc oui, tu peux mettre jusqu'à 32 slaves derrière un master.
si ton master a aussi une patte Ethernet, tu entres (à distance) par ce coté, et tu pilotes donc à distance le master qui pilote localement les variateurs (en rs485, localement, ça peut déjà être sympa comme distance, mais il faut faire attention aux impédances).
Attention, il faut que ton master "sache" quoi faire en cas de perte de communication coté Ethernet (fermer le robinet de remplissage e la baignoire si trop long silence par exemple).
Jusqu'ici tout va bien...
Hello,
Non on peut supposer qu'il n'y ait pas de problème de timing coté protocole RS485 la "boite" qui fait la connexion Ethernet/RS485 est sensée recevoir les data de Ethernet et les transcoder correctement.
Du coté Ethernet je ne vois pas de problème à ce que cela passe par un switch ou deux ... mais il faudra bien un programme quelque part qui envoi les ordres RS485 encapsulés sur Ethernet et soit aussi capable
de recevoir des données en provenance du réseau RS485 et de les exploiter .... le seul intérêt de cette manip est de pouvoir commander les deux engins au moyen d'un réseau Ethernet standard, mais il faudra bien une application sur un pc qui attaque un boitier RS485 --> eTHERNET a l'autre bout ... tout ceci pour se rapprocher du fonctionnement normal via RS485 ///
Petite note , le RS485 est fait pour fonctionner à des vitesses de 10 Mb/s et des distance de 1200 m mais pas les deux à la fois bien sur et est plutôt adapté aux environnement industriels grâce au caractère symétrique de sa ligne de transmission.
Ou bien il faudra développer des applications spécifiques ...
A PLUS
C'est l'étincelle qui a fait déborder le vase !
sauf que les boiboites Ethernet/RS485 assument un transfert de données asynchrones, mais ne se préoccupent pas de ce qu'il se passe entre 2 datas, donc les tempos inter data risquent fort de prendre une baffe.Envoyé par Patrick_91
le début d'un message, c'est à priori une tempo et un stx pour ne pas mélanger avec un stx au milieu d'un train. donc 2 cas de soucis potentiels:bien sûr, ça marchera toujours au début, mais c'est plus tard que ça risque de remonter à la surface et plus personne n'y comprendra rien...
- le début de message n'est pas bien régénéré,
- une petite tempo avant un stx du milieu et ça peut être interprété pour un début de message.
Jusqu'ici tout va bien...
hello,
Oui, sauf s'il y a une alarme indiquant que des datas n'ont pas été reçus ou transmis , c'est pour cela que je dis qu'il faut du code en plus quelque part ... en première approche on peut penser que ce la ferait du temps réel (vu la vitesse de ethernet) mais sans gestion des erreurs sur RS485 exploitées et retournées au cpu qui génère
et gère les data RS485 il y aura toujours un doute. d'ou l'idée :
CPU (avec sortie RS485 et programme applicatif) --> transcodeur(rs485)<**>ETHERNET <**> Transcodeur(RS485)<--> Terminal RS485
Ceci semble plus réaliste, a voir !! ...
A plus
C'est l'étincelle qui a fait déborder le vase !
Bonjour désolé pour le temps de réponse,
J'ai fait un test ... alors ça marchouille seulement mon interface graphique c'est un terminal et ça déconne méchamment par moment mais j'arrive a lire ce que je voulais... Le technicien m'a regardé avec des yeux lorsque je lui ai montré... du coup je vais changer les CU pour passer en Profinet et utiliser un pitit API et WinCC. C'est plus simple et moins "dégueulasse" comme il dit et je le comprends. Voila voila tout ca pour rien.
En tout cas merci de votre implication
