wir verwenden den Calliope mini seit ca. November im Schuleinsatz und programmieren diesen mit NEPO.
Immer wieder stellen wir hierbei den folgenden Fehler fest, ohne bisher eine Lösung des Problems gefunden zu haben:
Trotz korrekter Programmierung und Roboterkonfiguration funktionieren komplexere Programme, die durch Tastendruck der Tasten A und B aktiviert werden, zunächst oftmals nur teilweise oder gar nicht. Manchmal muss die entsprechende Taste erst viele Male oder auch länger gedrückt werden, bis sich der gewünschte Effekt einstellt. Zudem haben wir den Eindruck, dass sich manche Programmierungen erst langsam „eingrooven“ müssen, heißt, am Anfang funktioniert wenig bis gar nichts, sobald es aber dann nach einigen Minuten mal funktioniert, ist die Funktion recht zuverlässig reproduzierbar. Beide Verhaltensmuster lassen sich für uns nicht logisch erklären, zumal man von einem programmierten Algorithmus ein anderes Verhalten erwarten würde.
Ich nehme an, dass wir nicht die einzigen Nutzer sind, die solche Effekte beobachten. Daher meine Bitte um Austausch? Wer kann von ähnlichen Phänomenen berichten? Wer hat einen logischen Erklärungssansatz oder gar eine Möglichkeit der Abhilfe für dieses Problem?
Hallo Roland,
Bitte schicke doch mal ein Beispielprogramm bei dem der beschriebene Fehler auftritt. Dann wird sich bestimmt eine Lösung finden
Viele Grüße
Hubert
Hallo und vielen Dank für die Antworten.
@ klmi, danke für den Hinweis, aber Warteblock ist eingefügt.
@ Bitsteller, es sind vorwiegend Programme der folgenden Form, also wenn mit der gleichen Taste an und aus geschaltet wird und das erneute Schalten mit einem „Wiederhole bis“-Block realisiert wird.
Das nicht nachvollziehbare ist, dass das selbe Programm auf dem selben Calliope teilweise funktioniert, teilweise nicht. Wie bereits geschrieben, passt dieses Verhalten nicht zu meiner Vorstellung des algorithmischen Abarbeitens eines Programmablaufes. Entweder es funktioniert oder nicht, aber warum nur teilweise?
In fast allen Fällen funktioniert die obere Schleife (Taste A) nicht. Es scheint, als käme der Calliope nicht in die erste „Wiederhole bis“-Schleife, die LED bleibt aus. In der Simulation zeigt sich keine Auffälligkeit.
der Calliope mini macht da schon alles richtig, allerdings empfehle ich dir dabei dringend den Einsatz von Variablen.
Schau doch mal das Beispiel an, da siehst du gut, wie man genau das gewünschte Verhalten erreichen kann: Calliope mini-Helligkeit bzw. hier am Beispiel eines Bistabilen Schalters: Calliope-bistabil (allerdings in diesem Beispiel ohne Code).
danke für die Rückmeldung. Mit Variable habe ich auf Ratschlag von klmi ebenfalls programmiert, allerdings mit ähnlichem Ergebnis. Mit Funktionen habe ich noch nicht gearbeitet, weil das Programm überwiegend und auch reproduzierbar wie oben dargestellt das macht, was es soll. Mich intressiert daher die Tatsache, warum das Programm eben nur manchmal funktioniert, dann jedoch (z.B. wenn der Calliope eine zeitlang nicht angeschlossen war, bzw. wenn an einem anderen Notebook betrieben, etc.) nicht mehr oder erst nach mehreren Startversuchen, bzw. mehrfachem Tastendruck. Hierfür muss es doch irgend einen Erklärungsansatz geben. Gerne kann ich auch ein Video einstellen, bei welchem man das Problem in „Live“ sieht.
Hallo Roland,
ich kann mich dem Rat von Jörn und Michael nur anschließen und dir raten für den Status der beiden Tasten Variablen zu verwenden. Denn dein Programm ist „laufzeitabhängig“ und reagiert nur, wenn du eine Taste in dem Moment drückst, wenn das Programm nicht im „warte bis“ Block ist. Du kannst also sehr schwer nachvollziehen was wann passiert oder warum es nicht passiert. Die Simulation im Browser wird wesentlich langsamer ausgeführt als das Programm auf dem Calliope und verhält sich daher auch anders. Wenn du zwei Statusvariablen für die beiden Tasten verwendest, wird dein Programm kürzer und übersichtlicher und du brauchst wenn überhaupt, maximal einen Warte-Block in der äußersten Schleife.
