Hallo zusammen, habe mal eine grundsätzliche Frage zur RS232 Schnittstelle. Kann man eine Kommunikation über die Schnittschnittstelle mit 2 Software-tools paralell durchführen, ohne dass die jeweiligen Kommunikation gestört werden? Folgende Praxisbeispiel: Ich habe einen Ofen, der eine rs232 Schnittstelle hat und von einem win7-pc über die Schnittstelle gesteuert wird. Es wird regelmäßig die Temperatur ausgelesen und geloggt und manchmal eine neue Soll-Temperatur gesetzt. Es werden Daten von weiteren Sensoren ignoriert. Diese Daten möchte ich nun mit einer weiteren Software, die parallel auf dem win7 pc laufen soll, auslesen. Die Programmierung an sich sollte funktionieren. Die Frage ist nur, ob durch die zweite Software die Kommunikation zwischen Ofen und "Software 1" gestört werden kann. Könnt ihr mir das beantworten? Die Anfrage kann aus diversen Gründen nicht mehr in die ursprüngliche Software implementiert werden, ohne jetzt ins Detail gehen zu wollen.... Vielen Dank im voraus.
Du kannst den COM-Port nur 1x öffnen. Es geht also nur, wenn jede Software den schließt wenn sie ihn nicht braucht. Das wird die existierende nicht tun. Selbst wenn sie es täte, wird sie es nicht mögen wenn sie ihn wieder öffnen will solange die andere ihn gerade offen hat. Wenn du das Protokoll verstehst, kannst du einen Treiber schreiben, der einen virtuellen COM-Port für die alte SW simuliert. Angenommen du hast Windows: Du könntest schauen wie COM0COM das macht.
Gehen tut das allgemein. Ist nur Aufwand wie Sebastian schön schrieb. Wenn Du dagegen nur mithören möchtest, dann mach einfach eine serielle Schnittstelle auf und häng sie parallel. Je nach Protokoll auch an beide Leitungen, per Dioden entkoppelt.
Michael P. schrieb: > Die Anfrage kann aus diversen Gründen nicht mehr in die ursprüngliche > Software implementiert werden Dann geht es auch nicht, das Problem ist nur lösbar wenn ein entsprechendes Protokoll mit Umschaltung der Quelle in beiden beteiligten Softwaresystemen berücksichtigt wird. Nach deinen Aussagen hat aber die vorhandene Software die Schnittstelle exklusiv und dauernd. Da hilft nur eine 2. serielle Schnittstelle. Georg
Michael P. schrieb: > Die Anfrage kann aus diversen Gründen nicht mehr in die ursprüngliche > Software implementiert werden, ohne jetzt ins Detail gehen zu wollen.... Wenn es der selbe comPort ist wird es schwierig (wohl nur durch eine Art virtuellen comport der 2 clients erlaubt, spezial, spezial) Wenn es ein anderer comport ist geht das problemlos
georg schrieb: > Nach deinen Aussagen > hat aber die vorhandene Software die Schnittstelle exklusiv und dauernd. > Da hilft nur eine 2. serielle Schnittstelle. Doch. Lies Sebastians Antwort einfach noch einmal: Sebastian schrieb: > Wenn du das Protokoll verstehst, kannst du einen Treiber schreiben, der > einen virtuellen COM-Port für die alte SW simuliert. Die ist dann exklusiv und dauernd und nur virtuell.
Es gibt Software, mit der Du einen physicalisch vorhandenen COM Port auf 1 oder mehrere virtuelle Ports mappen kannst. Benutze ich gelegentlich zum "mithören". Allerdings gibt es dabei ggf. auch zu beachten, dass 1) sichergestellt werden muss, dass nur ein Programm sendet (zum gleichen Zeitpunkt) 2) Dein Hauptprogramm, was Du nicht mehr ändern kannst, durch die Antwort des Clients nicht verwirrt wird. Denn das Hauptprogramm sieht die Daten, die zurückkommen, ja auch. Das gleiche gilt natürlich auch andersrum... Dein Erweiterungsprogramm sollte so geschrieben sein, dass andere Antworten als die, die auf diesem WEge ausgewertet werden sollen, vernünftig ignoriert werden. Es gibt auch Möglichkeiten, RX und TX aufzusplitten und unterschiedlichen, virtuellen COM Ports zuzuweisen. Aber das in Deinem Fall vermutlich keine Option sein, weil dann Dein Hauptprgramm gar keine Daten mehr zurück bekommt.
Es stellt sich nur eine Frage. Reden die Software und der Ofen miteinander, oder nicht. Wenn JA, hast du ein Problem. Wenn EINE der Software-Programme aber nur still vor sich lauscht und das gehörte mit schreibt ist das kein Problem. Saug dir mal COOLTERM.exe runter, und hänge es auf den selben Port wie die reguläre Software. Und schau mal was da passiert. Ich habe das neulich für ein Projekt benutzt um des Serial-Monitor der Arduino-Oberfläche abzuhören während die IDE auch mithörte. Die IDE loggt den Monitor nicht. ;) Funktionierte einwandfrei.
Michael P. schrieb: > Ich habe einen Ofen, der eine rs232 Schnittstelle hat und von einem > win7-pc über die Schnittstelle gesteuert wird. Wäre vielleicht hilfreich das Protokoll genauer zu kennen, gibts ein pdf oder herstellernamen?
Sebastian schrieb: > Wenn du das Protokoll verstehst, kannst du einen Treiber schreiben, der > einen virtuellen COM-Port für die alte SW simuliert. > Angenommen du hast Windows: Du könntest schauen wie COM0COM das macht. Es geht auch ein bisschen einfacher: Deine neue SW muss kein Treiber sein - es reicht wenns eine normale Anwendung ist, die 2 COM Ports aufmacht, und alles was sie nichts angeht durchleitet. Einer der beiden COM-Ports ist dann der "echte", der andere geht über COM0COM zur alten SW. Das Problem liegt im "alles was sie nichts angeht" - was das ist kommt auf das Protokoll an, das da auf RS232 läuft. http://com0com.sourceforge.net/
Spontan kommt mir noch der Gedanke, dass man die Empfangsleitung auch noch parallel auf einen zweiten COM-Port legen könnte. Da kann man denn zwar nur hören, aber das reicht ja offensichtlich. Dieser zweite COM-Port könnte auch auf einem komplett anderen PC sein und nur bei Bedarf angeschlossen werden.
Du könntest auch ein RS232 zu TCPIP Http/Server Module an den Ofen schalten und deine anderen Teilnehmer greifen auf den Http Server zu.
Wow. Mit so vielen Antworten habe ich nicht gerechnet. Wenn ich das richtig zusammenfasse, dann ist mein Vorhaben nicht ohne weiteres Möglich. Insbesondere, da eine senden und empfangen erforderlich ist, so dass "einfaches" mithören auch nichts bringt. Danke für die zahlreichen Antworten!
Hallo, klar geht das. Du brauchst halt ein Tool, welches die Abfragen der beiden Programme getrennt aufnimmt und dann weiterleitet. Diese Tool braucht dann drei Schnittstellenverbindung. Eine "echte" zum Ofen und zwei virtuelle Verbindungen zur Software. com0com wurde ja schon genannt. Das Tool musst Du Dir halt schreiben. Ich habe z.B. folgendes Problem: Ein Log-Programm für das Funkgerät fragtkontinierlich z.B. Band, Betriebsart und Frequenz ab. Am Funkgerät gibt es nur eine EIA-232, sonst nichts. Nun brauche ich aber die Daten des Funkgerätes auch noch mal um mit einem Antennenkoppler zu sprechen. Dieser Koppler braucht eigentlich auch eine Verbindung zum Funkgerät. Koppler --> "echte" COM-Schnittstelle --> COM1 Funkgerät --> "echte" COM-Schnittstelle --> COM2 Zwei virtuelle COM-Ports. COM3 <--> COM4 Mein Tool "TRX-Connector" wird mit COM1, COM2 und COM3 verbunden. Dabei können diese individuell konfiguriert sein. Z.B. die eine mit 9600, und die anderen mit 19200 bd. Und was sonst noch so alles geht wie Stoppbits ... Das Log-Programm mit COM4. Nun werden die Abfragen die über COM1 und COM4 reinkommen, an COM2 durchgereicht. Die Antworten entsprechend wieder zurück. Da TRX-Connector das Handling der Daten übernimmt, kommt es auch zu keinen Konflikten. Möglich sind allerdings Time-Out Fehler, wenn die abfragende Software prompt eine Antwort möchte.
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.