Version imprimable
Bonjour,
je dois faire une application qui cause avec une machine par un lien série (j'utilise un bon vieux port COM pour ça). La machine n'est pas disponible tout le temps du développement et je dois la modéliser. Du coup il faut que je fasse une autre application "simulateur" qui se comporte comme la machine. Ce simulateur doit créer un port COM virtuel afin que la bonne appli s'y connecte.
Comment fait-on ceci?
Tu pourrais utiliser l'emulateur null-modem com0com c'est un project open source, un driver qui te crée un port virtuel avec qui tu peux faire tout les tests que tu veux.
Ben j'avais bien vu ça. Mais c'est en C. Enfin s'il n'y a que ca, je vais essayer de traduire...
A ta place je me concentrerais plus a developper l'application et a modéliser la machine. Pour les tests, ton application travaillera sur par exemple sur COM4 et ta machine sur COM5 (COM4 et COM5 reliées virtuellement par un cable Nullmodem). Une fois tu aura ta machine en main, tu ne changera rien a ton programme a part le nom du port.
Sinon une autre solution qui ne nécessite aucun driver, si tu possede dans ta machines de 2 Ports COM, tu les relie avec un cable Nulmodem. L'application travaillera sur un port et la machine modélisée sur l'autre.
Il existe un ensemble de composants utilisés pour la programmation d'application pour le port série. On y trouve six composants : TComPort, TComDataPacket, TComComboBox, TComRadioGroup, TComLed, TComTerminal
a l'adresse ComPort
A toi de voir.
Merci de ta réponse, j'utilise en effet ces composants. Par contre, le port com virtuel reste obligatoire, de part les specs du programme (il faudra après qu'il intercepte et complète les trames). Mais l'idée était bonne (parce que simple). :mouarf:
J'avais compris que cette virtualisation n'était nécéssaire que parce que la machine n'est pas disponible tout le temps du développement donc servirais juste pour la phase test. Explique-nous un peu les specs de ton programme.
Le projet complet : je fais la partie comm de la machine et du PC.
Le but dans un premier temps est de simuler la machine. Le logiciel PC (IHM et une partie du traitement) n'est pas fait par moi et est figé (il est antédiluvien), ce qui ne permet pas de faire les opérations de maintenance de la machine. Le but est donc du faire un service qui intercepte les trames de la machine, les corrige si il faut, effectue les opérations de contrôle et de maintenance de la machine et j'en passe. La machine est sur port USB, je m'occupe de tout ca. Par contre il faut que mon driver rende disponible les données sous la forme d'un port COM.
Donc le programme que tu veux développer se situe entre la machine et la vielle application, exact?
Il existe de nombreux application type "Virtual Serial Port Driver", je pense qu'acheter un composant coutera nettement moins cher que de vouloir en programmer un !
ce com0com semble de plus proposer des exemples de code pour une utilisation via DeviceIOControl et FileCreate... donc utilisable via TComPort !
Sinon l'idée du Port COM4 et COM5 connecté via com0com, peut-être même utiliser en prod ?
Tu connectes la machine sur le Port USB
Tu connectes la "vieille application" sur le port COM4
Tu connectes ton "proxy" sur le port COM5
Si j'ai bien compris, tout ce qui envoyé sur 4 revient sur 5 et réciproquement ?
Donc, ton proxy pour choper sur COM5 les trames provenant de la "vieille application" envoyées sur le COM4, ton "proxy" analyserait les trames, les altérerait au besoin, et les renverrais sur le Port USB
Et réciproquement, ce qui arrivent sur l'USB tu l'envoie via ton "proxy" sur le Port COM5 qui renverra sur le COM4 de la "vieille application"
Y'a aussi l'application The HUB for communications (hub4com) qui fait partie du projet com0com.
Ca te permet de recevoir des données et des signaux d'un port, les modifier et les envoyer vers un ou plusieurs ports et vice versa.
C'est une bonne idée mais j'ai pas autant de ressources :/ juste un port USB je n'ai pas de port série réel.
Je vais regarder du côté des DeviceIOCOntrol pour voir si y'a pas moyen.
En fait, j'étais parti sur uniquement l'utilisation de Ports COM Virtuels, puisque ta machine est en USB, il ne semblait pas utile d'utiliser de vrai Port, voire pire d'occuper deux vrais ports, cela aurait été moche !Citation:
Envoyé par DaffyDuck
Aucun problème COM4 et COM5 serait des Ports Virtuels créés par Com0Com (tu peux renommer CNCA0 et CNCB0 )
J'ai rarement des machines avec plus de 2 Ports COM, souvent 3 et 4 sont des Ports COM Virtuels qui utilise un USB
hub4com, c'est effectivement, très interessant
Je cherche à faire quelque chose comme ca :
http://www.serial-port-communication...rtual-activex/
Mais je cherche pas forcément à faire un composant activeX ;)
Hub4com correspond aussi, mais il faut déchiffrer du C et comprendre les mécanismes windows liés. Et moi sous Windows à part Delphi, je vole pas très haut.
Tu n'a pas a déchiffrer le programme en C, com0com est un driver open source qui te permet de créer des ports série virtuel (en couplet), ton "vieux programme" le verra comme si c'était un vrai port série (je suppose que tu peux modifier le Port de communication par défaut sur le "vieux programme" et qu'il travaille sur le port COM1)
Commence par créer le couplet COM5<->CNCB0 et COM6<->CNCB1 (COM5,CNCB0, COM6,CNCB1 sont des noms de Ports virtuels)
- Configure le port du "vieux programme" sur COM5Code:
2
Chaque fois que le "vieux programme" communiquera a travers le port virtuel COM5 tu aura le résultat sur le port virtuel CNCB0 et vise versa.
- Ton application travaillera sur 2 composants TCOMPort, Configure le premier composant (appelons-le SerialCOMPort1) sur CNCB0 (virtuel)et le deuxième composant (appelons-le SerialCOMPort2) sur CNCB1 (virtuel) (seulement si tu compte travailler avec le simulateur, sinon pointe-le vers le port réel COM1 directement a la machine)
Chaque fois que tu reçois une notification sur le SerialCOMPort1 ca veux dire que le "vieux programme" communique avec le Port réel COM1.Si c'est un send tu récupère le paquet tu le modifie et tu le renvois sur SerialCOMPort2 (vers la machine ou le simulateur).
Chaque fois que tu recois une notification sur le SerialCOMPort2 ca veux dire que la machine (ou le simulateur) communique avec le Port réel COM1.Si c'est un send tu récupère le paquet tu le modifie et tu le renvois sur SerialCOMPort1 (vers le "vieux programme").
- Configure le Composant TCOMport de ton simulateur sur le port virtuel COM6.
Pour résumer :
1° Cas : Mode Machine
Vieux Programme <-> COM5 <-> CNCB0 <-> Application <-> COM1 <-> Machine
2° Cas : Mode Simulateur
Vieux Programme <-> COM5 <-> CNCB0 <-> Application <-> CNCB1 <-> COM6 <-> Simulateur
Ok, j'ai fais la manip et je suis assez satisfait du comportement.
Par contre, on n'a fait que détourner le problème. J'aurais aimé savoir généré un port COM virtuel, ca aurait été plus stylé. Mais bon on peut pas tout avoir.:mouarf:
Merci quand même
Si tu veux écrire ton propre driver et tu veux toujours rester a Delphi, il y'a le Delphi Driver Development Kit
Voici un autre simulateur de port COM - Virtual Serial Port Driver (https://www.eltima.com/fr/products/vspdxp/). Le programme créé des paires de ports série virtuels connectés, ressemblant en tous points à des ports série physiques et pouvant être utilisés comme tels.
Ca commence a être un peu vieux cette solution et pas vraiment utilisable sur les OS modernes, c'est vraiment dommage.Citation:
Envoyé par fab256
J'ai moi-même voulu il y a quelque temps me pencher sur le développement de ports USB midi virtuels pour Windows 10 (l'idée était de développer une platine DJ personnalisable qui s'interface aux logiciels de DJ existant.
En Delphi ou (C++ Builder), rien que l'idée de développer un pilote physique ou virtuel, n'est même pas réalisable : on est obligé de se tourner vers Visual c++, pas le choix.
Qui plus est, la documentation ou les sources d'inspiration concernant l'élaboration de ports virtuels sous Windows sur internet sont quasi néantes.
Bref, j'ai laissé tomber.
C'est un GROS manque de Delphi/C++ Builder surement du à une main mise de Microsoft sur cet aspect de développement.
salut
effectivement le linker de delphi ne le permet pas
il existe des possibilitées de créer des drivers mais pas de façon simple
peut aurais t'on plus de chance avec fpc ... a voir