Forum: PC-Programmierung RS 232 mit zwei verschiedenen Software-tools ansprechen?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Michael P. (freakonaleash121)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Sebastian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Analyst (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Schlaumaier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Sebastian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

von DanVet (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Michael P. (freakonaleash121)


Bewertung
0 lesenswert
nicht lesenswert
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!

von hodoe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Holger D. (hodoe)


Bewertung
0 lesenswert
nicht lesenswert
hodoe schrieb:
> Ich habe z.B. folgendes Problem:

also, ich hatte das Problem ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.