+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Instrument IO & VISA (/Forum-Instrument-IO-VISA)
+---- Thema: virtual-com-port erstellen und DCD setzen (/Thread-virtual-com-port-erstellen-und-DCD-setzen)
Seiten: 1 2
RE: virtual-com-port erstellen und DCD setzen - jg - 11.08.2017 10:54
(11.08.2017 09:58 )buettnerstefan schrieb: Hallo Gerd,Aha, du hast also eine funktionierende Lösung
das Auto habe ich ja bereits gekauft, ich möchte es also nicht klauen sondern nur zeitgemäß zum fahren bringen
Und da so ein Oldtimer ein sehr altes Auto ist braucht man beim Hersteller auch nicht mehr nach ein Update fragen sondern man soll dann einen Neuwagen kaufen.
Aber mal Spaß beiseite, ich kann das Programm ja durch schließen eines Kontakts Triggern (und darf das auch).
Jetzt kann ich das mit einem Taster, einem Relais oder sonstwas machen, was spricht also dagegen das aus einem anderen Programm heraus zu machen?
Ich kann jetzt aus meinem Programm heraus eine Relaiskarte auf "an" setzen, damit den Kontakt für den COM-Port schließen was wieder in meinem PC amkommt um das Fremdprogramm zu Triggern. Das funktioniert auch, habe ich bereits getestet!
(11.08.2017 09:58 )buettnerstefan schrieb: Abgesehen davon das man "unnötigerweise Hardware" dafür braucht (um vom PC im PC etwas auszulösen) und dadurch längere Signallaufzeiten entstehen, widerstrebt es mir so einen Pfusch zu machen und reizt es mich das programmatisch hinzubekommen.Mir wäre nicht bekannt, wie das gehen soll. Du müsstest einen Windows-Treiber schreiben, der Windows einen COM-Port vorgaukelt. Dein anderes Programm muss ja diesen COM-Port ebenfalls erkennen und darauf zugreifen. Wobei wir beim nächsten Problemchen sind, sobald dein anderes Programm auf den COM-Port zugreift, wirst du da nicht mehr von LabVIEW aus zugreifen können. Wie willst du es jetzt hinkriegen, die Pins (die ja gar nicht existieren) zu verbinden?
Ich bin sehr zuversichtlich das es gelingt wenn ich eine virtuelle Schnittstelle erzeugen kann und vollzugriff auf diese habe (was bei einer virtuellen wahrscheinlich einfacher ist als bei einer echten).
Daher nun die Fragen:
Kann man mit LabVIEW eine viertelle COM-Schnittstelle erzeugen?
Falls ja, darf ich bitte erfahren wie das geht?
Also da ist die Lösung mit Relais-Karte und echtem COM-Port (selbst wenn das ein sogenannter virtueller COM-Port an einem USB-zu-RS-232-Konverter ist) sicherlich doch die einfachere und kostengünstigere Alternative.
Gruß, Jens
RE: virtual-com-port erstellen und DCD setzen - rolfk - 14.08.2017 11:24
(11.08.2017 09:58 )buettnerstefan schrieb: Ich bin sehr zuversichtlich das es gelingt wenn ich eine virtuelle Schnittstelle erzeugen kann und vollzugriff auf diese habe (was bei einer virtuellen wahrscheinlich einfacher ist als bei einer echten).
Jens hat es auf den Punkt gebracht, Das ginge wenn Du einen Windows Treiber schreiben würdest der zwei virtuelle COM Ports erzeugt die softwaremässig miteinander verbunden sind. Entwicklungsaufwand: einige Mannmonate und auch nur wenn Du ziemlich sattelfest bist mit Winndows Gerätetreiberentwicklung. Das ist aber echte Low-Level C Programmierung und Debugging von Gerätetreibern ist alles ausser einfach. Also denke ich mal das die Lösung mit einer einfachen Relaiskarte sowohl viel einfacher als auch günstiger ist, es sei denn Du beabsichtigst diese Lösung in Massenproduktion anzufertigen so von 10000 Stück an aufwärts. Und dann noch wäre es wahrscheinlich einfacher um die Fremdsoftware ganz einfach in LabVIEW neu zu implementieren.
Du kannst auch versuchen dieses Project hier zum Laufen zu bringen. Es implementiert so ein virtuelles Com Port Null modem. Aber ich bezweifle dass eine der Seiten die NI DCD Kontrolloption implementiert. Das ist eine NI spezifische Extension des COMM Device Drivers für deren eigene Hardware und ich denke nicht dass die irgendwo dokumentieren welchen IOControl call und mit welchen Parametern diese Option implementiert. Eventuel werden solche Extensions in VISA sogar auch noch explizit darauf getested dass der entsprechende Gerätetreiber von NI ist bevor dieser Treiberaufruf überhaupt versucht wird, da man ansonsten durchaus Kernelcrashes bekommen könnte wenn man einen beliebigen Treiber mit diesem Kontrollcode aufruft. Also denke ich dass selbst dieser Treiber nicht wirklich die Lösung wäre.