Daten von einem anderen Programm "auffangen" und verarbeiten

[schweindi]

ahso, ja
also wir verwenden ein Nokia CS-15 umts/gsm gateway und man muss die "telephone function of sim" erstmal einschalten, damit das ganze funktioniert.
Auszug aus AT-Commands Revision A:

Code:

Set phone functionality +CFUN
Command syntax: AT+CFUN=<functionality level>
AT+CFUN=0 (ähnlich: AT+CPOF - power off)
AT+CFUN=1 (start oder wenns schon gestartet ist modem reset)

ja ich habe gerade in hyperterm geschaut:
RI:10 - Readinterval?
RM:0 - Read Multiplier?
RC:0 - Read Konstante?
WM:0 - Write Multiplier?
WC:5000 - Write Konstante?

also wenn meine Annahmen stimmen, hat hyperterm kein read timeout oder? naja ich denke die Befehle sollten, wie du gesagt hast, nie mehr als 5 Sekunden brauchen -> ich mach Read: 5000 ReadIntervall: 10 und Write: 5000 - das sollte dann passen...

Danke für den Tipp, werde ich berücksichtigen. Ich probier das ganze umgeschrieben mal aus.

[schweindi]

So sieht der traffic am Port gerade aus:#

Code:

Software: AT
Modem: OK..
S: AT+CFUN=1
M: . ERROR (Timeout)
(so das wäre der "connect" teil)
wenn ich jetzt manuell weitere Befehle sende:
S: AT
M: AT+CFUN=1..+CFUN=1..OK..OK
S: AT+CNMI?
M: .
S: (irgendein Befehl)
M: AT+CNMI?..+CNMI=2,2,0,1,0..OK..OK
S: (irgendein Befehl)
M: .
usw usw

Wie man sieht, nachdem ich cfun=1 eingegeben habe, kam ein Zeichen nur . (= #13) und dann egal welchen Befehl ich verschickt habe, kam jeweils die Antwort auf den vorigen Befehl zurück... Da verstehe ich leider garnicht!
Was kann das bewirken?

P.S.: "at+cfun=1..+CFUN=1..OK..OK" mein Befehl wird als echo zurück gesendet, da ATE ein ist..

[shmia]

Du solltest dich nicht darauf verlassen, dass Antworten ein bestimmtes Timing haben.
Stattdessen würde ich das abschliessende #13 als Endezeichen betrachten.

Der Algorithmus sieht so aus:
Es gibt einen Empfangspuffer (string).
Bei jedem OnRead-Event werden die empfangen Daten zuerst an den Empfangspuffer angehängt.
Dann schaut man nach, ob im Empfangspuffer eine ganze Zeile steht indem man nach dem Endezeichen sucht. (*)
Die Antwort (inklusive Endezeichen) wird aus dem Empfangspuffer ausgeschnitten.
Dann wird die Antwort (ohne Endezeichen) einer Procedure übergeben die dann entsprechend reagiert.
Es könnte aber noch eine weitere Antwort im Empfangspuffer stehen; deshalb zurück zur mit (*) markierten Zeile.

[schweindi]

hmm ja das ist dann das prinzip vom TComPort, ich will es jetzt aber mit den methoden von synaser machen!

ich hab da etwas gefunden:

ComPort1.RecvBlock(timeout);
Das liest ja genau soviel aus, wie viel am anfang der zeile angegeben wird.
Mein Modem schickt zb:
Lenght:4 OK..
dh 4 = anzahl der elemente und soviel müsste er auslesen, das Problem ist nur, wenn ich das ausprobiere, und ich schreibe im Hyperterm "4 OK" dann bekomme ich nachdem ich "O" geschrieben habe einen "Out of memory error"!? das ist jetzt schon eigenartig

[shmia]

Zitat von schweindi:

...und ich schreibe im Hyperterm "4 OK" dann bekomme ich nachdem ich "O" geschrieben habe einen "Out of memory error"!? das ist jetzt schon eigenartig

Und wie schnell kannst du schreiben?
Ein kurze Pause zwischen dem O und dem K und schon kommt .RecvBlock() mit einem unvollständigem Ergebnis zurück.
Du musst dir klarmachen, dass du dich von einem Timeout ganz lösen musst.
Ob jetzt alle zwei Sekunden eine einziges Zeichen hereinkommt oder ob alle Zeichen auf einen Rutsch eintreffen darf für dein Programm keine Rolle spielen.

PS
habe gerade gesehen, dass es bei Synaser die Methode RecvTerminated() gibt.
antwort := synaser.RecvTerminated(5000, #13);

[schweindi]

ich habe tiomeout auf 20000 gesetzt - 20 Sekunden sollten reichen für mich

ich habe schon das Problem gefunden:
ich habe eingegeben: "4 OK" aber eig sollte es sein "0004 OK" da er ja 4 byte braucht.

Jetzt muss ich nur noch herausfinden, wie ich 4 in byte darstellen kann, da, wenn ich 0004 eingeben kommt als Wert 8755723296 und nicht 4 heraus!

[shmia]

Zitat von schweindi:

ich habe eingegeben: "4 OK" aber eig sollte es sein "0004 OK" da er ja 4 byte braucht.

Die 4 Bytes werden binär ausgewertet (siehe function TBlockSerial.RecvInteger).
Du kannst RecvBlock() daher so nicht verwenden.
Aber gehe mal einen Betrag zurück und lies noch mein PS.

[schweindi]

ah sorry, hab das nicht mehr gesehen... okay, na dann verwende ich das mal.
also das Modem antwortet mit "OK"+CR+LF dh endstring ist immer #10?

[schweindi]

okay, super funzt das alles jetzt.
Ich hab nur noch ein problem, das Modem sendet jeden Input als echo zurück. Wie kann ich diese Echos auslesen und somit aus dem Input löschen?

Gelöst! Jetzt will ich aber, dass sobald er auf dem Port Daten bekommt, etwas macht. Bei TComPort war das OnRxChar. Wie geht das hier mit dem? bzw wie kann ich es machen, dass sobald er etwas im Input hat, eine procedure ausgeführt wird?

[schweindi]

Alternative:
wäre es leichter das Windows Event: SERIAL_EV_RXCHAR zu verwenden und daraus ein (eigenes) Event zu machen.

Ich habe zwar noch nie Events selber gemacht, aber ich denke mir, irgendwo muss im Endeffekt doch auf ein Windows Event verwiesen werden. Z.B. in der TComPort Unit wird jedem Event property zugeschrieben und irgendwann kommt "If Assigned(TEVENT) then ... .DOStatus" also das ist bezogen auf Serielle Anschlüsse.
Aber ich sehe nirgendwo eine für mich verständliche Zuordnung, in der ein Windows Event irgendwie verwendet wird... also ist ein RxChar Event leicht selber machbar?