Hallo Achim,

einerseits bin ich dabei, weitere von mir noch nicht erkannte Problemsituationen zu erfassen, andererseits kann es sein, dass unterschiedliche Hardwaretolleranzen auch zu unterschiedlichen Ergebnissen führen.

Genau hier setze ich an und versuche genauere Details zu ermitteln.

Hallo Elektrolutz
Die Anzahl der Versuche bei dir verblüfft mich doch sehr. Kann mir kaum vorstellen das bei dieser Produktionsart solch starke Hardware Unterschiede sein sollen. Ein paar Herz Abweichung beim Quarz ist ok, aber der Rest ? Der Proz ist doch der selbe, die Motore vermutlich auch. Der Rest ist doch unerheblich. Der Befehl zum Fahren kommt aus dem 128 oder 88. Und dort läuft alles digital.
Mal zu was anderem. Habe mir gestern die copro Befehle angesehen. Es gibt ja mehrere und auch verschiedene Möglichkeiten diese anzusprechen. Hatte dabei an die Möglichkeit der Überwachung über Ticks gedacht. Vorgabe der Strecke - Mssung der Ticks - und Freigabe des weiteren Programmes. Scheint aber kaum möglich zu sein.
Wenn ich von Tuto 8 ausgehe, so werden dort die case verwendet. Die Länge der Zählzeiten steht bei (delay) 20 (ms). Wenn case alle 100 Schritte aufgerufen wird, so sind das ja 2 Sekunden von Fahrt bis Stop. Bei Proz eine sehr lange Zeit. Wo hängt es denn eigentlich? Wieso immer verschiedene Befehle?.
Hätte da vielleicht eine Idee um das sicher zu machen. Wenn die Fahrbefehle vom 88 ausgeführt werden, hilft eine Freigabe weiter. Der 88 (?) steuert die Motore an. Erst wenn der Befehl (egal welcher) ausgeführt ist erfolgt eine Rückmeldung und das Programm kann weiter gehen. Der Rest wartet bis fertig. Dabei haben stop aber Vorrang. Vielleicht hast du eine bessere Idee. Eine Kontrolle mit C ins Prg einzubauen ist aufwendig und hat viele Fehler.
Achim

Hallo Achim,Unter dieser Annahme gibt es keinen sporadischen Fehler, das Auftreten der Fehlfunktionen müsste dann streng logisch passieren und genau reproduzierbar sein. Aber genau dieses ist nicht der Fall.
Wieso bist du der Meinung, dass dieses kaum möglich sei. Man kann doch jede durchgeführte Funktion abschliessend prüfen und auch nachrechnen, ob das Ergebnis in erwarteter Weise eingetreten ist. Man muss es nur programmieren - fertige Funktionen gib es nicht für jede Situation.
Sorry, aber hier verstehe ich nicht, was du sagen möchtest? Erkläre mir bitte mal, wie du gemessen hast, dass "delay(20)" = 20ms ist? Wo hängt was? Welche verschiedenen Befehle meinst du?
workwind hat in einer seiner letzen Antworten beschrieben, dass die copro-Befehle gelistet werden und der Reihe nach abgearbeitet werden, nur gleiche Befehle überschreiben sich mir dem zuletzt gegebenen Wert. Das ist eine FW-interne Funktion, ohne die ein Bus nicht plausibel funktionieren kann.
Sicherlich ist die Programmierung einer Kontrollfunktion aufwändig, zudem sorgt eine solche Funktion auch für zusätzliche Prozessorauslastung. Wieso hat eine Kontrolle viele Fehler, für Programmierfehler und deren Beseitigung ist aber der Programmierer verantwortlich .

Hallo
Da die Verarbeitung im Proz digital ist (durch ein Programm) und die Ausgänge dran hängt, ist die Frage wo die Fehler herkommen. Idee woher den die Fehler kommen?
Sorry, hatte die falsche Nr vom Tuto genommen. Es ist Totu 9. Dort wird über eine Schleife Nibo ein Stück vor gerade gefahren und dann wieder zurück. Dabei kommt stopIemmdate zum Einsatz um zu zeigen was aktives Bremsen ist. Es wird die Schleife durchgezählt und bei case 100 in die Bewegung verzweigt. Am Ende steht delay (20). das sind 20ms.
Da die Schelife von 1 anfängt und bis zur ersten case Anweisung 100 mal die Schleife durchlaufen muss, sind das nach meinem verständnis 2 Sekunden. Das wird bis Ende durchgeführt.
Es ist klar das man alles überprüfen kann. Doch der Nibo wurde für die Ausbildung, zum lernen und für Anfänger entwickelt. Kann mir kaum vorstellen, das jemand der gerade mit C anfängt und sich dazu den Nibo holt, das alles sofort kann und genau weiss wie man das programmiert. Je mehr Befehle und Zeilen im Programm sind um so grösser ist die Möglickeit von Fehlern. Der Programmierer ist dafür verantwortlich, ist klar. Möchte aber keinen Nutzer die Freude am Nibo verderben, wenn ich ihm sage, mit wieviel zuzätzlichen Aufwand er diesen Fehler in Griff bekommt. Da es ja verschieden Möglichkeiten gibt, dem Nibo zu sagen was er machen soll, gibt es auch verschiedene Möglichkeiten der Kontrolle.
Messen brauche ich den Befehl delay nicht. Steht im Lib drin, das delay in ms ist. Diese Angabe kommt vom Hersteller. Workwind verwendet selbst für eine Pause von 1 Sekunde delay (1000). Bei 100 Durchläufen der Schleife im Tuto sind das rund 2 Sekunden. Auch das Programm was damit meine stammt von Workwind. Bei einer listung der Befehle sind das ca. 2 Stück. Meisten sogar nur eine. Wenn der Befehl kommt, vorwärts zu fahren, wird er nicht ausgführt oder nur teilweise. Der nachfolgende Befehl Stop wird ausgeführt. Dann laufen wieder 10 Befehle oder mehr ohne Probleme. Die Sache ist mit nicht klar. Es muss doch irgendwo hängen
Achim

Hallo Achim,

soweit du mit "Totu 9" oder auch "Tuto 9" das Programm zum "Tutorial 9" aus der "Lib 2.10" meinen solltest, dann haben wir unterschiedliche Programmversionen.
In der mir zur Verfügung stehenden Version kommt der Befehl "copro_stopImmediate()" nicht zum Einsatz.

Meine Tests beziehen sich auf das Programm "stop_immediate.c" aus ".../examples2/stop_immediate_test" in der Lib 2.10.

Deshalb versuche ich die Fehlerursache so genau wie möglich einzukreisen, um dem Hersteller eine brauchbare Fehlerbeschreibung geben zu können.
Im Übrigen sollte jeder Programmierer in der Lage sein, Kontrollroutinen zu schreiben, um "eigene" Programmierfehler ausfindig machen zu können.


Ich habe noch nicht gemessen, wie genau die "delay-Funktion" als Zeitglied arbeitet.
Bei 100 Programmabläufen addiert sich zu der delay-Zeit-Summe zumindest noch die Programmablaufzeit hinzu.

Man könnte ja mal ein Uhr-Programm für den Nibo2 schreiben, getaktet über die delay-Funktion - alternativ über einen Timer, mit großflächiger Zeitanzeige über das Display, um die Zeit auf Genauigkeit gegenüber einer Funkuhr zu prüfen. Eine schöne C-Programmieraufgabe, durch die man den Nibo2 im nichtbenutzten Zustand als Uhr einsetzen kann. Als Programmerweiterung könnte man Wecksignale per Licht und Piepser ergänzen.

Hallo
Bei der verwendung von delay ist es wahrscheinlich nicht so wichtig ob 20 ms nun 19,5 oder 20,5 ms brauchen. Es geht mir auch darum, Spass bei meinem Hobby zu haben, Es bereitet mir Freude etwas in C (C++) zu lernen und diese Wissen direkt zu testen. Dazu entwickelt man eigene Programme und schickt sie zum Nibo. Ziel von Nicai ist es doch auch, aus einzelnen Teilen einen Roboter zu bauen und Gewinn bringend zu verkaufen. Dazu braucht man Kunden, die bereit sind Geld für das Teil auszugeben. Hast du den das einfache Programm mit Hin und Her mal ausprobiert?
Eine (Stop)Uhr für den Nibo gibt es bereits. Es ist manchmal recht interessant, wenn man sieht, wieviel manche Befehle und Programme brauchen. Eine direkte Uhr sehe ich im Moment nicht als wichtig an, da keine Basis vorhanden ist.
Vielleicht kannst du etwas Licht in mein Dunkel bringen. Wenn stop auf dem 128 auslöse, was passiert dann eigentlich? Wie erfolght die Übertragung vom 128 zum 88 und was läuft dabei? Was macht der 88 damit? Du hattest ja mal gesagt, das 88 viel über Zähler macht. Da wir nur an den 128 ran kommen, können wir leider nichts überprüfen.
Das mit den Programmierern ist so ein Problem. Es gibt solche und solche. Und eines habe ich in meinem Leben gelernt, selbstgemachete Fehler findet am schlechtesten.
Ich glaube kaum das ich solche komplexen Sachen so einfach hinbekomme. Wenn ich mir Beispiel in der Lib so ansehe, so bin ich nach eigener Einschätzung noch weit weg, aber auf dem Weg. Hilft nur eins, weiter lernen und probieren.
Läuft dein Programm schon?
Achim