Hallo gibt es eine DLL mit der ich eine Virtuelle COM erzeugen kann ? Ich habe eine alte Software die nur über eine COM Geräte steuern kann, möchte nun so eine Art GeräteDummy schreiben, um die Steuerung an aktuelle Hardware anzupassen. Gruss Ralf
Geht auch ohne DLL, nur ein wenig Hardware: Man nehme einen PC mit drei COM Ports und läßt dem ollen Progi seinen RS232-Datenstrom auf den ersten COM Port los. Über ein Nullmodemkabel fängt man die Daten via zweiten Port auf, bearbeitet sie mit dem neuen Progi und schickt via dritten Port zur Zielhardware. Ganz einfach, nicht?
N. Tesla schrieb: > Geht auch ohne DLL, nur ein wenig Hardware: Geht auch ohne Hardware: Mit com0com und hub4com (-> http://com0com.sourceforge.net/) lassen sich virtuelle COm Ports einrichten, die sich auch anzapfen lassen. gruss
@ N. Tesla das ist pure Hardware verschwendung, da ist die COM0COM Lösung doch schon eleganter ... aber auch nicht unbedingt das was ich suche ich habe jetzt schon nach COM >> socket Lösungen gesucht und getestet funktioniert aber alles nicht so richtig ... Gruss Ralf
old-school_offline schrieb: > aber auch nicht unbedingt das was ich suche Nicht? Dann beschreib doch mal genauer, was Du suchst, das ist aus Deiner bisherigen Beschreibung nämlich nicht zu entnehmen. Was fehlt Dir bzw. was stört Dich an com0com?
@ Rufus Τ. Firefly
>> Nicht? Dann beschreib doch mal genauer, was Du suchst ...
ich suche eine Virtuelle COM die über eine API(DLL) angesprochen werden
kann, also quasi direkt, ohne die Umwege einer umgelenkten zweiten COM
oder einer IPSocket-Verbindung.
Gruss Ralf
Ralf G. schrieb: > ich suche eine Virtuelle COM die über eine API(DLL) angesprochen werden > kann, also quasi direkt, ohne die Umwege einer umgelenkten zweiten COM dann kann nicht gehen, dafür braucht man einen Systemtreiber und dort Programmiert man soetwas nicht rein. Aber mit dem com2com brauchst du nicht mal eine DLL und kannst einfach so programmieren.
Das was du suchst dürfte beispielsweise hier zu finden sein: http://www.eltima.com/products/ -> unter "Developer Software" das 'Virtual Serial Port ActiveX' http://www.eterlogic.com/Products.VSPE.html http://www.fabulatech.com/products.html#serial Was das Com2Com angeht, nette Idee, aber es wäre halt schon schön, wenn's das eben in der o.g. Form gibt: Eine DLL o.ä., mit der man einen VCP erzeugen kann. Ralf
@ Ralf mit AktivX habe ich noch nicht gearbeitet ... deine Links schaue ich mir mal in ruhe an. > Was das Com2Com angeht, nette Idee, aber es wäre halt schon schön, > wenn's das eben in der o.g. Form gibt: Eine DLL o.ä., mit der man einen > VCP erzeugen kann. sehe ich auch so ... @ Peter II > dann kann nicht gehen, dafür braucht man einen Systemtreiber und dort > Programmiert man soetwas nicht rein. aber es könnte doch ein Gerätetreiber(virtuelle COM) geben der über eine DLL angesprochen werden könnte ... Gruss Ralf
Die Links von Ralf(Gast) sehen doch schon sehr vielversprechend aus ... http://www.eterlogic.com/Products.VSPE.html > Virtual device: connector > Virtual device: data splitter > Virtual device: pair > Mapper device > User mode device: TcpServer > User mode device: TcpClient > User mode device: Serial Redirector > User mode device: UDP Manager > User mode device: Bridge > Python scripting system > x86 and x86_64 processor architecture support > VSPE API (C/C++ header and static library) for native language > VSPE API Python bindings for Python developers > Embedded HTTP server > Data monitoring > Virtual Serial Ports Emulator is a FREEWARE program on 32 bit > platform and can be used absolutely free for any purpose. http://www.fabulatech.com/products.html#serial > Virtual Serial Port Control > Virtual Serial Port Control is a developer component which makes it > possible to create and control virtual serial ports. The program is > accessible over ActiveX control, Net or DLL. > It entirely replaces hardware serial ports and hardware COM devices. > Virtual COM ports created with Virtual Serial Port Control fully emulate > hardware serial ports. kostet aber 2000$ Gruss auch Ralf
Ralf G. schrieb: > aber es könnte doch ein Gerätetreiber(virtuelle COM) geben der über eine > DLL angesprochen werden könnte ... ja aber wozu sollte man noch ein dll brauchen wenn ein schon eine einheitliche Schnittstelle (com) gibt? Was soll da noch der vorteil von dll sein?
Mach doch 'ne DLL, die auf den physischen COM-Port zugreift und über
eine API 'ne Anzahl von NamedPipes zur Verfügung stellt. Auf die
NamedPipes haste dann Zugriff wie auf 'nen COM-Port, nur dass du eben
nicht "\\.\COMn" als Filename nimmst, sondern "\\.\pipe\<name><nr>",
z.B. "\\.\pipe\VCP1". Dann kannste mittels ReadFile(), WriteFile() ganz
normal auf dem Handle operieren wie mit 'nem seriellen Port auch. Wird
auch von der libC zur Verfügung gestellt, die Funktion schimpft sich da
eben "pipe()" und liefert 'nen FileDescriptor zurück.
VirtualBox kann sowas z.B. machen um die COM-Ports der VM auf eine Pipe
des Hosts zu lenken, falls dieser keine UARTs zur Verfügung stellt. Wozu
man da ein COM-Objekt braucht, seh ich ehrlich gesagt auch nicht ein.
Das bringt natürlich nur was, wenn du Funktionalität trennen oder
multiplexen willst. Für einfachen Mehrfachzugriff reichen die
FILE_SHARE_{READ|WRITE} Flags beim CreateFile doch aus.
Peter II schrieb: > Ralf G. schrieb: >> aber es könnte doch ein Gerätetreiber(virtuelle COM) geben der über eine >> DLL angesprochen werden könnte ... > ja aber wozu sollte man noch ein dll brauchen wenn ein schon eine > einheitliche Schnittstelle (com) gibt? > > Was soll da noch der vorteil von dll sein? Naja, wenn man beispielsweise (alte) Software hat, die eine COM-Schnittstelle voraussetzt, man aber über eine eigene Software die Daten reinfüttern will. Ralf
@ Peter II > ja aber wozu sollte man noch ein dll brauchen wenn ein schon eine > einheitliche Schnittstelle (com) gibt? Noch mal ... ich möchte ein Gerät das an einer COM hängt Simulieren und später auf andere Geräte wie auch immer angeschlossen umsetzen ... Die vorhandene (alte) Steuersoftware kann nur über COM kommunizieren/steuern. Dafür brauche ich eine Virtuelle COM, die ich möglichst direkt aus meiner Software steuern/verwenden will, ohne zusätzliche Tools ! @ Ralf > Naja, wenn man beispielsweise (alte) Software hat, die eine > COM-Schnittstelle voraussetzt, man aber über eine eigene Software die > Daten reinfüttern will. genau So ist es ... Danke für dein Verständnis ... Gruss Ralf
Ralf G. schrieb: > Dafür brauche ich eine Virtuelle COM, die ich möglichst direkt aus > meiner Software steuern/verwenden will, ohne zusätzliche Tools ! wenn schreibe dir selber einen Treiber > @ Ralf >> Naja, wenn man beispielsweise (alte) Software hat, die eine >> COM-Schnittstelle voraussetzt, man aber über eine eigene Software die >> Daten reinfüttern will. und genau das geht mit com2com
> und genau das geht mit com2com
Und genau das sehe ich nicht, wie das bei com2com gehen soll, denn
soweit ich das verstanden habe erzeugt com2com immer zwei
Schnittstellen, die miteinander verknubbelt sind.
Ralf
Ralf schrieb: > denn > soweit ich das verstanden habe erzeugt com2com immer zwei > Schnittstellen, die miteinander verknubbelt sind. Ja, das tut es. Aber genau das ist doch das, was Du brauchst, um mit der Schnittstelle zu reden: Dein nichtveränderbares Programm bekommt die eine davon vorgesetzt, Dein anderes Programm, das den Betrieb der Schnittstelle simulieren soll, eben die andere. Und damit ist die gewünschte Funktionalität erreicht. Da sind keine programmiertechnischen Klimmzüge irgendeiner Art erforderlich; damit muss nur Dein steuerndes Programm halt auch mit einer seriellen Schnittstelle kommunizieren können. Welchen Sinn hätte es, für eine serielle Schnittstelle noch eine eigene, völlig andere und auf dem Planeten sonst nie wieder vorkommende API zu entwickeln? Wozu sollte das gut sein? Du willst mit einem Programm kommunizieren, das eine serielle Schnittstelle ansteuert. Also gibst Du dem Programm seine serielle Schnittstelle, packst ein Nullmodemkabel dran und hängst Dein steuerndes Programm an das andere Ende des Nullmodemkabels. Und genau das macht com0com, nur daß dafür keine Hardware mehr erforderlich ist.
Das stimmt schon, aber es gibt halt Leute die nicht vier VCPs anlegen möchten, wenn sie sich beispielsweise dazwischen hängen möchten. Und andere möchten die Eingangsdaten einer echten Schnittstelle modifizieren, bevor sie sie an die Uraltsoftware weiterreichen. Ralf
Ralf schrieb: > Das stimmt schon, aber es gibt halt Leute die nicht vier VCPs anlegen > möchten, wenn sie sich beispielsweise dazwischen hängen möchten. keine Angst windows kann auch mit mehr als 10 schnittstellen umgehen > Und andere möchten die Eingangsdaten einer echten Schnittstelle > modifizieren, bevor sie sie an die Uraltsoftware weiterreichen. das ist nun schon wieder etwas ganz anders, und hat nichts mit dem ursprünglichen Problem zu tun. Mit Com2Com hättest du schon einen Lösung für dein Problem, nur weil sie etwas unschön ist nimmst du sie nicht? Da scheint das Prblem nicht wichtig zu sein.
Ralf schrieb: > Das stimmt schon, aber es gibt halt Leute die nicht vier VCPs anlegen > möchten, wenn sie sich beispielsweise dazwischen hängen möchten. Dann sieh Dir das com0com-Projekt mal etwas genauer an. Einerseits gibt es dort auch hub4com, und andererseits auch das von Dir anscheinend komplett übersehene com2tcp. Ansonsten: Wenn das Aufstampfen und "ich will aber" wichtiger ist als das Finden einer praktikablen Lösung, hindert Dich nichts in der Welt daran, Dir den Kram so zu entwickeln, wie Du ihn Dir wünschst.
>hindert Dich nichts in der Welt daran, Dir >den Kram so zu entwickeln, wie Du ihn Dir wünschst oder 2000$ zu zahlen.. >Und andere möchten die Eingangsdaten einer echten Schnittstelle >modifizieren, bevor sie sie an die Uraltsoftware weiterreichen. wo soll hier das Problem mit com0com liegen? (das hat ja mit der "echten" überhaupt nichts zu tun..) man ließt von der "echten" (Com1) und schreibt auf die virtuelle (COM15) die uraltsteuerung hängt man an die 2. virtuelle (com16) welche mit COm15 "virtuell" verbunden ist... usw.
@Peter II: > keine Angst windows kann auch mit mehr als 10 schnittstellen umgehen grins >> Und andere möchten die Eingangsdaten einer echten Schnittstelle >> modifizieren, bevor sie sie an die Uraltsoftware weiterreichen. > das ist nun schon wieder etwas ganz anders, und hat nichts mit dem > ursprünglichen Problem zu tun. Der Vorschlag Com2Com aber auch nicht, denn es wurde nach einer DLL o.ä. zur Erzeugung eines VCP gefragt und nicht nach einem virtuellen Nullmodemkabel ;) > Mit Com2Com hättest du schon einen Lösung für dein Problem, nur weil sie > etwas unschön ist nimmst du sie nicht? Da scheint das Prblem nicht > wichtig zu sein. Ja, es wäre eine Lösung für sein Problem. Aber vielleicht nicht die, die er wollte. Abgesehen davon: wie man hier öfter mal sieht tun sich einige schwer mit der UART-Schnittstelle und wie man sie richtig bedient. Daher kann ich mir durchaus vorstellen, dass ein VCP, der über eine DLL bedient wird eben attraktiver ist - ob die Bedienung der DLL nicht genauso ein Gefrickel ist wie die eines VCPs steht auf nem ganz anderen Blatt ;) @Rufus: > Einerseits gibt es dort auch hub4com, und andererseits auch das von Dir > anscheinend komplett übersehene com2tcp. Schön. Er hatte aber nach EINEM VCP gefragt, der durch eine DLL zugreifbar ist und NICHT DURCH EINEN ZWEITEN VCP oder ne IP-Adresse oder oder oder. > Ansonsten: > Wenn das Aufstampfen und "ich will aber" wichtiger ist als das Finden > einer praktikablen Lösung, hindert Dich nichts in der Welt daran, Dir > den Kram so zu entwickeln, wie Du ihn Dir wünschst. Ich behaupte nicht, dass Com2Com nicht praktikabel ist. Ich möchte aber mal anmerken, dass du aufstampfst und "aber willst, dass Com2Com die Antwort" ist. Eine mögliche Lösung ist Com2Com, keine Frage. Er hat aber nach nem anderen Weg gefragt. Ob er Com2Com nimmt oder sich für einen meiner Links entscheidet muss er beurteilen, nicht wir. @Robert: > wo soll hier das Problem mit com0com liegen? Es gibt kein Problem an sich. Einige Leute würden eben einen anderen Weg bevorzugen. Nicht mehr hab ich behauptet. Ich möchte nur mal anmerken, dass es sicherlich funktioniert, wenn man dann zwei Schnittstellen bedienen muss bzgl. Buffern, wechselnden RTS/CTS/DTR/DSR/etc.-Signalen, aber das ist Schnittstellen-spezifisch. Ein VCP, der über DLL angesprochen wird und bei dem man die Daten reinschiebt und gut ist, ist für manche einfach attraktiver. Und ja, ich weiss dass er die Logik und Bedienung der Schnittstelle in eine eigene Klasse verpacken kann um das gleiche Ziel zu erreichen - aber das muss er dann auch erstmal machen. Ralf
Ralf schrieb: > Ich behaupte nicht, dass Com2Com nicht praktikabel ist. Ich möchte aber > mal anmerken, dass du aufstampfst und "aber willst, dass Com2Com die > Antwort" ist. Nö. Da keinerlei Begründung außer "will nicht" gekommen ist, sehe ich das anders. Wären die Forderungen (ja, so muss man das wohl nennen) so detailliert, wie Du sie Dir gerade zurechtinterpretiert hast, dann sähe die Situation anders aus.
@Rufus: > Nö. Da keinerlei Begründung außer "will nicht" gekommen ist, sehe ich > das anders. oO Verzeihung, wo habe ich geschrieben "_ich_ will das so nicht"? Wo hat der Beitragsersteller geschrieben, "_er_ will das so nicht"? > Wären die Forderungen (ja, so muss man das wohl nennen) so detailliert, > wie Du sie Dir gerade zurechtinterpretiert hast, dann sähe die > Situation anders aus. Was fehlt dir noch an Details? Der Beitragsersteller hat geschrieben, dass er's per DLL machen möchte, und die ActiveX Controls die ich gepostet hatte kommen der Sache schon recht nahe und näher als Com2Com. Ich habe da also m.E. nix reininterpretiert. Wo ich die Zügel locker gelassen habe waren die (teils theoretisch, teils praktisch hergeholten) Anwendungsfälle unter dem Gesichtspunkt der 'Programmierfreundlichkeit', sofern man Wert darauf legt. Ralf
>gepostet hatte kommen der Sache schon recht nahe und näher als Com2Com. wirklich? wenn man sich die 2 anschaut: Beitrag "Re: Virtuelle COM als DLL" dann geht es hier nur um das ERSTELLEN/Konfigurieren der Virtuellen com ports (zumindest hab ich das so heraus gelesen) nicht das "auslesen/schreiben" der daten in oder vom Com Port... beim produkt von eltima braucht man dann beides: Serial Port ActiveX und Virtual Serial Port ActiveX ?? (wobei ersteres dann erst recht wieder vom virtuellen com port liest/schreibt)
@ Robert L. >> gepostet hatte kommen der Sache schon recht nahe und näher als Com2Com. > wirklich? > wenn man sich die 2 anschaut: > Beitrag "Re: Virtuelle COM als DLL" > dann geht es hier nur um das ERSTELLEN/Konfigurieren der Virtuellen com > ports (zumindest hab ich das so heraus gelesen) > nicht das "auslesen/schreiben" der daten in oder vom Com Port... So muss mich auch mal wieder zu Wort melden ... Ich möchte gerne eine Virtuelle COM über API(DLL) verwenden, also senden und empfangen und natürlich auch steuern(konfigurieren) ... Die COM2COM - Lösung ist mir bekannt und ist NICHT das was ich in erster Linie suche !!! Gruss Ralf G.
Ralf G. schrieb: > Ich möchte gerne eine Virtuelle COM über API(DLL) verwenden, also senden > und empfangen und natürlich auch steuern(konfigurieren) ... Nur mit einer DLL gehts nicht. Das Handling findet nämlich nicht im Kontext (D)einer Applikation statt, sondern im Kernel Mode. Das ist durch das Design von Windows so bedingt und auch so gewollt, und Du wirst das nicht ändern können. > Die COM2COM - Lösung ist mir bekannt und ist NICHT das was ich in erster > Linie suche !!! Genau DAS ist aber der von der Windows Systemarchitektur vorgegebene Lösungsweg, ob Dir das gefällt oder nicht. fchk
Ralf G. schrieb: > Ich möchte gerne eine Virtuelle COM über API(DLL) verwenden, also senden > und empfangen und natürlich auch steuern(konfigurieren) ... was willst du da steuern? RTS, CTS usw geht auch mit der com2com und viel mehr kann man da doch gar nicht machen.
> was willst du da steuern? RTS, CTS usw geht auch mit der com2com und > viel mehr kann man da doch gar nicht machen. Dachte da eher an Baudrate/Anzahl-DatenBits/Anzahl-StopBits/Parity-Bit/Handshake-Einstellu ng Gruss Ralf
Ralf G. schrieb: > Dachte da eher an > Baudrate/Anzahl-DatenBits/Anzahl-StopBits/Parity-Bit/Handshake-Einstellu das kann du doch alles über die Virtuelle ComPorts von der Applikation einstellen. (bin mir aber nicht sicher ob es überhaupt eine auswirkung hat, denn es werden ja keine wirklichen daten mit einem Takt übertragen).
> Nur mit einer DLL gehts nicht. Das Handling findet nämlich nicht im > Kontext (D)einer Applikation statt, sondern im Kernel Mode. Das ist > durch das Design von Windows so bedingt und auch so gewollt, und Du > wirst das nicht ändern können. wenn ich es richtig gelesen habe ... sieht WINDOWS eine Verwendung einer RS232 über API aber vor ... in der WIN32 gibt es eine API um mit einer RS232 zu kommunizieren ... oder die port.dll oder die rsapi.dll ... ist nur eben mit einer echten COM Gruss Ralf
Ralf G. schrieb: > wenn ich es richtig gelesen habe ... sieht WINDOWS eine Verwendung > einer RS232 über API aber vor ... > > in der WIN32 gibt es eine API um mit einer RS232 zu kommunizieren ... > > oder die port.dll oder die rsapi.dll ... ist nur eben mit einer echten > COM nein - alles Programm die mit einer echten Com umgehen können, können auch mit einer Virtuellen umgehen. Für die Programm ist das überhaupt kein unterschied. Aus dem Grund kann man auch alte hardware mit alter Software für einen USB zum Com adapter betreiben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.