[gelöst] RS232 mit DTR & RTS und Synaser

[Theozh]

Hallo nochmals,

nachdem ich nun einige Geräte über RS232 und RS485 ansprechen konnte, habe ich nun ein Gerät das sich mit Synaser nicht ansprechen lassen will.

Dieses Gerät verlangt chr(6) als Termination-Character.

Code: Alles auswählen

 
ser:=TBlockSerial.Create;
ser.Connect('COM1');
ser.config(19200,8,'N',SB1,false,false); // BaudRate, Bits, Parity, StopBits, SoftFlow, HardFlow
ser.SendString(Command + chr(6));
Result := ser.RecvTerminated(1000, chr(6));
 

Es kommt keine Reaktion.
Mit dem Terminal-Programm HTerm.exe habe ich nun herausgefunden, dass ich mit diesem Gerät nur erfolgreich kommunizieren kann wenn ich in HTerm.exe die Knöpfe DTR und RTS setze/aktiviere.

Wie mache ich das mit Synaser?
ser.DTR:=true;
ser.RTS:=true;
Immer noch keine Rückmeldung. Was mache ich falsch?
Mit dem gleichen Code (ohne DTR und RTS) kann ich aber andere Geräte ansprechen.
Danke für Tipps,
Theo.

[do-while]

Die Leitungen DTR (Data Terminal Ready) und RTS (Request To Send) sind Handshake-Leitungen, die nicht einfach statisch eingestellt werden, sondern den Zustand der Übertragung anzeigen sollen. Hast Du mal geprüft, was Dein Terminalprogramm damit macht, wenn Du das einstellst? (z.B. mit einem Oszilloskop).
Was braucht der Schnittstellenkonverter für Signale? Häufig verwenden Konverter für eine 2-Draht-RS485 eine Handshakeleitung (DTR oder RTS) um den Transmitter ein oder aus zu schalten. Bei Deinem ser.DTR := true wärst Du dann immer im Sendebetrieb oder immer im Empfangsbetrieb, beides auf die Dauer nicht so richtig förderlich.

Auf http://www.kksystems.com/german/html_fi ... ontrol.htm findest Du eine Beschreibung zu den Signalen. Das Ganze ist aber vom verwendeten Konverter anhängig, die Signale können auch invertiert gebraucht werden oder statt RTS die DTR-Leitung.

Außerdem gibt es Konverter, die Deinen gesendeten Frame als Echo empfangen und andere machen das wiederum nicht. Bei Echo musst Du dann nämlich erst deine Bytes aus dem Empfangsbuffer wegwerfen, bevor Du die Antwortbytes erhälst.

Vielleicht kann man noch genauere Tipps geben, wenn Du die Geräte- und Konvertertypen postest.

[Theozh]

Das Gerät ist ein Inficon IC/5 Schichtdickenmessgerät. Der Konverter ist ein Prolific USB-RS232 Konverter.
Es kann aber defintiv nicht am Schnittstellen-Konverter liegen, denn über das Terminal Programm "HTerm.exe" k a n n ich mit dem Gerät über RS232 kommunizieren.
Vielmehr müsste man wissen, was HTerm.exe genau macht. Damit es funktioniert muss ich die Knöpfe "DTR" und "RTS" aktivieren. Bei der Kommunikation mit anderen Geräten darf ich sie nicht aktivieren.
Der Befehl, den ich senden muss lautet z.B. "H" + chr(6) oder in Dezimal 72 06. Als Antwort bekomme ich "Inficon IC/5 Ver 2.3" + chr(6) zurück.
Aber eben mit Lazarus/Synaser will das nicht gelingen...

[mschnell]

Der Konverter ist ein Prolific USB-RS232 Konverter..

Bei manche USB/RS232 Wandler haben die Hardware und/oder die Treiber (für das verwendete OS) Probleme die Steuerleitungen zu setzen und/oder zu lesen. Das kann auch darin gipfeln, dass es "manchmal geht und manchmal nicht". RTS/CTS können bei entsprechender Konfiguration beispielsweise zum Buffer-Handling "automatisch" von der Hardware behandelt werden, ohne dass die Software sie explizit schaltet.

-Michael

[Theozh]

aber die Hardware, PC, Gerät, Konverter, Treiber ist doch alles identisch. Der einzige Unterschied ist die Software.
Mit HTerm.exe geht's, mit Synaser nicht. HTerm.exe verwendet doch keinen anderen Treiber?!
Dann müssen es doch ganz klar irgendwelche Einstellungen in Synaser sein! Oder liege ich da falsch?

[Heinrich Wolf]

...

Code: Alles auswählen

 
...
ser.config(19200,8,'N',SB1,false,false); // BaudRate, Bits, Parity, StopBits, SoftFlow, HardFlow
...
 

...
Mit dem Terminal-Programm HTerm.exe habe ich nun herausgefunden, dass ich mit diesem Gerät nur erfolgreich kommunizieren kann wenn ich in HTerm.exe die Knöpfe DTR und RTS setze/aktiviere.

Wie mache ich das mit Synaser?
...

DTR und RTS sind HardFlow
Versuch's mal mit

Code: Alles auswählen

 
ser.config(19200,8,'N',SB1,false,true); // BaudRate, Bits, Parity, StopBits, SoftFlow, HardFlow
 

[do-while]

Hast Du denn schon mal mit einem Portmonitor nachgesehen, ob wirklich diese Bytes über die Leitung gehen?
Ein Byte 06 als Schlusszeichen ist absolut unüblich, und ich habe sonst schon viele Schnittstellen gesehen.
Die 06 könnte z.B. aber eine Prüfsumme sein.

Einen kostenlosen Portmonitor für PC gibt's hier: http://www.serial-port-monitor.com/free ... loads.html
Damit kannst Du auch mühelos die Original-Software belauschen

Du solltest 3 Dinge klären:
1) Welche Bytes gehen wirklich über die Leitung?
2) Stimmen denn die Übertragungsparameter überhaupt? Oder gibt es ein Parity?
3) Wie stehen die Handshakeleitungen in Ruhe und bei Kommunikation?

[Theozh]

Hallo Hagen,
danke für Deine Tipps.
Ja, das Schlusszeichen ist ganz sicher chr(06) und kein Prüfzeichen. Ich habe bis jetzt noch nicht allzuviele Schnittstellen gesehen, aber bislang noch keine zwei gleiche
Danke für den Link. Werde den Portmonitor mal ausprobieren, denn ein Oszi habe ich nicht gerade zur Hand.
Parity ist "none". Baudrate etc. stimmt.
Ja, ich vermute sehr, dass es an den Handshakes liegt. Softflow, Hardflow, Xon/Xoff, DTR, RTS, CTS,... damit wollte ich mich eigentlich gar nicht so genau beschäftigen, muss ich aber nun wohl. Schaden tut's nicht, aber unnötig viel Zeit brauchen tut's.
Melde mich wieder.
Theo.

[Theozh]

@Heinrich.
Ich bin mir ziemlich sicher, dass ich diese Kombination auch schon probiert habe und es nicht funktioniert habe. Werde es nochmals testen.

[Theozh]

hmm... sehr speziell. Nun funktionierts mit

Code: Alles auswählen

 
ser.config(19200,8,'N',SB1,false,true); // BaudRate, Bits, Parity, StopBits, SoftFlow, HardFlow
 

Vielleicht war die Schnittstelle zum Testzeitpunkt "vermurkst" und nun nach PC-Neustart wieder i.O. oder durch das andere Terminal-Programm blockiert oder sonstige Parameter in der Geräte-.ini Datei falsch...

Hilfreich zur Fehlereingrenzung ist übrigens noch folgende Property:

Code: Alles auswählen

 
var SerialActive: Boolean;
  SerialActive:= ser.InstanceActive;
  if not (SerialActive) then ShowMessage('No connection to serial device');