Ansteuerung der seriellen Schnittstelle RS232

[MiR]

Aufgrund einer Diskussion zu Geräten mit serieller Schnittstelle https://www.mikroskopie-forum.de/index.php?topic=45907.0;topicseen erschien es mir nicht ganz falsch, einen etwas ausführlicheren Bericht über die Wiederinbetriebnahme von Geräten mit RS232-Schnittstelle zu posten. Insbesondere auch deshalb, da die Kommunikation in der Regel sehr einfach ist.

Um nicht komplett außerhalb der Forumsinteressen zu liegen, beschränke ich mich bei den praktischen Beispielen auf 2 Mikroskopheiztische und einen motorisierten XY-Tisch, bzw. auf die entsprechenden Steuergeräte.

Steuergerät/Heiztisch 1: Mettler  FP80 + FP82HT
Steuergerät/Heiztisch 2: Linkam TMS91/THM600
Steuergerät/XY-Tisch : Lang/Märzhäuser - MCL


Allgemeines

Klar, dass das Studium der Handbücher der erste Schritt sein sollte, da sie oft Angaben die die Ansteuerung skizzenhaft beschreiben, enthalten. Sehr oft, insbesondere in Handbüchern älterer Geräte, sind Beispiele für MS-Basic abgedruckt. Allerdings ist die Angabe solcher Informationen von Firma zu Firma und den Jahren unterschiedlich geregelt. Das die Online-Recherche dazu gehört ist eigentlich selbstverständlich, ich erwähne es nur weil sie gelegentlich Lösungen anderer Nutzer hervorbringt. Ach ja, und die Informationsbeschaffung bei den Firmen kann sich einfacher gestalten bzw. ergiebiger sein, wenn man seine ,,Dienstadresse" verwendet ...
Letztendlich steht und fällt aber die erfolgreiche (Wieder)-Inbetriebnahme eines Gerätes mit der Kenntnis der (Befehls-) Sequenzen.


Sequenzen (ASCII-Codes)

In der Regel einfache Zeichenfolge welche, besonders im Fall der Kommandos, meistens nur aus einem Zeichen bestehen. So wird beispielsweise das FP80, durch das Senden eines  ,,G" (47H), in den Grundzustand versetzt. Das war es, na gut nicht ganz, meist muss das Endekennzeichen 0DH (Carriage Return) (mit-) gesendet werden.


Kommunikation

Die Befehle (Funktionen) welche auf der Windows-API (MSDN) beruhen, die für eine Kommunikation benötigt werden, sind recht übersichtlich und der Programmaufbau kann (in der Regel) einfach gestaltet werden.
Im folgenden ein paar Programmzeilen, welche im wesentlichen aus 5 Funktionen bestehen:

Code Auswählen Erweitern

1)  dem Öffnen der Schnittstelle
Port = "\\.\COMx" // x= 1 - ...
ComHandle = CreateFile(Port, GENERIC_READ | GENERIC_WRITE, 0, Null, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, Null)

2)  Setzen der Kommunikationsparameter (Baudrate ...)
//set parameters.
  dcb.BaudRate = Baudrate       ' z.B. 9600 ,  nur einige Werte möglich, siehe Internet
  dcb.ByteSize = ByteSize          '  meistens 7 oder 8
  dcb.Parity = Parity                   ' 0 - 5 möglich, meistens NOPARITY = 0 oder EVENPARITY = 2
  dcb.StopBits = StopBit             ' 0 - 2 möglich, meistens ONESTOPBIT = 0
hResult = SetCommState(ComHandle, dcb)

3) Schreiben eines Befehls (Senden eines Kommandos an das Gerät)
hResult = WriteFile(ComHandle, SendePuffer, Length(SendePuffer),  NumberOfBytesWritten, Ovl)

4) Antwort des Gerätes lesen
hResult = ReadFile(ComHandle, EmpfangsPuffer, 4096, dwRead, Ovl)
Bei der Readfile-Funktion ist es meistens vorteilhaft diese in eine Schleife (bzw. gleichwertiges Konstrukt) einzubringen, um die Antwort komplett, auch im Fall einer Verzögerung, zu erhalten.

5) Schließen der Schnittstelle
hResult = CloseHandle(ComHandle)

Natürlich fehlt hier noch ein bisschen drum herum, aber der Kern des Programms ist dargestellt, und ohne Frage kann man ein solches Programm sehr viel umfangreicher aufbauen ...

Bei einfachem Kommunikationsprotokoll (z.B. softwareseitig ohne ,,Fehlercode"-Bildung und hardwareseitig ohne Handshake-Leitungen) müssen lediglich die Befehlszeichen (Sequenzen) für die verschiedenen Operationen vorhanden (publiziert) sein. Im einfachsten Fall (was eigentlich eher die Regel ist) wäre es das schon. Dann kann man mit modernen Programmen (Terminal-Programmen) diese "Codecs" übergeben und ausführen lassen, oder man schreibt sein eigenes Programm.

erstes Beispiel: Linkam-Steuergerät TMS91

Bei diesem Gerät ist diese einfache Implementierung gegeben, so ist z.B.  in den Ressourcen alle Angaben angegeben:
https://github.com/ptomato/REP-instrumentation/commit/78088d2c515288dd597fda512d49809efb3d9452
https://www.linkam.co.uk/archivemanuals

Im Forum gibt es übrigens einen Beitrag (,,Schmelzversuch p-Anisidin" von Thomas [Capovau] ) welcher doch sehr eindrucksvoll vor Augen führt, wozu es unter anderem gut sein kann, doch selber Hand anzulegen (zu können).
https://www.mikroskopie-forum.de/index.php?topic=4759.msg31816#msg31816

Ich zitiere mal aus dem Beitrag:
"Die Heiztische der Firma Linkam besitzen ... eine serielle Schnittstelle RS232. Dazu gibt es eine Software, welche in der Lage ist den Tisch zu steuern. ...das dieses Programm grauslig ist und ... neben der Geldausgabe noch mit unsäglichen Sicherheitsfeatures nervt. ...dazu klappt die Installation nicht immer und schon gar nicht problemlos. Am Ende .. muss man dann nochmal den Händler anrufen, welcher dann ... einen Key generiert, welcher die Software frei schaltet. Ein Wort: unsäglich!
Wer .. sein Mikroskop mit der Axiovision steuert, kann (aber) bei Zeiss ein in Zusammenarbeit mit Linkam produziertes Software-Modul kaufen, mit dem man sehr leicht und komfortabel den Heiztisch steuern kann. "
Anmerkung: Das ist zwar schön, aber eigentlich unbezahlbar..., zumindest für den Hobbyisten

zweites Beispiel: Lang/Märzhäuser – Steuergerät MCL

Ein besonders einfaches Beispiel, da sowohl die MCL-Beschreibung heruntergeladen werden kann, als auch eine Demo-Software, welche auch noch die Daten, welche über die Schnittstelle übertragen werden, in einem separaten Fenster anzeigt. Mehr dürfte kaum noch gehen ...

https://www.marzhauser.com/nc/de/service/downloads.html
Unter dem Link Downloads ist die Betriebsanleitung mit den Kommandos zu finden als auch die Software Win-Commander 32!

Auch auf der Seite von Lang sind Win-Commander-Versionen und eine API zu finden.
Diese Versionen habe ich aber nicht getestet!
https://www.lang.de/produktbereiche/lang-software/steuerungs-software/win-commander/
https://www.lang.de/produktbereiche/lang-software/steuerungs-software/lang-api/

drittes Beispiel: Mettler – Steuergerät FP80

Diese Gerät zeichnet sich dadurch aus, dass manche Tasten (bzw. Befehlsequenzen), in Abhängigkeit vom Programmablauf, eine mehrfache Bedeutung haben. Die Beschreibung für dieses Gerät befindet sich im Anhang. -> https://mse.engin.umich.edu/internal/procedures/mettler-fp-80-hot-stage/mettler-user-guide , ab S.79 (Appendix A)


Software-Spion

Ist die Software vorhanden (mal abgesehen vom Dateiträger, auf welchem sie sich befindet oder ob es ein 16Bit-Programm ist) gibt es die Möglichkeit, softwaremäßig oder hardwaregestützt, die Kommunikation zwischen Programm und Gerät aufzuzeichnen, um die Befehlssequenzen zu gewinnen.
Im Internet z.B. als ,,Serial Port Monitor" oder ,,RS232 Sniffer" zu finden. Als Software nutze ich ein kostenloses Tool, welches seit geraumer Zeit (200X) ein Microsoft-Werkzeug (Sysinternals) ist, und auf den Namen ,,Portmon" hört. Es gibt auch eine Version dieses Programms für 16Bit. Portmon zeichnet in der Regel auch die Kommunikationsparameter (Baudrate etc.) auf.


RS232 -> USB (2.0)

Sollte die Hardware-Kommunikation ohne Handshake auskommen (wie oben beschrieben der ,,heutige" Standard) ist eine einfache und preiswerte Umstellung auf USB mit einem RS232-USB-Wandler (,,LogiLink USB 2.0, Seriell Adapter" oder ,,RPI USB TTL Raspberry Pi - USB zu TTL", um mal zwei Exemplare zu nennen) machbar.
Bevorzugt benutze ich solche Wandler die einen Chip von FTDI haben. Die Programmierung (FTDI-API) dieses Chips ist auf der Homepage sehr gut dokumentiert. Eigentlich wird diese gar nicht benötigt, da auch eine Ansprache über die Windows-API (siehe Kommunikation) möglich ist. D.h., es muß nicht eine Zeile neu codiert werden bzw. die RS232-Terminal¬programme können weiterhin genutzt werden.
Da ja die benutzte Portnummer (Schnittstelle) bei USB variabel sein kann, will vielleicht doch noch Hand anlegen, um es etwas komfortabler zu haben. Mit wenigen Zeilen, mit Funktionen der FTDI-API, kann dann die Suche, z.B. per Namen des Wandlers, hinzugefügt werden. Für eine eindeutige Identifizierung wäre die Suche bzw. der Abgleich mit der ,,Device ID" bzw. ,,Hardware-ID"  natürlich besser... Für Details verweise ich hier auf die Dokumentation von FTDI.

Übrigens ist auch die Nachrüstung einer seriellen Schnittstelle (RS232) auch für moderne Computer weiterhin möglich.


Fertiges Terminal-Programm ...

Wer nicht selber programmieren möchte, kann natürlich die Sequenzen auch über ein Terminal-Programm senden.
Da gibt es einige, ich beziehe mich hier auf das Programm Mttty.exe von Microsoft zur seriellen Kommunikation, welches, sehr umfangreich, die Möglichkeiten der Programmierung der seriellen Schnittstelle aufzeigt und mit einem längeren Artikel daherkommt.
https://learn.microsoft.com/en-us/previous-versions/ff802693(v=msdn.10)?redirectedfrom=MSDN
Da der Link zu der Software nicht mehr funktioniert, einfach nach > mttty.exe < suchen. Bzw., auf der Seite https://github.com/bmo/mttty gibt es eine leicht geänderte Version für das Kompilieren mit VC 2017.


Daten-Prüfsumme (CRC)

Diese ,,aufwändigere" Datenübertragung ist mir immer dann begegnet, wenn die Schnittstelle nicht nur für RS232 ausgelegt ist, sondern, u.a., auch für RS585.  Prinzipiell handelt es dabei um das Hinzufügen einer Prüfsumme, welche aus den eigentlich zu übertragenden Daten gewonnen wird. Die Art der Gewinnung kann unterschiedlich sein, deshalb lediglich der Verweis auf den Wikipedia-Eintrag ,,Zyklische Redundanzprüfung". Sicherlich kann die Analyse, bei Unkenntnis des genauen Verfahrens, eine Herausforderung darstellen.
Beispiele für solche Geräte sind: Eurotherm-Regler 902x, Jumo-Regler dTron 16.1 der JUMO GmbH & Co. KG, PTPx-Regler von Perkin Elmer Inc., TEC-Controller TEC 1xxx der Meerstetter Engineering GmbH


Viele Grüße aus Berlin
Michael

[A. Büschlen]

Hallo Michael,

besten Dank für deine hilfreichen Hinweise. -

Gruss Arnold Büschlen

Vielleicht einmal mehr per PN.

[MiR]

Hallo Arnold,

gern geschehen, bei Fragen/Bemerkungen melde dich einfach.

Viele Grüße aus Berlin
Michael

[MiR]

Nachtrag:

Verbindung von Gerät und PC

Generell unterscheidet man die Kabel eigentlich nur nach ,,seriellem Kabel" und ,,Nullmodemkabel", https://de.wikipedia.org/wiki/RS-232. Wobei das serielle Kabel (mind. gekreuzte Leitungen für Txd und Rxd) für die Verbindung von Gerät und PC konzipiert ist. Leider gibt es aber durchaus mehrere (serielle) Kabel, welche sich leicht in der Belegung unterscheiden können. Abgesehen davon, meinen manche Geräte-Hersteller sie müssten die Vielfalt noch ein wenig erhöhen und ihre eigene Belegung festlegen. Da ist es immer gut, wenn man wenigstens die genaue Belegung (aus dem Handbuch) kennt, und die Belegung prüfen kann.
Inwieweit man sich an den Hardware-Baustein herantasten kann, ist mir unbekannt, vielleicht helfen die Hinweise im Beitrag ,,Serielle Kommandos für Mikroskope der Leica MZ Serie", Antwort #6, https://www.mikroskopie-forum.de/index.php?topic=46417.msg343039#msg343039 etwas.

RS232 wirklich installiert ?

Öfter ist die Schnittstelle lediglich optional verfügbar, also noch gar nicht installiert. Das ist manchmal schwer zu erkennen, da eine Beschriftung am Gehäuse vorhanden sein kann, die Buchse verbaut ist und auch die Verkabelung zwischen Buchse und Leiterplatte schon ausgeführt ist. Das kann sogar soweit gehen, dass die Einstellungen für die Schnittstelle formal vorgenommen werden können.

Viele Grüße aus Berlin
Michael

[aga_peter]

Hallo zusammen,

ich habe beruflich schon zig Geräte via RS232 ansteuern müssen. Das Thema ist recht komplex. Das fängt schon mit der Konfektionierung der Kabel, der Pinbelegung, dann kommen diverse Parameter der seriellen Schnittstelle dazu und schliesslich landen wir bei den Softwareprotokollen/Commandsets. Bei den Protokollen kommt alles mögliche vor, von ganz einfach bis recht komplex.
Hier wurde schon viel gesagt, ich möchte mit Euch noch Folgendes mit Euch teilen:

 - zum testen der Kommunikation haben wir die freie Software Hercules Setup Utility benutzt. Diese kann übrigens auch TCPIP und andere Protokolle. Der Vorteil ist auch, dass man die Software nicht installieren muss. Die Software ist sehr mächtig und man kann damit wirklich sehr viel machen (inkl Anzeige in Hex, etc...)

- zum Mitschneiden der Kommunikation und für reverse Engineering haben wir gerne statt einer Softwarelösung auf die Hardwarelösung gesetzt. Dazu haben wir ein serielles Y-Kabel genutzt und an einem freien Port die Kommunikation geloggt/abgehört (zb mit dem o.g. Hercules utility). Funktioniert prima. Im Netz gibts Anleitungen wie man so ein Kabel selber herstellen kann.

 - wir haben immer wieder Probleme mit den verbauten seriellen Ports gehabt, speziell bei neueren Rechnern. Die Lösung war meistens der Einbau einer Karte mit 1-2 RS-232 Ports

 - USB-RS232 Konverter machen gerne Probleme. Bei Bedarf einen guten Konverter benutzen (zb von Moxa uport 1110 mit einem Port. Kostet um die 50 Euro, aber noch nie Probleme gehabt. Alternativ gibt es TCPIP-RS232 Konverter, für private Zwecke würde ich das abe nicht machen.

 - Checksummenberechnung: sind nicht sehr häufig anzutreffen, die können aber einem das Leben schwer machen. Hier gibt es nichts, was es nicht gibt. Hierzu braucht es zwingend den Algorithmus/die Beschreibung vom Hersteller.

Gruss
Peter