Posts by Programmiersklave

    Ich meinte eher, wenn das Anwenderprogramm selbst umlaufend viel Zeug als Textdatei rausschreibt, so im Journal-Stil, kann man ja machen, und wenn irgendwas schiefgeht, weiß man dann im Backup, wo es hing. Stellte sich allerdings raus, dass das längerfristig statistisch eher ungesund für den Massenspeicher und das Dateisystem war.

    Wenn er Netzwerkverbindungen verliert, warum auch immer, endet das eigentlich auch immer im Systemfehler und nicht in einem Reboot.

    Was man (der Kunde) vielleicht auch verwechselt: wenn nur das TP abstürzt und rebootet. Während der Zeit hat man mit RS weiter Zugriff auf den Robbi, aber von außen sieht man nur, dass es finster ist und stehenbleibt. Vielleicht einfach mal die TPs kreuztauschen?

    Ich würd' mich nicht so auf die Auslastung fixieren. Da sind im System ein Haufen Mechanismen, die dafür sorgen, dass bei Überlastung die Notbremse gezogen wird, das poppt dann normalerweise nicht einfach so weg. Da gibt's erst Warnungen und Merkwürdigkeiten.

    Und generell - wenn das System merkt, dass was gar nicht stimmt, entscheidet es sich für einen SysFail. Was immer es bei jener Anlage ist, es wird wohl vermutlich noch unterhalb von RobotWare sein, vielleicht sogar Hardware. Machst Du viel Logging? Dann ist die Flashdisk ein guter Kandidat.

    Naja, wenn Backup auf USB im vollen Betrieb reproduzierbar zum Absturz führt und andererseits die BG-Tasks für hohe Auslastung verdächtigt werden, wäre es wohl die passende Gegenprobe, nur für diesen Test mal die BG-Tasks langsamer zu machen, um dann ein Backup zu probieren.

    Und dann in einer 2. Probe die BG-Tasks schnell lassen, aber die Bewegungstasks verlangsamen.

    Solche Fehler entstehen ja gerne, wenn sich intern irgendwas aufstaut oder logisch kollidiert, woran nie einer gedacht hat, dass es sich aufstauen oder selbst verletzen könnte - und das dann überläuft. Vielleicht hilft auch hochziehen auf die letzte Version von 6.15

    Gerade wenn Du Verriegelungen erwähnst - Weltzonen sind auch so ein Ding, das nicht immer sauber implementiert war....

    Mit zweimal StrPart()

    Quote from Handbuch

    StrPart '('

    [ Str ':=' ] <expression (IN) of string> ','

    [ ChPos ':=' ] <expression (IN) of num> ','

    [ Len ':=' ] <expression (IN) of num> ')'

    Eine Funktion mit einem Rückgabewert des Typs string.

    Wobei 80 auch in einem geht, es wird automatisch hart umgebrochen.

    Bei Verwendung von USB-Adaptern hat es gewöhnlich keinen Sinn, die Einstellung der COM- Übertragungsparameter nur im Terminal-Programm machen zu wollen.

    Man gehe in den Windows-Gerätemanager und suche dort unter "Anschlüsse" den Adapter und stelle unter "Eigenschaften|Port Settings" die Parameter ein, mit denen auch die Gegenstelle zu telefonieren bereit ist. 9600/8N1 ist die Standardeinstellung, regelmäßig kommunizieren aber viele Geräte schon seit 20 Jahren deutlich schneller.

    Dort erfährt man dann auch gleich, welchen virtuellen COM-Port der Adapter bereitstellt. Den muss man dann aber im Terminal-Programm (oder welchem Programm auch immer) auf jeden Fall auswählen.

    Windows hat die unangenehme Eigenart, die COM-Ports einfach hochzuzählen, ehemals vorhandene aber nicht allzu bereitwillig zu vergessen. Es kommt daher regelmäßig vor, dass beim Neustart von Windows ein virtueller serieller Port eine neue Nummer bekommt, deshalb muss man beinahe zwangsläufig jedes Mal, bevor man arbeiten kann, im Geräte-Manager nachschauen, wo der Adapter sich gerade anzuschließen pflegt. Bei diesen Wechseln wird wohl auch wieder auf die Default-Einstellungen zurückgesprungen (Windows hat sogar einen Button dafür!), weshalb es durchaus vorkommen kann, dass von einem Tag auf den anderen die Einstellungen nicht mehr gehen.

    Einmal den Adapter zur Unzeit abgezogen oder eingesteckt, und schon ist es durcheinander.

    Bei manchen Antriebskomponenten verlegt man dazu die Regelfrequenz der Servos in einen nicht störenden Bereich, Umrichter bieten dazu manchmal die Auswahl aus zwei Frequenzbereichen an.

    Beim KUKA habe ich in den Maschinendaten jedoch nie einen Parameter dafür gesehen- was aber nicht heisst, dass es ihn nicht gibt. Vielleicht mal bei KUKA nachfragen? Möglicherweise erfordert das weitere Anpassungen der Servoparameter jeder Achse.

    Wenn sich der Roboter während der Prüfung nicht bewegen muss, kann man auch einfach die Bremsen einfallen lassen...

    Vielleicht bekommt man "leisere" Servos teilweise auch durch eine Anpassung des Fahrprofils hin (robcor.dat), da wüsste ich aber keine Details.

    Bei der S4C+ wies ABB früher extra darauf hin, dass es eher nicht möglich sei, zyklische Hintergrundtasks ohne Wartezeit zu verwenden, weil sonst die Haupttask ins Hintertreffen geraten könnte. Selbst in SPS-Tasks mit Steueraufgaben habe ich dann auch später noch immer ein WaitTime 0.1 eingebaut, das reichte dann offiziell und auch aus der Erfahrung - in der Wartezeit erledigt der Computer dann die anderen Dinge.

    Es gibt keine Gleichzeitigkeit. Du kannst nicht einmal sicher sein, dass ein Block von PERS oder auch EAs, der von einer Task beschrieben wird, sich nicht mitten im Schreibvorgang befindet, wenn die andere Task lesen will. Wer sich drauf verlässt, dass in einer Task zwei Programmzeilen hintereinander stattfinden, ohne dass eine andere Task zwischendurch stattfindet, wird mit sporadischen Fehlern der mysteriösen Klasse belohnt - je zeitlich enger, desto seltener, aber nicht "nie".

    Bei nicht laufenden Motion-Tasks (also die, die erst über ein Startsignal gestartet werden), kommt noch irgendein Nachdenkvorgang vom System hinzu, insbesondere, wenn eines der beteiligten Module neu geladen wurde. Da bin ich auch schon allerübelst auf die Schnauze gefallen - das geht durchaus so weit, dass ein "WaitSyncTask" am Anfang nicht funktioniert, weil die Konkurrenztask noch gar nicht richtig läuft, mit der Folge, dass der Robbi, der warten sollte, durchmarschiert. (Jedenfalls war das mal bei bestimmten RW-Versionen so, weiß nicht, ob das immer noch so ist.)

    Ich hab' mir jedenfalls angewöhnt, "Gleichzeitigkeit" zwischen Tasks oder auch zwischen Task und EA-System als "totally random" anzusehen und das beim Programmieren zu berücksichtigen.

    Is' vielleicht nicht wirklich hilfreich, aber so macht das niemand und man versteht es auch nicht.

    ENTWEDER man programmiert mit den Inline-Formularen, gibt dort die Werte ein, die man braucht, und ist fertig damit.

    ODER man schreibt das Programm von Hand. Dann befüllt man aber keine LCPDAT und so'n Gedöns, sondern man schreibt die modalen(!) Zuweisungen an die passenden Stellen ins Programm. Im Idealfall ist dann die *.DAT komplett leer.


    Bei VEL = 2 m/s wirst Du in T1 keinen Unterschied bemerken, da der Robbi auf 0.25 m/s begrenzt. Standardmäßig nicht proportional, sondern eben gedeckelt (kann man aber irgendwo umschalten, wenn man das will).

    Bei PTP wird die Geschwindigkeit prozentual vom Maximum angegeben, deshalb merkste das da.

    Man muss auch im Hinterkopf behalten, dass KRL seit 30 Jahren oder so weitgehend zu sich selbst abwärtskompatibel ist. Nicht vollständig, aber doch in wesentlichen Eigenschaften. Was früher aus der Not heraus als Konvention festgelegt wurde, ist heute vielleicht nicht mehr zeitgemäß - aber nun eben Standard. Und so gibt es ein paar Merkwürdigkeiten, über die Du jetzt stolperst - und die man uns 1998 in Augsburg schon als "ist eben so, weil man das früher so haben wollte" erklärte.

    Wenn beide Fälle gleichzeitig auftauchen hat die Reaktion auf die Kollision Vorrang (niedrigere Prio Zahl). Die Bauteilaufnahme wird abgebrochen und ein Rückzug ausgelöst.

    Die Sichtweise ist nach meinem Verständnis nicht korrekt. Es gibt kein "gleichzeitig".

    Wenn 30 zuerst auslöst, mag 31 nachträglich löschbar sein, und alles ist gut. Wenn 31 zuerst auslöst, bekommst Du eine Verschachtelung im Aufrufstapel, falls 30 es schafft, vor dem Abschalten auch noch auszulösen.

    Wenn Du jetzt sagst:

    Sobald ich jedoch wieder in dasselbe Programm springe

    legt das nahe, dass der Aufrufstapel nicht gelöscht wurde, sondern nur der Programmzeiger versetzt. Die unterbrochene Interruptroutine würde dann wieder aufgenommen, oder?

    Dann kommt's auf die Stellung des Tools während der Aufnahme des Bildes an. (Davon ausgehend, dass die Kamera nicht am Roboter hängt.)

    Wobei Du im deinem Programm eher ein "SearchL" nachgebaut hast und keine echte Korrektur machst.

    Bei einer Korrektur würdest Du einfach vom Kamerawert 150 abziehen und hättest die Abweichung als Zahl, die man dann - bevorzugt in einer Frame-Multiplikation - mit dem Start verrechnet.

    Ist das Techpaket denn überhaupt installiert?

    Die Systemdateien werden bei der Installation erweitert. Der erste Fehler deutet darauf hin, dass der ENUM-Datentyp "DIGINCODE" gar nicht existiert. In WV kann man das recht einfach erforschen, indem man mit Rechtsklick auf Datentyp oder Variable und "gehe zu Deklaration" in an die entsprechende Stelle springt.

    Die Anleitungen sind allgemein nicht immer ganz sauber, manchmal haben die sich in der Doku auch schlicht verschrieben...

    Und dann: hast Du RE: Syntaxfehler bei DIGIN ON gesehen, bzw. ist Dein Gerät alt genug?