Serielle Schnittstelle überwachen!

[R2009]

Hi Alle,

ich möchte den Bitstream der RS232 Schnittstelle auf einem PC überwachen.

Problem:
ein Java Tool kommuniziert mit einem entfernten Gerät über GSM.
Kann ich mich irgendwie in den Datenstrom einlinken und sehen was da läuft?

Vielen Dank im Vorraus!

[Muetze1]

Hi Einer,

Benutze PortMon.

Bitte nachträglich!

[R2009]

Hi auch Einer,

das nützt mir nichts, ich brauche das Ganze eingebunden in Delphi!

Viele Grüsse!

[R2009]

Hi,

hat keiner eine Ahnung wie man sowas macht. Ich brauche eigentlich nur einen Ansatz.
Oder gibts vielleicht eine Komponente?

Viele Grüsse!

[dusty]

Ich denke, dass immer nur 1 Anwendung auf die serielle Schnittstelle zugreifen kann, so dass es nicht möglich sein wird, sich dazwischen zu hängen. Eine gute Komponente ist SerialNG von DomIS. Guckst Du hier:
http://www.domis.de

Kannst Dir die Komponente mit einigen Beispielen dort downloaden.

[Nersgatt]

Das Portmon, das oben verlinkt wurde, funktioniert ganz wunderbar. Ich habe es heute morgen mit einem Scanner getestet. Man muss nur zuerst Portmon starten und dann die eigentliche Anwendung (ich habe es mit TuTTy ausprobiert) -> läuft perfekt. Muss also irgendwie möglich sein.

Edit: Auch wenn PortMon nicht das ist, was Du suchst, wenn Du dem Link oben folgst, findest Du unten einen Absatz "How it works" wo prinzipiell beschrieben steht, wie PortMon arbeitet.

[R2009]

Hi Nersgatt,

ich benutze Asynchpro. Eine Komponente für die serielle Kommunukation hab ich also schon.

Grüsse

[R2009]

Ok,

habs genauer durchgelesen. Das ganze überfordert mich zur Zeit etwas. Verstanden hab ich schon einigermassen was Portmon treibt.
Kanns mir trotzdem nochmal jemand etwas genauer erklären?
Vor allen Dingen seh ich mich ausser Stande das selbst umzusetzen.

Zitat:

When you select a port to monitor, Portmon sends a request to its device driver that includes the NT name (e.g. \device\serial0) that you are interested in. The driver uses standard filtering APIs to attach its own filter device object to the target device object. First, it uses ZwCreateFile to open the target device. Then it translates the handle it receives back from ZwCreateFile to a device object pointer. After creating its own filter device object that matches the characteristics of the target, the driver calls IoAttachDeviceByPointer to establish the filter. From that point on the Portmon driver will see all requests aimed at the target device.

Er schreibt da "sends a request to its device driver...."
Das bezieht sich doch sicher auf den Treiber der seriellen Schnittstelle oder?

Vielen Danj im Vorraus!

[chrisw]

Ich habe so etwas vor Jahren mal "gebaut" !


Aufbau war wie folgt:

1. Daten mit Asyncpro auf der Seriellen-Schnittstelle empfangen.
2. Daten in einem Memo ausgeben und weiterleiten an einen virtuellen Port (siehe hier) z.Bsp. über TCP .
3. die Software, die eigentlich die Daten bekommen soll auf denvirtuellen Port konfigurieren.


Hoffe ich konnte helfen

Chris

[DerDan]

Zitat:

Zitat von chrisw

Ich habe so etwas vor Jahren mal "gebaut" !


Aufbau war wie folgt:

1. Daten mit Asyncpro auf der Seriellen-Schnittstelle empfangen.
2. Daten in einem Memo ausgeben und weiterleiten an einen virtuellen Port (siehe hier) z.Bsp. über TCP .
3. die Software, die eigentlich die Daten bekommen soll auf denvirtuellen Port konfigurieren.


Hoffe ich konnte helfen

Chris

So was ähnliche hab ich auch schon mal gebastelt. Es gibt virtuelle Com Ports, bei denen man die Daten abgreifen kann.

http://com0com.sourceforge.net/

suche dort mal nach "HUB for COM ports" damit kann man dein Problem eventuell lösen.
Kommt natürlich darauf an ob dein Programm nur einmal läuft (z.B für Debug) oder auf vielen Rechnern,
dann wurde ich nicht unbedingt eine virtuellen Port installieren wollen.

mfg DerDan

[R2009]

Hi,

vielen Dank. Das bringt mich sehr viel weiter. Hab mir sowas ähnliches schon gedacht.
Sollte ich in absehbarer Zeit zu einer Lösung kommen werde ich das hier publizieren.


Danke!

[R2009]

Hi,

ich hab's. Basierend auf der Lösung für Virtuelle Com Ports habe ich eine Lösung gefunden.
1.) Com0com installiert (liegt im Anhang bei).
2.) In Com0com Com4 <--> Com5 parametriert.
3.) Mein Programm Comcom transportiert die Daten von Com5 auf Com3 und macht diese Daten sichtbar.
an Com3 muss das Modem oder das Gerät angeschlossen sein.
4.) Das sendende Programm habe ich auf Com4 umgestellt.
Damit gibt es eine geschlossene Verbindung zwischen dem sendenden Programm und dem Modem.

Das einzige Problem was ich jetzt noch habe:
die seriellen Schnittstellen im Programm wechseln die Baudrate nicht wenn eine Modemverbindung zustande kommt.
Krieg ich aber auch noch hin.
Die Com Schnittstellen im Programm sind mit Asynchpro erstellt.

Die Lösung ist eigentlich ganz trivial und einfach.
(Für die Schlaumeier und Besserwisser: das Programm ist im Hauruckverfahren entstanden. So siehts auch aus)

Vielen Dank und Grüsse an alle die mir geholfen haben!

[R2009]

Hi,

das Problem ist so nicht lösbar! ich muss irgendwie an die Übergabe Programm serielle Schnittellentreiber ran.
Bei meinem Problem wird die Baudrate gewechselt ohne dass ich irgendwie feststellen kann auf welche.
Man müsste doch irgendwie erreichen können, dass man ohne Umweg über virtuelle serielle Schnittstellen ans Ziel kommt.

Vielen Dank im Vorraus!

[Reinhard Kern]

Zitat:

Zitat von R2009

Hi,

das Problem ist so nicht lösbar! ich muss irgendwie an die Übergabe Programm serielle Schnittellentreiber ran.
Bei meinem Problem wird die Baudrate gewechselt ohne dass ich irgendwie feststellen kann auf welche.
Man müsste doch irgendwie erreichen können, dass man ohne Umweg über virtuelle serielle Schnittstellen ans Ziel kommt.

Vielen Dank im Vorraus!

Hallo,

habe mich schon gewundert, als du deine Lösung so begeistert beschrieben hast. Die (wahrscheinlich einzig korrekte) Lösung ist ein Filtertreiber, bzw. nach MS layered driver, also ein Treiber, der auf einen vorhandenen Treiber für die COM-Schnittstelle aufsetzt. Die Daten werden also durchgereicht Anwendung - Filtertreiber - COM-Treiber - Leitung bzw. umgekehrt. Aber das ist halt Treiberprogrammierung ohne wenn und aber. Mit den entsprechenden SDKs und Visual Studio aber durchaus lösbar.

Ich hatte das Problem bisher nicht, weil ich einen Schnittstellenanalysator vom Hewlett Packard habe, der alles auf den Datenleitungen anzeigt und überprüft. Der kostet allerdings mehr als ein Auto mit Abwrackprämie und löst dein Problem sowieso nicht. Equivalent wären 3 zusammengeschaltete Com-Ports: eines für die Funktion und 2 zur Überwachung (weil man TxD und Rxd überwachen muss, indem man sie an ein RxD eines anderen Comports anschliesst). So funktionieren Schnittstellenanalysatoren für Notebooks, bloss kriegt man keine Notebooks mehr mit 2 COM.

Gruss Reinhard