RS232,RS485 in mseide

[Theozh]

Hallo,
bin gerade dabei, mir mseide anzuschauen...
Mit Lazarus hatte ich für die Benutzung der Seriellen Schnittstelle synaser verwendet.
Wie ich sehe, gibt es dafür in mseide tcommport und tasciicommport.
Gibt es da Minimalbeispiele?
Bin ohne Tutorial oder Beispiel leider (noch) nicht so fit, den Sourcecode zu entziffern und die passenden Prozeduren herauszufiltern...
Letztendlich ist es ja immer das Gleiche: Initialisieren, String senden, String empfangen.
Vielen Dank, Theo.

[mse]

Im tab 'Comm' gibt es dafür mehrere Komponenten. Die direkt auf die Schnittstelle arbeitenden tcommport, tasciicommport und tasciiprotport welche zur Abwicklung von Protokollen und auch für halbduplex Bus-Betrieb verwendet können (z.B. habe ich damit auch schon Modbus gefahren), dann die neueren auf dem pipe interface beruhenden tsercommcomp, tsercommchannel, tasynsercommchannel.
Ein Beispiel für tsercommcomp ist hier:
https://gitorious.org/mseuniverse/mseun ... tion/rs232

Code: Alles auswählen

 
procedure tmainfo.clearexe(const sender: TObject);
begin
 rxdata.clear;
end;
 
procedure tmainfo.portsetexe(const sender: TObject; var avalue: commnrty;
               var accept: Boolean);
begin
 port.port.commnr:= avalue;
end;
 
procedure tmainfo.setactiveexe(const sender: TObject; var avalue: Boolean;
               var accept: Boolean);
begin
 port.active:= avalue;
end;
 
procedure tmainfo.sendtextexe(const sender: TObject; var avalue: msestring;
               var accept: Boolean);
begin
 port.pipes.tx.write(avalue+eor.value);
end;
 
procedure tmainfo.inputavaileexe(const sender: tcustomcommpipes);
var
 str1: string;
begin
 str1:= sender.rx.readdatastring;
 rxdata[0].readpipe(str1);
// rxdata[0].readpipe(sender.rx); //direct alternative
 
 rxdata.showrow(bigint); //show last row
end;
 

Verbinde mal 2 und 3 der Schnittstelle und teste, ob die Daten wieder zurück kommen.

[Theozh]

Vielen Dank für das Beispiel.
Leider funktioniert es nicht auf Anhieb. Habe für die Kommunikation ein Messgerät mit RS232 angehängt.
Ich vergaß zu erwähnen: Windows und ein USB-RS232 Adapter sind mit im Spiel. Aber das sollte eigentlich nichts ausmachen, oder etwa doch?
Das USB-Gerät wurde als COM16 erkannt. Auch nachdem ich es in COM2 geändert habe, kein Erfolg. Das Beispiel schlägt mir "3 COM3" als Auswahl vor, obwohl es kein COM3 gibt.
Es kommen die Meldungen: "Invalid commnr: -1" oder "stream write error".
Woran liegt's?

[mse]

USB-RS232 können schon zu Problemen führen. COM16? Dann ändere versuchsweise lib/common/serialcomm/msecommport.pas:937

Code: Alles auswählen

 
  fhandle:= createfile(pchar(commname[fcommnr]),
 

auf

Code: Alles auswählen

 
  fhandle:= createfile(pchar('COM16')),
 

Edit: tcommselector schlägt nur ports vor, die es auch öffnen kann. Da muss ich das demo ergänzen, dass der möglicherweise bereits geöffnete port vor dem dropdown geschlossen wird, sonst erscheint er bei der Auswahl nicht.
Edit2:
Gemacht, git master 80e3cb5d315f82ec7a0b43b5efd120c193a70799.
Hast du git bereits installiert? http://git-scm.com/

[Socke]

Code: Alles auswählen

 
  fhandle:= createfile(pchar('COM16')),
 

Unter Windows gibt es spezielle Dateinamen nur für die COM-Ports bis einschließlich Nummer 9. Danach muss man den vollständigen Dateinamen angeben: \\.\COM16 http://support.microsoft.com/kb/115831

[mse]

1 bis 9 lassen sich mit tcustomrs232.comnr einstellen. Für alle übrigen Fälle werde ich eine Eigenschaft commname einbauen. Danke für den Hinweis.

[Theozh]

auch mit COM2 tut's nicht. So wie es scheint, wird der COM-Port irgendwie "vermurkst", ich vermute nicht geschlossen?!
Der einzige Weg, das zu beheben, scheint mir ein Rechnerneustart. Oder kennt jemand einen anderen Weg, in Windows einen offenen Port zwangsweise zu schliessen bzw. freizugeben?

[mse]

Wenn der COMn Name in der Dropdownlist erscheint, konnte er geöffnet werden. Ich bin daran die Commwahl nach Sockes Tip zu implementieren. Danach kannst du auch mit dem gewohnten COM16 arbeiten. Hast du git auf deinem Rechner installiert?

[mse]

Für alle übrigen Fälle werde ich eine Eigenschaft commname einbauen.

Gemacht. \\.\COM1 in 'Port' eingetragen funktioniert bei mir. Ich hoffe \\.\COM16 spricht dein USB-RS232-Interface an.
Wie man die MSEide+MSEgui Entwicklerversion beschafft steht hier:
http://www.lazarusforum.de/viewtopic.php?f=53&t=7276
Bitte klone auch git@gitorious.org:mseuniverse/mseuniverse.git um das geänderte Demoprogramm zu erhalten.

[Theozh]

Vielen Dank für Deine Mühen.
git usw. scheint zu laufen.
Mit dem RS232 Beispiel kann ich das Messgerät nun ansprechen. Es schaltet zumindest schon mal in den Remote-Modus
Doch eine Antwort bekomme ich leider nicht zurück.
Auf den String "*IDN?" sollte ich eine Antwort "Keithley 2000 ..." erhalten.

Dafür kommt am Gerät der Fehler +800, laut Fehlercodetabelle: "RS-232 Framing Error detected"
Was das wohl heißen soll?

[mse]

Dafür kommt am Gerät der Fehler +800, laut Fehlercodetabelle: "RS-232 Framing Error detected"
Was das wohl heißen soll?

Was erwartet das Gerät als EndOfRecord Marker? Die entsprechen Bytes können im Demo in 'EOR-data' als HEX-Code eingetragen werden.

[Theozh]

es wird LF erwartet... das ist doch 0A

[mse]

es wird LF erwartet... das ist doch 0A

Ja. Framing error könnte auch fehlendes Stopbit bedeuten. Stimmen Baudrate, Parity und Anzahl Stopbit?

[mse]

Es gibt nun in mseuniverse drei Demos, sie benötigen die aktuelle git master
MSEgui Version:

1. rs232direct, tsercommcomp mit options sco_nopipe.
- funktioniert ähnlich wie Synaser und läuft vielleicht mit USB.
- es werden zyklisch die eingetroffenen Bytes abgeholt.

2. rs232, tsercommcomp ohne options sco_nopipe.
- Hier wird ein zweiter thread erstellt, der auf ankommende Daten wartet. Dies
führt vermutlich zu den Problemen mit USB.
- Vorteil: die Daten werden an das Hauptprogramm gesendet, das Hauptprogramm
muss nicht warten und nicht zyklisch abfragen.

3. commchannel, tsercommcomp ohne options sco_nopipe mit zusätzlicher
tasynsercommchannel Komponente.
- tasynsercommchannel stammt von einer Kommunikations-Basis-Komponente ab,
welche auch für Socket Verbindungen verwendet wird und das Einhängen von
Verschlüsselungs- Kompressions- und Protokollhandlern erlaubt.
- Hier erhält das Hauptprogramm nur vollständige Telegramme oder
Statusmeldungen (z.B. timeout). Hier arbeitet der gleiche Empfangsthread wie
bei 2., darum erwarte ich ebenfalls USB-Probleme.

Es gibt noch eine weitere Möglichkeit mit den grauen Komponenten tcommport,
tasciicomport, tasciiprotport. Hier lauft ebenfalls ein separater thread.
Dieser hat eine queue, wo Kommunikationsauftragsobjekte aufgegeben werden
können. Sie werden dann der Reihe nach abgearbeitet und die mit den
empfangenen Daten beladenen Objekte ans Hauptprogramm zurückgereicht. Dieses
System verwende ich z.B um Busteilnehmer asynchron anzusprechen. Das könnte
eventuell ebenfalls mit USB funktionieren, ist aber zur Programmierung
aufwändiger.

[mschnell]

2. rs232, tsercommcomp ohne options sco_nopipe.
- Hier wird ein zweiter thread erstellt, der auf ankommende Daten wartet. Dies
führt vermutlich zu den Problemen mit USB.

Warum sollte das zu Problemen führen ? Ich verwende ständig AsyncPro (mit Delphi 2006). Das funktioniert genau so und es gibt keine Probleme mit USB.

-Michael