\section{Die Anwendung --- Automatisierung} Eine Vision, die mir schon lange vorschwebt, wäre, Roboter in der Industrie mit FORTH zu steuern. Nun ist es ja so, dass alle Roboterhersteller schon ihre eigene Programmiersprache etabliert haben, weil sie FORTH schlicht und ergreifend nicht kannten. Einen Standard wie z.B. "`IEC--61131"' für speicherprogrammierbare Steuerungen --SPS-- (der übrigens auch viele Jahre brauchte, um sich durchzusetzen und von Siemens immer noch mit einem eigenen Dialekt versehen wird) gibt es für Roboter nicht und die IEC--61131 setzt sich gar nicht oder nur zögerlich auf Robotern durch. Manch ein FORTH--Programmierer fragt sich jetzt sicher, was bedeutet "`IEC--61131"'. Den Standard hier darzulegen, wäre natürlich fehl am Platz, aber es bedeutet grob gesagt 5 Programmiermethoden für die Automatisierungstechnik mit: \begin{tabular}{@{}l@{~~(}p{4.5cm}} FUP, Funktionsplan & Signalverabeitung --- grafisch) \\ KOP, Kontaktplan & Relaisersatz --- grafisch) \\ AS, Ablaufsprache & Ablaufkonstrukte --- grafisch) \\ AWL, Anweisungsliste & Textsprache in UPN auf niedrigem Niveau) \\ ST, Strukturierter Text & Kreuzung aus Pascal, BASIC und ???). \\ \end{tabular} Die Idee in diesem Zusammenhang wäre jetzt, ein Open--Source--Project zu starten, welches anfangs einen Parser für FORTH schafft, der IEC--61131--Statements in FORTH umsetzen kann und damit eine programmierbare Logik (PLC), bzw. speicherprogrammierbare Steuerungen (SPS) zum Leben erweckt. Man könnte auch sagen, einen FORTH--Realtime--Kernel für unterschiedlichste Hardware und Plattformen zu erzeugen. Dieser ist dann natürlich auch für Roboter geeignet und könnte mit der "`Ummantelung IEC--61131"' Akzeptanz und Einsatz finden. Einen ersten Ansatz für dieses Thema habe ich in Anton Ertls Paket "`Gray"' gefunden. Gray bringt schon eine Menge mit, was erforderlich wäre. In Antons Beispielen findet sich eine kleine Pascal--Quelle, die mittels Gray auf FORTH umgesetzt wird. All dies beinhaltet jedoch einen nicht zu unterschätzenden Aufwand, denn Steuerungen müssen echtzeitfähig sein, Multitasking realisieren und eine Möglichkeit zum komfortablen Debuggen bieten. Peripherieanbindungen über Feldbusse, wie z.B. CANopen, ProFiBus, Sercos, Powerlink, etc., sind die Normalität und über 99,9 \% Zuverlässigkeit sollte nicht diskutiert werden. Prozesssicherheit und Zuverlässigkeit bringen unter Umständen die Notwendigkeit einer Zertifizierung mit sich, was in FORTH, entsprechend einem Vorschlag von Uli Hoffmann, jedoch bestens lösbar wäre. Darüber hinaus könnten aus der freien Software--Welt viele gute Dinge, wie z.B. Treiber in Linux, mit übernommen werden, FORTH kann an Stellenwert gewinnen und seine Potenzen für die Automatisierung ausspielen, denn dessen Nutzung bleibt ja nach wie vor offen und evtl. wächst dann sogar die FORTH--Gemeinde. Ausbaufähig für die Zukunft bliebe ein solches Open--Source--Project auf jeden Fall, denn es bleiben immer noch die grafischen Teile der IEC--61131, welche dann auch an den, ich nenne es mal FORTH--Realtime--Kernel, angebunden werden müssten. Ich möchte diese Überlegungen zur Diskussion stellen, denn ich nehme mal an, dass eine Sprache, welche nicht, oder nur wenig genutzt wird, sei diese noch so gut, über kurz oder lang zum Scheitern veruteilt ist. Eine sinnvolle Anwendung kann Referenzen bringen und natürlich auch wieder Input für FORTH selbst geben. Viele Dinge, wie z.B. die Objektorientierung etc., wurden schon diskutiert und realisiert, sollten diese aber in einem solchen gemeinsamen Open--Source--Project notwendig sein, dann werden diese realisiert und finden ihren Stellenwert. Nicht zuletzt könnte davon eine Fokussierung ausgehen, die die nun doch schon fast nicht mehr zu überschauende Vielfalt an FORTH--Systemen und Dialekten bündelt. Last but not least, richtige Knickarm--Roboter könnten schweißen, kleben, palettieren etc. ;-) \hfill Dezember 2006 / Gerd Franzkowiak