Cookie
Electronic Team, Inc. uses cookies to personalize your experience on our website. By continuing to use this site, you agree to our cookie policy. Click here to learn more.

Connexion simultanée à plusieurs ports COM

Serial to Ethernet Connector permet de partager un port série avec plusieurs clients à la fois. Il offre également la possibilité de connecter un seul et même client à plusieurs interfaces série distantes.
Essayer gratuitement
Période d'essai de 14 jours gratuits
La licence est disponible à partir de $259.95
Disponible pour

Envoi des données de ports série vers plusieurs applications

Serial to Ethernet Connector vous permet d’envoyer les données d’un même périphérique série vers plusieurs ordinateurs distants. Vous pouvez par exemple connecter un capteur GPS série à plusieurs ordinateurs distants afin de partager simultanément ses données. Plusieurs utilisateurs peuvent ainsi accéder simultanément aux mêmes données depuis différentes applications à partir du moment où ils sont connectés sur le réseau.
Une position GPS reçue par plusieurs utilisateurs

Fusionner les données transmises par plusieurs périphériques série

Serial to Ethernet Connector peut fusionner les données transmises par plusieurs périphériques série vers un seul et même ordinateur distant. Vous pouvez par exemple regrouper les données de plusieurs détecteurs ou capteurs d’alarme et les envoyer vers un ordinateur central. Un technicien pourra ainsi accéder simultanément aux données de tous les appareils afin de prendre les décisions adéquates sur les systèmes protégés par les alarmes.
Un ensemble de capteurs géré depuis un seul et même ordinateur portable

Comment partager un port série avec plusieurs ordinateurs

1
Installez Serial to Ethernet Connector sur l’ordinateur auquel est physiquement connecté un périphérique série tel qu’un capteur GPS. Installez le logiciel sur tous les autres ordinateurs ayant besoin d’accéder aux données GPS.
Obtenir le programme d’installation pour votre système d’exploitation
2
Sur l’ordinateur auquel est connecté le GPS, créez une connexion serveur qui recevra les données du port physique.
Sélectionnez Connexion serveur sur l’ordinateur et choisissez le protocole Données RAW
3
Sur un ordinateur client distant, exécutez le logiciel et rendez-vous sur l’onglet "Connexions à distance". Attribuez un nom au port virtuel et cliquez sur "Créer" pour établir la communication avec le serveur.
L’onglet sur trouve sur la barre d’outils située en haut
4
Répétez les deux étapes précédentes sur tous les ordinateurs qui doivent accéder aux données du GPS.
Procédez de la même manière sur l’ordinateur local si vous utilisez plusieurs capteurs
5
Vous pouvez à présent transmettre des données GPS à tous les ordinateurs distants depuis un seul et même serveur.
Vous pouvez gérer les connexions depuis l’ordinateur central ou les ordinateurs auxquels sont physiquement connectés les périphériques
Remarque : Si la création automatique de connexions n’est pas activée dans l’onglet "Connexions distantes", vous devrez les créer manuellement. Veuillez consulter le manuel utilisateur pour savoir comment procéder.

Avis de nos clients

4.9 note globale, basé sur 372 utilisateurs revue
Utilisé par plus de 150 entreprises dans le monde entier
Daniele Besana
Ingénieur réseau
Serial to Ethernet Connector s’avère être la solution la plus efficace que j’ai pu essayer jusqu’à maintenant. La technologie de virtualisation de ports série proposée par ce logiciel permet d’éviter d’avoir à utiliser des cartes d’extension ou des ordinateurs supplémentaires. Cette technologie m’est particulièrement utile dans mon système de transmission de données car les interfaces RS 232 virtuelles sont la solution la plus simple pour l’accès à distance et la gestion des périphériques série sur le réseau.
Olivia Lane
Ingénieur en contrôle de la pollution
Dans notre laboratoire de contrôle qualité, nous utilisons des instruments spécialisés communiquant avec les ordinateurs via des ports série. Pour éviter d’avoir à déplacer et à recalibrer constamment notre matériel, nous avons décidé d’essayer de partager les appareils sur le réseau local. Serial to Ethernet Connector nous a permis d’y arriver facilement. Dorénavant, lorsque quelqu’un a besoin de se connecter à un appareil en particulier, il lui suffit de partager le port série sur l’Ethernet et d’y accéder à distance via un serveur terminal.
Stefan Mueller
Architecte solution chez Alpla
Serial to Ethernet Connector nous permet de connecter nos vieux appareils avec notre nouvelle application web. La principale raison qui nous a poussé à choisir Electronic Team est l’interface du logiciel. Elle semble bien plus intuitive et moderne que celles des logiciels concurrents. Grâce à Serial to Ethernet Connector, nous n’avons pas besoin de remplacer les appareils anciens connectés aux clients via des interfaces série et pouvons continuer à les utiliser avec la nouvelle solution.
Emma Davis
Programmeur en contrôle de processus
Serial to Ethernet Connector répond à tous nos principaux besoins. Cette solution fiable propose l’authentification par mot de passe et le chiffrement des données transmises. Ces fonctionnalités sont particulièrement importantes dans notre cas étant donné que nous travaillons avec des terminaux de point de vente et devons nous assurer que nos données soient sécurisées. Cette application nous permet d’accéder très facilement aux appareils de point de vente via des ports série virtuels partagés sur l’Ethernet.
James Meyer
Ingénieur performances
Les fonctionnalités de partage de ports COM de Serial to Ethernet Connector font désormais partie intégrante de notre logiciel de diagnostic de machines de plateformes pétrolières. Depuis que nos ingénieurs ont ajouté les fonctionnalités d’accès à distance dans notre système d’automatisation, le personnel de service peut détecter les problèmes affectant le fonctionnement du système de manière beaucoup plus rapide et efficace.
Jacob Williams
Ingénieur en communications
J’étais à la recherche d’un moyen pour rediriger un périphérique TAPI vers une session de bureau à distance Citrix XenDesktop. Étant donné qu’il semblait impossible de le connecter à un port COM virtuel sur XenDesktop, j’ai choisi d’utiliser une autre solution. Serial to Ethernet Connector m’a permis de rediriger mon périphérique TAPI sur l’Ethernet pour y accéder depuis ma machine virtuelle.
Claudio Corniani
Responsable ingénierie électronique chez PIUSI SPA (Italie)
Nous avons intégré les fonctionnalités de Serial to Ethernet Connector à notre matériel. Cela nous a permis de virtualiser un nouveau port série et de rediriger les communications vers le port Ethernet sans avoir à effectuer d’autre modification sur notre logiciel. Nous avons amélioré nos performances globales !

Questions fréquemment posées

Oui — c’est le schéma classique de diffusion, et c’est exactement à cela que sert une connexion serveur Raw. La machine avec le périphérique exécute une connexion serveur sur le port, et n’importe quel nombre de machines clientes s’y connectent ; chaque client reçoit une copie de la sortie du périphérique. C’est la solution naturelle pour distribuer un flux GPS, un flux de capteur, ou tout périphérique dont plusieurs ordinateurs ont besoin des données en même temps.

Gardez deux choses à l’esprit. Utilisez le mode Raw pour cela — Telnet (RFC 2217) est pair à pair et n’acceptera pas plusieurs clients. Et le multi-client est sûr pour la lecture : si plusieurs clients envoient aussi des commandes à un périphérique à commandes/réponses, leurs écritures s’entrelacent sur l’unique port physique et se corrompent mutuellement, donc faites arbitrer les commandes par un seul client de contrôle. Plusieurs lecteurs, oui ; plusieurs rédacteurs non contrôlés, non.

Réponse de Nikolai Svarachevsky · Développeur principal
Oui. Étant donné que les types de connexion serveur et client sont interchangeables, l’image miroir de « plusieurs clients, un serveur » est entièrement prise en charge : une machine exécute plusieurs connexions client, chacune se connectant à un serveur différent, et chacune étant mappée localement à son propre port COM virtuel. C’est le schéma standard de convergence — qui consiste à regrouper plusieurs appareils distants dans un ordinateur central.

La règle de conception qui permet de garder cela clair est la suivante : un port virtuel par source distante. Votre application lit alors chaque appareil sur un port distinct et sans ambiguïté. Évitez la tentation de fusionner plusieurs serveurs distants dans un seul port local — leurs flux d’octets s’entrelaceraient sans aucun moyen de les distinguer, à moins que les charges utiles ne soient explicitement auto-identifiantes. Ports séparés, sources séparées.

Réponse de Nikolai Svarachevsky · Développeur principal
Oui, et c’est plus simple qu’il n’y paraît. Chaque machine publie son propre port réel comme connexion serveur, puis crée des ports virtuels qui se connectent à toutes les autres connexions serveur des autres machines (toutes sauf la sienne). Faites cela sur chaque nœud et les données de chaque appareil deviennent disponibles sur toutes les autres machines — c’est votre étoile. Le modèle serveur/client interchangeable est ce qui permet de l’assembler proprement, il n’y a donc pas de « mode maillé » spécial à chercher ; vous le construisez simplement à partir des mêmes connexions que vous utilisez déjà.

La seule chose à prévoir concerne les écritures, pas les lectures. Distribuer la sortie de chaque appareil à tout le monde fonctionne parfaitement. Mais si plusieurs machines envoient des commandes vers le même appareil, ces écritures s’entrelacent sur ce port physique unique — le série n’a pas d’arbitrage pour plusieurs émetteurs — donc gardez un seul émetteur de commandes par appareil, ou arbitrez cela au niveau de l’application. Si l’architecture devient importante, un port virtuel par source distante (plutôt que d’en fusionner plusieurs en un seul) permet de garder chaque flux proprement séparé.

Réponse de Nikolai Svarachevsky · Développeur principal
Parce que la RFC 2217 confère à un seul client l’autorité sur les paramètres du port — débit en bauds, lignes de signal, état du port — et cette autorité ne peut pas être partagée de manière cohérente. Si deux clients étaient connectés en même temps et que chacun essayait de définir un débit en bauds différent ou de piloter RTS différemment, le port physique n’aurait aucun moyen de satisfaire les deux. Le protocole est donc défini comme pair à pair : un seul client possède la session RFC 2217 à la fois.

C’est pourquoi le partage multi-client utilise le mode Raw, qui ne transporte aucune propriété des paramètres du port et peut donc dupliquer en toute sécurité un flux d’octets vers de nombreux clients. Les deux modes sont complémentaires par conception : Telnet/RFC 2217 pour un seul pair ayant besoin d’un contrôle complet du port, Raw pour de nombreux pairs qui ont seulement besoin des données. Si vous avez besoin à la fois du contrôle et de la diffusion, donnez au consommateur de contrôle sa propre connexion Telnet dédiée, distincte de la diffusion Raw.

Réponse de Nikolai Svarachevsky · Développeur principal
Oui. Dans une connexion serveur en mode brut, les paramètres de transfert de données vous donnent une liste déroulante Envoyer les données à, et l’une de ses options est Dernier actif — les données sont envoyées uniquement au client qui a répondu en dernier. C’est exactement le comportement « répondre uniquement à la dernière connexion qui a écrit » ; vous n’êtes pas obligé de diffuser la sortie de l’appareil à tous les clients. Il existe une liste déroulante correspondante Recevoir les données de avec les mêmes choix (Aucun, Seulement le premier / Seulement le dernier, Dernier actif, Tous), ce qui vous permet aussi de contrôler le côté entrant.

La valeur par défaut pour les deux est Tous — chaque client reçoit la sortie de l’appareil — ce qui est le bon réglage pour un appareil qui diffuse simplement vers de nombreux lecteurs. Lorsque vous avez un appareil de type requête/réponse partagé entre plusieurs clients et que vous voulez que chaque réponse revienne uniquement au demandeur, passez Envoyer les données à sur Dernier actif. Deux points à garder à l’esprit : il s’agit d’une fonctionnalité du mode brut (en Telnet/RFC 2217, la connexion est de toute façon un-à-un), et si plusieurs clients peuvent écrire à la suite en très peu de temps, coordonnez-les au niveau de l’application afin que « dernier actif » corresponde bien au client visé.

Réponse de Bohdan Miniv · Ingénierie QA
Serial to Ethernet Connector
Connexion simultanée de plusieurs ports COM
Essayer gratuitement
Période d'essai de 14 jours gratuits
La licence est disponible à partir de $259.95
Disponible pour