Laden...

Senden über Com-Port: Bekomme bei bestimmtem (längeren) Befehl keine Antwort vom Gerät

Erstellt von Bartleby vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.741 Views
B
Bartleby Themenstarter:in
2 Beiträge seit 2011
vor 13 Jahren
Senden über Com-Port: Bekomme bei bestimmtem (längeren) Befehl keine Antwort vom Gerät

Hallo zusammen,

ich hab ein kleines Problem beim Ansteuern eines Geräte über Com-Port.

Folgendes Scenario:

Ich möchte ein Zugangskontroll-System ansprechen. Das ganze ist ein etwas älteres Gerät von Conrad.

Jetzt möchte ich einen neuen RF code einspeichern. Der Port wird initialisiert mit folgenden Einstellungen:

        port1.PortName = port;  
        port1.BaudRate = 57600;  
        port1.DataBits = 8;  
        port1.StopBits = StopBits.One;  
        port1.Parity = Parity.None;  
        port1.ReadTimeout = 200;  
        port1.WriteTimeout = 200;   

Nun möchte ich den Befehl zum Speichern zusammen mit dem neuen RF Code senden:

port1.Write(new byte[] {0x02, 0x46, 0x46, 0x53, 0x54, 0x30, 0x30, 0x32, 0x46, 0x38, 0x41, 0x36,
0x33, 0x32, 0x34, 0x38, 0x44, 0x41, 0x30, 0x34, 0x30, 0x04,},0,22);

Jetzt das Kuriose. Führe ich den Befehl aus passiert nix. Bekomme auch keine Antwort. Wenn ich jedoch im Hintergrund mitschneide was raus geht und rein kommt (z.B. mit Docklight) funktioniert es auf einmal einwandfrei. Wenn ich es über ein Terminalprogramm schicke gibt es auch keine Probleme. Kürzere Befehle z.B. wenn ich die Seriennummer auslesen will funktionieren allerdings mit meinem Programm.

Hat evtl. einer ne Idee für mich wo ich das Problem anpacken muss? Glaub ich hab ernsthaft ein Brett vorm Kopf im Moment. Das Internet konnte mir bisher auch nicht weiterhelfen.

Vielen Dank für eure Hilfe!

Gruß Sebastian

G
538 Beiträge seit 2008
vor 13 Jahren

Ich bin mir nicht ganz im Klaren darüber, wie das mit dem Comport aussieht und ob man das in .NET überhaupt beachten muss, aber wie ist das mit dem Empfangspuffer des Geräts? Kann es sein dass du es in Stückchen senden musst?

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

W
955 Beiträge seit 2010
vor 13 Jahren

Hi,

hast du es mal mit einem anderen Client versucht, Hyperterminal o.ä.?

B
Bartleby Themenstarter:in
2 Beiträge seit 2011
vor 13 Jahren

Das hab ich auch schon versucht, aber ist genau das gleiche Verhalten. Das Gerät was ich anspreche erwartet zu Beginn des Strings ein "stx" (0x02) und am Ende ein "eot" (0x04).

Wenn ich das Ganze stückchenweise schicke, sieht es beim Mitschneiden so aus, das egal wie schnell oder wie groß die Pakete sind, erst nach dem eot ne Reaktion kommt. Ohne Mitschneiden wie gesagt keine Reaktion.

185 Beiträge seit 2005
vor 13 Jahren

eventuell kann das Gerät die Zeichen nicht schnell genug lesen, und wenn du mitloggst, werden die Zeichen verzögert ausgegeben, und das Gerät kommt mit.

T
708 Beiträge seit 2008
vor 13 Jahren

Das Problem ist wahrscheinlich, dass du ein Carriage Return & LineFeed mitsenden musst.
Die beiden "Zeilenumbruch"-Zeichen werden z.B. vom Hyperterminal automatisch mitgesendet.

Für einen Sniffer sehen die ausgehenden Befehle identisch aus, aber es passiert einfach nix. (Kenne ich leider nur zu gut 😉 )

Ansonsten kannst du versuchen den Handshake zu setzen und herumprobieren welcher Typus erwartet wird. (Das sieht man nämlich ebenfalls weder im HyperTerminal, noch bei den meisten Sniffern)

Gruß
TriB

EDIT: Wer lesen kann....
Also da du schon schreibst, dass es nur beim Mitlesen eine Antwort gibt, ist es definitiv der Handshake.

U
1.688 Beiträge seit 2007
vor 13 Jahren

Hallo,

was passiert, wenn Du von Deinem Programm aus nicht alles auf einmal, sondern in "Bröckchen" von 5 Zeichen mit kurzen Pausen dazwischen schickst?