erstes Beispiel

erstes Beispiel

Inhalt

1 Ein Beispiel

Topic=.Java2C.Sample1.

Folgend ist ein Beispiel einer Anwendung für Java2C gezeigt. Das Beispiel ist wie folgt aufgebaut:

  • In einem Package vishia.exampleJava2C.java4c befinden sich diejenigen Klassen, die in schneller Echtzeit laufend in C implementiert werden sollen. Einstieg dafür ist javasample:_org/vishia/exampleJava2C/java4c/MainController. Es handelt sich dabei um eine Regelung beispielsweise von Gleichstrommotoren über eine Weg-Geber und einen von einem Führungswertgenerator vorgegbenem Weg. Erstmal ist nur ein Motor implementiert, das Beispiel soll dann ausgebaut werden auf eine Gleichlaufregelung beispielsweise mit dem Kriterium eines gleichmäßigen Zuges (von transportierten Papierrollen oder ähnlichem). Das ist komplex genug, um zu zeigen, dass eine Simulation der Algorithmen einen guten Beitrag liefern könnte. Hier ist Java geeignet.

    Das Beispiel soll dann noch ergänzt werden um eine Vorgabe der Werte für den Führungswertgenerator aus einem übergeordneten Programm in Java. Typisch kann es sein, dass die langsame Echtzeitverarbeitung in Java auf einem PC erfolgt, mit allen java-typischen Dingen wie Grafische Bedienoberfläche, Kopplung in einem vernetzten System usw. Die Kommunikation zum schnellen Teil der Steuerung kann dann beispielsweise über Ethernet und UDP/IP erfolgen, Netzwerktreiber sind für embedded heute durchaus gängig. Aufträge sollen dann in eine LinkedList bereits im C-Teil der Steuerung gepuffert werden, um dann in schneller Abtastzeit die Motorbewegungen vorzugeben. Damit soll gezeigt werden, dass Funktionalitäten aus java.util ebenfalls in C präsent sein müssen. Die LinkedList ist in der CRuntimeJavalike bereits implementiert und als Produktivcode auch (woanders) bereits eingesetzt. Das Beispiel brauch aber noch etwas an Bearbeitungszeit (ein Zeit-Kapazitätsproblem).

  • Ein anderes Package vishia.exampleJava2C.emulationEnv enthält diejenigen Anteile, die für die Simulation der Algorithmen im Package java4c als Umgebung benötigt werden. Diese Anteile werden nicht nach C umgesetzt sondern dienen ausschließlich der Simulation auf Java-Ebene. Einstieg dabei ist javasample:_org/vishia/exampleJava2C/emulationEnv/MainEmulation, in dem auch main() enthalten ist.

  • Die konvertierten Algorithmen aus dem Package java4c sind dann in den C-Routinen (derzeit erst nur ../example/out/PID_controller.c, ziemlich viel noch TODO) anschaubar.

Der Translator Java2C arbeitet wie folgt:

  • Gemäß den Prinzipien von Zmake gibt es einen Steuerfile, der dasjenige Package auflistet, das konvertiert werden soll. Das Steuerfile wird nach einem ANT.xml-File konvertiert und abgearbeitet. (TODO, bisher einfacher batchfile).

  • Die *.java-Files werden mit dem ZBNF-Parser innerhalb des javasrc:_org/vishia/java2C/Java2C.java geparst und danach konvertiert. Ergebnis sind die dargestellten C-Files.

1.1 Ablauf der Simulation im Beispiel

Topic=.Java2C.Sample1..

Bild: Regler-Ausgaben Die Simulation gibt bisher einen einfachen dreieckförmigen Verlauf eines Weges vor (hin- und her-Bewegung). Die Simulation der Umgebung ist so aufgebaut, dass es sowohl eine Ungenauigkeit der Wirkung der Stellgröße gibt (damit der Regler auch was zutun hat) als auch Trägheiten. Das Bild zeigt die Darstellung der Simulationsergebnisse. Am Anfang gibt es einige Startprobleme, sichtbar in wilden Schwingungen. Aber dann ist sichtbar dass der Verlauf der Ansteuerspannung (dunkelgrün) die Bewegung (Sollwert grüner Dreieckverlauf) folgt. An den Bewegungsenden gibt es starke Schwingungen. Die Motoren müssen ziemlich schlagartig gebremst und umgepolt werden. Das zeigt auch die Notwendigkeit von Optimierungen. Das sind die Ergebnisse der Java-Simulation. Es kommt hier nicht darauf an, die Regelung zu optimieren, sondern eher noch zu zeigen, dass eine Java-Simulation alle Probleme einer unoptimierten Regelung bereits zeigt.

1.2 Regelung in 16-bit-Festkomma

Topic=.Java2C.Sample1..

Auch das ist in Java nachstellbar: Die Regelung soll beispielsweise auf einem preiswerten 16-bit-Controller laufen. Damit sind die Hauprechnungen in 16-bit-Integer auszulegen. Nur für den Integrator werden 32 bit spendiert, weil er sonst hängen bleibt. Die Parameter sind irgendwo in den Bits verschoben zu realisieren. In C ohne Simulation würde man da etwas das Schwimmen beginnen, wenn man sich in den Bits verzählt. In Java unter Eclipse-Debugging ist das genauestens nachkontrollierbar. Der C-Algorithmus wird sich genauso verhalten, braucht also diesbezüglich nicht nochmal debugged zu werden. Auf dem Zielsystem sind nur Echzeit-Tests notwendig.