# Jetter Einsteiger



## lejcko (31 Mai 2011)

Hallo zusammen,

habe mich endschlossen nach mehreren Jahren Siemens programieren
auf Jetter Steuerungen umzusteigen. 
Nun habe ich ein paar Probleme mit der Adressierung der Eingänge und Ausgänge (JX3 DIO16). Vieleicht könnte mir mal einer da bei helfen wie ich die Register, heist es wohl bei Jetter aus dem Program einfach ansprechen  (abfragen) kann.
Also z.b. wenn Eingang 1= true   dann Ausgang 1=true
bei Siemens z.B. U E0.0 dann S A0.0 mir ist nicht genau wie ich an die notwendigen Adressen kommen soll, klar ist mir nur dass es mit der Position des JX3 DIO16 Moduls zu CPU zusammen hängt. 

Austattung:
Die aktuele JetSym Software
JX340 CPU
JX3 16 DIO modul


Gruß
Lejcko


----------



## whatisnesps (6 Juni 2011)

*Adressierung*

Hallo allein,

die Adressierung der Eingänge und Ausgänge eines JetControls 340 beginnt bei der Steuerung selbst mit der eins. Jedes gesteckte JX3-Modul bekommt eine fortlaufende Nummer. Das erste JX3-DIO16 neben dem JetControl 340 bekommt dann automatisch die zwei. Diese Adressierung erfordert keinen zusätzlichen Aufwand (Hardwaremanager), sondern wird vom JetControl selbst übernommen. Wir können also die Produkte aus dem Lager holen, mit Spannung versorgen, einschalten und die Module werden automatisch vom JetControl erkannt.
Die Adressierung folgt dem Schema: 10000mmxx, wobei mm der Moduladresse entspricht (01 für die CPU, 02 für das erste JX3-Modul direkt neben der CPU, 03 für das zweite JX3-Modul neben der CPU, ...) und xx der EA-Nummer (meist 01 ... 16).
Steckt das JX3-DIO16 direkt neben der CPU, dann lauten die Adressen der 16 digitalen Eingänge: 100000201 bis 100000216.
Die digitalen Ausgänge sind rücklesbar, also als digitalen Eingängeverwendbar, und hören dann auf die Adressen 100000209 bis 100000216.
Ich empfehle, für die digitalen EA Variablen anzulegen. Ein Blinklicht sieht dann beispielswiese so aus:
var
    bi_Start:    bool at %ix 100000201;
    bo_Toggel:    bool at %qx 100000210;
end_var;

task t_Markus autorun

    loop
        when bi_Start continue;
        bo_Toggel := true;
        delay(t#500ms);
        bo_Toggel := false;
        delay(t#500ms);
    end_loop;

end_task;

Für weitere Fragen offen.

Markus Friedrich


----------



## lejcko (7 Juni 2011)

*Adressierung der JX2 SM2 Achsen*

Hallo Herr Markus,

vielen vielen Dank für deine Antwort ..hatte mir sehr geholfen bei dem verstehen wie Jetter die Hartware im System anmeldet.
Bin nun in der Lage eigene Anwendungen mit Digitalen Ein Ausgängen zu Programmieren.
Ein Problem habe ich dennoch und zwar besteht meine Steuerung nun  aus folgenden Komponenten.
Jx 340 -3-SD-W + Jx3-DI16 + JX2-PS1 + JX2 SM2.
Da Jetter momentan die JX3 Variante eine Schrittmotor Moduls nicht liefern kann musste ich auf den Systembus der JX2 umsteigen. Nun habe ich das selbe Problem wie auch in meine ersten Anfrage daß ich die beiden Achsen des JX2 SM2 Moduls nicht ansprechen kann. Das heißt die Adressen für dieses Positionier Modul  sind mir völlig unklar.
POS(AxhsenNr. Position. Geschwindigkeit). Ich denke dieser Befehl ist verantwortlich für die Bewegung der Achse.
Für weitere Hilfe währe ich sehr dankbar.

Michael Lejcko


----------



## whatisnesps (7 Juni 2011)

*Adressierung JX2-SM2*

Hallo Herr Lejcko,

eine JX3-Variante eines Schrittmotormoduls bietet die Jetter AG nicht an. Wir verwenden das JX2-SM2-Modul hoch offiziell am JetControl 340.
Der POS-Befehl kommt aus der JetSym-Welt und funktioniert dort einwandfrei. Ich habe hier ein JetSym-STX-Beispielprogramm, das Ihnen zeigt, wie eine Schrittmotorachse an einem JetControl 340 programmiert wird. Ich habe exakt den gleichen Aufbau wie Sie auf dem Tisch und würde Ihnen gern dieses Beispiel zukommen lassen. Meine E-Mail-Adresse lautet m (wie Markus) Friedrich (direkt verbunden, ohne Strich, ohne Punkt) at Jetter Punkt de.

Meine Antworten können eine Schulung nicht ersetzen. Selbst wenn ich Ihnen hier ein paar Mosaiksteinchen der Jetter-Technologie online erkläre, haben Sie immer noch nicht das gesamte Bild vor Augen. Aus diesem Grund empfehle ich Ihnen, eine solche Schulung zu besuchen.
Die Jetter-Programmierung unterschiedet sich von der Programmierung klassischer SPS-Systeme. Wenn Sie diese Schulung nicht besuchen, besteht die Gefahr, dass Sie in die falsche Richtung loslaufen und das will ich nicht.

Markus Friedrich


----------



## IBFS (7 Juni 2011)

whatisnesps schrieb:


> Die Jetter-Programmierung unterschiedet sich von der Programmierung klassischer SPS-Systeme.



Können sie denn mit einfachen Worten in wenigen Sätzen erklären,
was vom Prinzip her anderes ist. Ist es mit irgendwas bekanntem,
also 3S oder OpenPCS Vergleichbar.

Wenn sie hier wirklich Interesse für ihre Produkte wecken wollen, dann
wären dazu eine Info nicht schlecht. 

Frank


----------



## whatisnesps (7 Juni 2011)

*Interesse für Jetter wecken*

Hallo Frank,

besser kann ich es kaum beschreiben:


Oliver Ernst schrieb:


> Hallo Kume,
> 
> wir haben Erfahrung mit beiden: Jetter und Siemens.
> Wobei wir bisher nur 1 Projekt unter Siemens und unzählige mit Jetter realisiert haben.  Beide haben Ihre Vor- und Nachteile.
> ...



Der Beitrag, den ich hier zitiere, ist vom 			 				05.01.2005, 21:45. In der Zwischenzeit hat sich Einiges getan.
JetSym STX, die neueste Programmiersprache in der Jetter-Welt, bietet weitere Vorteile wie Zeichenkettenverarbeitung und Dateioperationen in einer SPS. Soll heissen: Es gibt beispielsweise die Möglichkeit, eine Textdatei im Dateisystem eines JetControls (eine Jetter-SPS) zu erzeugen und die dann anschließend bei Bedarf per E-Mail zu verschicken. Das Format einer solchen Textdatei kann TXT sein, muss es aber nicht zwingend. Das Format kann dann auch CSV, XML oder HTML heißen. Dass das funktioniert habe ich mit einem kleinen, gut dokumentierten JetSym-STX-Projekt bewiesen: Ein JetControl erzeugt eine HTML-Datei in seinem eigenen Dateisystem. Diese Datei habe ich alarm.html genannt. Es werden alle möglichen Alarme, die während seiner Arbeit anfallen, auf dieser HTML-Datei gesammelt, dokumentiert und veröffentlicht. Jeder, der ethernettechnisch Zugriff auf das Dateisystem des JetControls hat, kann sich diese Nurleseseite (!!!) anschauen. Schaltet mir jemand den JetControl aus, bleibt die HTML-Datei im Dateisystem gespeichert und wird beim nächsten Wiedereinschalten neu eingelesen. Dass eine solche HTML-Datei per iPhone oder HTC aufrufbar ist, versteht sich von selbst.
Solche Textdateien können dann gern auch auf einer SD-Karte liegen, die im JetControl steckt. Solche Textdateien lassen sich nicht nur schreiben, sondern auch problemlos einlesen.

Desweiteren steht in JetSym STX die objektorientierte Programmierung zur Verfügung. Wer möchte (keine Pflicht), kann einen JetControl also gern auch objektorientiert programmieren.

Ein richtig großer Vorteil sind die arithmetischen Befehle wie Sinus, Cosinus, Tangens, Wurzel, Exponentialfunktion, die mir schon bei einigen Projekten treu zur Seite standen und mich bei der Arbeit unterstützten.

Arbeiten viele Programmierer an ein und demselben Projekt, steht eine Toolintegration zur Verfügung, um Softwarestände einfach zu verwalten (http://de.wikipedia.org/wiki/TortoiseSVN).

Bedingt durch die Multitaskingstruktur, die natürlich auch bei JetSym STX zur Verfügung steht, können wir Tasks schrittweise ausführen lassen. Bei klassischen SPS-Systemen wird im Debugbetrieb immer das gesamte Programm angehalten.

Ein Programm sollte immer fehlerfrei sein, klar. Das klappt aber leider nicht immer, es treten hie und da mal Fälle auf, zu denen die SPS allergisch reagiert. Aus diesem Grund wurde bei JetSym STX ein ausgefeiltes Exception-Handling (Ausnahmebehandlung) integriert. Es stehen Befehle wie TRY..CATCH zur Verfügung, die einfach aus der Hochsprachenprogrammierung übernommen wurden.

Konfuzius sagt: "Kopiere deinen Meister und verbessere ihn" ==> Programmquellcode lässt sich aus einer SPS recht einfach auslesen, wieder sichtbar machen und an andere Bedürfnisse anpassen, selbst dann, wenn ein Passwortschutz definiert wurde. Ein wichtiges Thema, das in den kommenden Jahren immer wichtiger werden wird. JetSym-STX-Programme werden compiliert und können selbst von unseren Fachleuten hier im Haus nicht wieder rückübersetzt werden und das ist auch gut so.
Wir können das Programm in der Steuerung ebenfalls passwortschützen. Selbst wenn es einem Angreifer gelingen sollte, das übersetzte Programm auszulesen, kann er damit nur exakt hundertprozentig baugleiche Maschinen bauen. Das ist bei der Komplexität der Maschinen, die mit Jetter-Steuerungen meist realisiert werden, sehr schwer.
Der Kunde FORDERT aber den Quellcode zur Maschine? Kein Problem. Den bekommt er, aber die Teile, die unsere Ideen enthalten, schützen wir vor fremden Zugriffen und geben dem Kunden vorcompilierte JetSym-STX-Bibliotheken mit. Dann kann sich der Kunde gern den Quellcode vom Werkstückträgertransport anschauen und debuggen, aber eben nicht die relevanten Teile der Maschine.



> Wenn sie hier wirklich Interesse für ihre Produkte wecken wollen, dann wären dazu eine Info nicht schlecht.


 ==> liest das hier jemand sonst? Wecke ich wirklich Interesse für Jetter, wenn ich hier Antworten auf Fragen schreibe? Ich bin gern bereit, mehr über JetSym STX aus dem Hause Jetter zu berichten.

Ich bin neu hier im Forum und habe das Login von meinem Vorgänger übernommen.

Für weitere Fragen und Diskussionen offen.

Markus Friedrich


----------



## IBFS (7 Juni 2011)

whatisnesps schrieb:


> ==> liest das hier jemand sonst? Wecke ich wirklich Interesse für Jetter, wenn ich hier Antworten auf Fragen schreibe?



Danke für die Ausführungen.

Du glaubst garnicht wie viele ROs (ReadOnlys) hier im Forum unterwegs sind.
Wenn dann jemand mal JETTER hier oder ggf. bei Google eingibt, dann ist
das schon hilfreich.

Allerdings sind im zitierten Post ein paar kleine Fehlerchen enthalten, die das
Gesamtbild stören. Ich würde meine Produkte nie mit "im Vergleich zu" anpreisen,
weil das über kurz oder lang oder ggf. schon direkt falsch sein kann.
Mit dem beschriebenen Zyklus stimmt das so leider nicht. Erstens gibt
es bei der 400er Serie (auch schon 2005) TPA = Teilprozessabbilder.
Zweitens hat sogar die 300er Serie von Si. Interruptfunktionen OB40 usw.

Ich denke die Ansätze sind verschieden und eure Anwendungsfälle sind eher
kleine aber dafür schnelle Insellösungen. Dadurch ergeben sich zwischen
den beiden genannten Firmen m.E. recht wenig Überschneidungen, sodass
es sinnvoll ist, die besonderen Anwendungsfälle herauszustellen.

Gruß

Frank


----------



## whatisnesps (7 Juni 2011)

*eher kleine Insellösungen...*

Hallo Frank,



> Du glaubst gar nicht wie viele ROs (ReadOnlys) hier im Forum unterwegs sind. Wenn dann jemand mal JETTER hier oder ggf. bei Google eingibt, dann ist  das schon hilfreich.


 Okay, verstanden und danke für den Hinweis.



> Ich denke die Ansätze sind verschieden und eure Anwendungsfälle sind eher kleine aber dafür schnelle Insellösungen.


 Die Ansätze sind definitiv verschieden. Als kleine Insellösung würde ich Maschinen mit 150 bis hin zu 300 Servoachsen eher nicht bezeichnen... 



Mir geht es vor allem auch darum, herauszustellen, wie einfach Jetter-Steuerungen programmiert werden. Morgen habe ich beispielsweise wieder einen Kurs im Rahmen unserer Zusammenarbeit mit der Girls' Day Academy. Acht Mädchen der neunten Klassenstufe einer hiesigen Realschule besuchen uns und programmieren Jetter-Steuerungen *und* -Servoantriebstechnik. Es ist immer wieder erstaunlich, wie weit wir in zwei Stunden kommen: Legosteine werden von einem pneumatischen Greifer aufgenommen, mit einer Servoachse horizontal weiter befördert und an einer anderen Stelle wieder abgesetzt.

Markus Friedrich


----------



## bike (8 Juni 2011)

Dies sind interessante Ausführungen.
Ich habe mir den Webauftritt  angeschaut.
Auch ist das Bild von der Messe mit dem großen Schaltschrank beeindruckend.
Doch habe ich keine Anwendung gefunden aus dem Bereich der Automatisierung.
Ist vermutlich zu gut versteckt 

Die Step 7 Steuerungen bzw die Technologie Erweiterungen können auch mathematische Funktionen, das ist nichts besonderes.
Und der Hinweis wegen Kopierschutz und ähnliches geht doch an der Praxis vorbei.
Wenn der Quellcode geliefert werden muss, dann muss alles dabei sein. 
Daher ist dies kein Vorteil in meinen Augen.


bike


----------



## trinitaucher (8 Juni 2011)

whatisnesps schrieb:


> Als kleine Insellösung würde ich Maschinen mit 150 bis hin zu 300 Servoachsen eher nicht bezeichnen...
> [Foto]


Sind da etwa 12 Steuerungen verbaut worden für je rund 9 Antriebe? Wieso nicht alle Servoachsen an einer Steuerung, wenn doch eh alle synchronisiert werden?


----------



## whatisnesps (8 Juni 2011)

*Werbung, überzeugen?*

Hallo alle,

Trinitaucher:   [FONT=&quot]Alle Servoverstärker an eine Steuerung zu hängen, wäre nicht sinnvoll, da die Synchronisation nur die halbe Miete ist. Da steckt noch mehr dahinter. Was ich vergessen habe zu erwähnen: Der Jitter (Abweichung von der Genauigkeit) liegt, über alle Servoachsen betrachtet, bei unter zehn Mikrosekunden (steht am linken Schaltschrank in roter Schrift). Und das über Standard-Ethernet TCP/IP! Wir können an jeden beliebigen freien Ethernet-Port einen Standard-PC reinhängen und Parameter der einzelnen Achsen auslesen, selbst im heißen Bereich, also da, wo die Synchronisation läuft. Das vereinfacht die Fernwartung erheblich, weil wir dafür Standardgeräte verwenden können.

[/FONT]





> Die Step 7 Steuerungen bzw die Technologie Erweiterungen können auch mathematische Funktionen, das ist nichts Besonderes.


 Bei Jetter gehören nicht nur die mathematischen Funktionen zum Standardbefehlsatz, sondern auch die objekorientierte Programmierung, Motion-Bibliothek, die Datei- und Zeichenkettenoperationen, .... Und die kosten keinen Cent extra 

Bitte nicht falsch verstehen: Ich möchte hier niemanden bekehren oder belehren. Ich will nur Leute unterstützen, die Fragen zum Jetter-System haben.

Markus Friedrich


----------



## IBFS (8 Juni 2011)

whatisnesps schrieb:


> Ich will nur Leute unterstützen, die Fragen zum Jetter-System haben.



Geht denn DELTA-LADEN also Laden von Teilfunktion bei laufender Maschine?

Frank


----------



## whatisnesps (8 Juni 2011)

*Teilfunktionen*

Hallo alle,

ja, das Laden von Teilfunktion bei laufender Maschine funktioniert unter JetSym STX.

Markus Friedrich


----------



## trinitaucher (8 Juni 2011)

Du legst dich ja echt ins Zeug für deine Firma... respekt :wink:


whatisnesps schrieb:


> [FONT=&quot]*Alle Servoverstärker an eine Steuerung zu hängen, wäre nicht sinnvoll, da die Synchronisation nur die halbe Miete ist.* Da steckt noch mehr dahinter. Was ich vergessen habe zu erwähnen: Der Jitter (Abweichung von der Genauigkeit) liegt, über alle Servoachsen betrachtet, bei unter zehn Mikrosekunden (steht am linken Schaltschrank in roter Schrift).
> [/FONT]


Wieso nicht sinnvoll? Wenn ich nun aber nur eine Steuerung haben möchte?
TwinCAT mit EtherCAT kann 255 bis zu Achsen synchronisiert verfahren, an *einer* Steuerung. EtherCAT als Protokoll könnte noch viel mehr, und auch mit Jitter < 1µs.
... will nur sagen, dass mich die Leistungsfähigkeit jetzt nicht so extrem vom Hocker haut.


whatisnesps schrieb:


> [FONT=&quot]Und das über Standard-Ethernet TCP/IP! Wir können an jeden beliebigen freien Ethernet-Port einen Standard-PC reinhängen und Parameter der einzelnen Achsen auslesen, selbst im heißen Bereich, also da, wo die Synchronisation läuft. Das vereinfacht die Fernwartung erheblich, weil wir dafür Standardgeräte verwenden können.
> [/FONT]


Wie wird die Deterministik sichergestellt, wenn ich nen Laptop dazwischenhänge, der das Netzwerk mit Braodcast-Anfragen zuballert? Müssen spezielle Switche verwendet werden, oder gibt's Einschränkungen in der Topologie?
Ich verstehe nicht wie eine exakte Synchronisierung ohne überlagertes Protokoll oder bestimmte Einschränkungen von statten gehen kann. (Wenn's so einfach wäre, wieso bräuchte man dann ProfiNet, EtherCAT und wie sie alle heißen?).


whatisnesps schrieb:


> Bei Jetter gehören nicht nur die mathematischen Funktionen zum Standardbefehlsatz, sondern auch die objekorientierte Programmierung, Motion-Bibliothek, die Datei- und Zeichenkettenoperationen, .... Und die kosten keinen Cent extra
> 
> Bitte nicht falsch verstehen: Ich möchte hier niemanden bekehren oder belehren. Ich will nur Leute unterstützen, die Fragen zum Jetter-System haben.


Aber bei allem Enthusiasmus, mathematische Operationen kennen Steuerungen mit CoDeSys-Compiler, und insb. PC-basierte, auch schon lange. Bei TwinCAT zumindest gehören die von dir genannten Dinge auch zum Standard (je nach Version).

Was meint ihr mit "Laden von Teilfunktionen"? Online-Change?


----------



## IBFS (8 Juni 2011)

trinitaucher schrieb:


> Was meint ihr mit "Laden von Teilfunktionen"? Online-Change?



...das man im RUN der SPS geänderten Code in die Steuerung laden kann, ohne das die SPS in STOP geht.
Das ist für mich mit die wichtigste Funktion an einer SPS überhaupt.

Frank


----------



## whatisnesps (8 Juni 2011)

*Jetter*

Hallo Trinitaucher,



> Du legst dich ja echt ins Zeug für deine Firma... respekt :wink:


 Ich kann nur für eine Firma arbeiten, von der ich überzeugt bin. Ich würde es nicht lange überleben, jeden Morgen mit einem grummeligen Gesicht zur Arbeit zu gehen, wenn ich von der Sache nicht überzeugt wäre.

Die zwölf Steuerungen, die in der Anlage verteilt sind, heißen Sectioncontroller. Die arbeiten alle das gleiche Programm ab, nur eben zeitlich versetzt, so dass am Ende ein Strang Flaschen auf dem Fließband steht. Diese Steuerungen haben, wie schon erwähnt, noch andere Aufgaben. Es wäre nicht sinnvoll, dies von einer Steuerung allein erledigen zu lassen. Ich stecke nicht tief genug in dem Projekt drin, um weiterführende Informationen geben zu können. Wenn erforderlich, müsste ich erst meinen Kollegen löchern...



> TwinCAT mit EtherCAT kann 255 bis zu Achsen synchronisiert verfahren, an *einer* Steuerung. EtherCAT als Protokoll könnte noch viel mehr, und auch mit Jitter < 1µs.


 Das ist richtig. TwinCAT mit EtherCAT arbeitet allerdings nicht mit Standard Ethernet TCP/IP und kommt damit auf einen kleineren Jitter. Unsere Servoachssynchronisation könnten wir jederzeit parallel zu einer Büro-Ethernet-Installation fahren. Das haben wir bereits bewiesen. Wir verwenden also kostengünstige Standard-Industrie-Switche und Infrastrukturkomponenten (Fernwartung) und machen uns dadurch nicht abhängig von einem speziellen Hardwareanbieter. Bei unserer Art der Synchronisation ist bei 255 Achsen noch lange nicht Schluss. Das begrenzende Element ist die Anzahl der zur Verfügung stehenden IP-Adressen auf der einen und die Geschwindigkeit der Switche auf der anderen Seite.
Bei der Ethernet-Topologie achten wir darauf, dass jede Sektion ihren eigenen Switch hat (sieht man in meinem angehängten Foto von der Anlage). Dadurch kann jederzeit eine Sektion außer Betrieb gesetzt werden, ohne den Rest der Anlage lahm zu legen. Der Zeitmaster hat seinen eigenen Switch, der die Telegramme an die Sektionsswitche verteilt.
Die Deterministik stellen wir dadurch sicher, dass ein Zeitmaster Multicasts an alle Teilnehmer schickt. Dieses Telegramm ist mit einem Zeitstempel versehen. Jeder Teilnehmer kann sich aufgrund dieses Telegramms zurückrechnen, wie alt die Nachricht ist. Und das auch dann, wenn die Laufzeiten der Telegramme unterschiedlich ist. Taucht nun ein Laptop im Netzwerk auf, der ständig Broadcast-Anfragen sendet, müssen wir nur sicherstellen, dass der Zeitmaster alle seine Teilnehmer mit seinen Telegrammen in einem gewissen Zeitabstand erreichen kann.
Beim Einschalten des Systems findet zunächst ein Einschwingvorgang statt, den wir sehr schön mit dem im JetSym integrierten Oszilloskop beobachten können (JetSym ist unser hauseigenes Programmier- und Diagnosetool, da haben wir glücklicherweise selbst den Daumen drauf und können in Windeseile neue Funktionen integrieren, ohne auf die Arbeit eines externen Softwarehauses warten zu müssen oder abhängig zu sein). Nach einer gewissen Zeit sind alle Teilnehmer eingeschwungen und basierend auf dieser Uhrensynchronisation fahren wir dann die Servoachsen. Ich hoffe, JetSync, so heißt unsere Servoachssynchronisation gut genug erklärt zu haben. Wer weitergehende Informationen zu dem Thema haben möchte, kontaktiert mich einfach auf der SPS/IPC/Drives in Nürnberg. Ich werde da sein und gern solche Fragen beantworten.



> Aber bei allem Enthusiasmus, mathematische Operationen kennen Steuerungen mit CoDeSys-Compiler, und insb. PC-basierte, auch schon lange. Bei TwinCAT zumindest gehören die von dir genannten Dinge auch zum Standard (je nach Version).


 Das ist doch prima. Von denen schreibe ich auch nicht. Es gibt andere SPS-Systeme, die für solche Extrafunktionen teuer Geld verlangen. Von denen spreche ich speziell.

Gestern Abend habe ich erwähnt, heute mit der Girls' Day Academy zu tun zu haben. Die Neuntklässlerinnen haben gerade das Haus verlassen. Ich bin immer noch ganz hin und weg vom Enthusiasmus der Mädchen. Wir haben das bestehende Projekt (Pneumatikgreifer schnappt sich Legosteine und setzt die per Servoachse woanders wieder ab) etwas erweitert. Die Mädchen haben eine Schleife in das Programm eingebaut, die es ermöglicht, die Legosteine auf fünf verschiedene Positionen abzulegen. Die Absetzpositionen werden durch ein Array definiert. Mit meinen Erwachsenen brauche ich gefühlte Ewigkeiten für diese Übung. Trotz parallel laufender Foto- und Videoaufnahmen hatten die Mädchen die Aufgabe in kürzester Zeit gelöst. Wow! Ein weiterer Beweis, dass sich Jetter kinderleicht programmieren lässt.

Markus Friedrich


----------

