Beiträge von Programmiersklave

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.

Zitat von doc_rob

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:

Zitat von doc_rob

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?

Zitat von HighPerformance_GmbH

v=0.00278521mm/s

Sportlich, angesichts des Umstands, dass speeddata aus 4 num besteht und die sind traditionell single precision floating points....

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?

Wenn da irgendwo in einer .DAT steht:

SIGNAL variablendings $IN[20] TO $IN[28]

dann kann man das oft auch umändern in

SIGNAL variablendings $OUT[2000] TO $OUT[2008]

und es interessiert die Funktion, die nur lesend auf "variablendings" zugreift, nicht die Bohne.

Man selbst aber kann - entweder über die Variablenansicht oder über die Ausgangsansicht, oder auch über den Hintergrundtask programmiert - die Variable bzw. die Ausgangssituation ändern, weil es ja nicht mehr schreibgeschützt ist.

Das meinte ich nur, wäre vielleicht einen Versuch wert.

Mh, okay.

Ich weiß nur, dass man die Signaldefinition oft umleiten kann. Das Programm greift auf die benannte Variable zu, und ob hinter der jetzt $IN[..] oder $OUT[...] als Definition steht ist dann egal. Gelesen werden kann beides, letzteres eben dann auch von anderer Stelle aus geschrieben.

Wie das bei dem Techpaket ist weiß ich aber nicht....

Es gibt keinen Grund, DI zu setzen, außer man will sich selbst starten.

Soll sich der Roboter selbst starten?

Zitat von Florian Laufer

Alternativ kannst du auch das Programm "VirtualBox" nutzen.

Kann VirtualBox das jetzt? Nested VMs?

Ja, Ihr habt ja recht, muss ich mal basteln, als Einzelkämpfer kann ich das ja jetzt auch machen. Früher musste ich Rücksicht auf die Kollegen nehmen, bzgl. des Änderungsdatums der Datei. An Einigen quetschte sich der Fortschritt mit Gewalt vorbei....

Metadaten für das Dateihandling unter Windows

Readable

Visible - die BAS.SRC z. B. wird im Programmablauf nicht angezeigt, dort fehlt das V

...

Offline erzeugte und in das System geladene Dateien kommen aber durchaus ohne diese Zeile aus und bekommen diese auch nicht zwangsläufig, solange man sie nicht über das Panel manipuliert.

Nett wär's, wenn KUKA das aus dem Archiv raushalten könnte. Naja, ausser &COMMENT vielleicht. &REL und &ACCESS vermüllen einem die Versionsverwaltung... aber das ist nur so'n Luxustraum.

Oder relTool oder im Target rumbasteln oder PoseMult oder was auch immer... Möglichkeiten gibt's viele.

Leider würde sich der Threadersteller nur über Ideen freuen, statt eine konkrete Frage zu äußern.

So mag ihn vielleicht die Idee freuen, dass sein MoveJ (?) an der Stelle sicher innerhalb einer gegebenen Konfiguration liegen sollte, um keine bösen Überraschungen zu erleben.

Und vielleicht freut er sich über die Idee, den Weg, den er von der SPS bekommt, sicher zu begrenzen, weil die vielleicht auf die Idee kommen könnte, ihn einen Meter in das Bauteil reinzuhämmern.

Und 'ne ganz gute Idee, über die man sich freuen könnte, wäre, dass man daran denken mag, dass die Situation auf dem E/A-Bus (sollte man einen solchen verwenden) zum Zeitpunkt des Lesens durch den Roboter nicht zwangsläufig dem entspricht, was die SPS im Sinn hatte, und deshalb ein solider Handshake eingebaut werden sollte.

Dass die Verwendung eigener Bewegungsbefehle möglicherweise in dem Zusammenhang eine weniger gute Idee war, ist dagegen unerfreulich, weil mit Arbeit verbunden. (RelTool oder Offs würde vermutlich trotzdem funktionieren)

Zitat von AtoK09

Ja? Warum?

Diese Ereignisroutinen sind auf ihre Weise nebenläufig innerhalb der Bewegungstask, meinen unangenehmen Erfahrungen nach. Die lassen sich auch nicht per Stop beenden, nicht abwählen, der PZ lässt sich nicht beeinflussen etc..

Eine Ereignisroutine auf PowerUp, die nicht endet, führt zu einer Blockade des Systems in der Weise, dass das Programm in der Bewegungstask immer als laufend angesehen wird, mit allen negativen Folgen. Programmanwahl? Editieren? Neustart? Halten sie erst das Programm an. Und dann hilt es ja nichts, denn es ist ja auf PowerUp.

Letztlich provoziert man dann einen Systemfehler und macht einen der erweiterten Neustarts, um das System überhaupt wieder lauffähig zu bekommen.

Bin aber tatsächlich nicht sicher, was passiert wenn man "main" nimmt. Aber ich würd's auch nicht probieren wollen.

Zitat von rmac

irgendetwas Simples

?

Zitat von AtoK09

Ich meine "einfach" mal eine Eventroutine erstellen, Main mit Power_On verknüpfen... versuchen

Uh.. das wird kein gutes Ende nehmen, fürchte ich.

Zitat von RobiMan

kann ja auch eine Weltzone setzen das Signal oder ein Trigger oder oder oder

kommt halt drauf an wie knapp die Zeit ist und wie nahe ran du an die Überwachte Zone schnell fahren musst.

Er ist ja hier schon drin, das ist ja das Ausgangsproblem. Nicht "der Robbi fährt in die sichere Zone", sondern "die Zone wird plötzlich zur sicheren", dadurch, dass der Werker reingeht.

Das ist erst einmal unlösbar, solange die Sicherheitstechnik nicht differenzieren kann, wie weit der Werker vom Roboter weg ist.

Wenn sie das kann (beispielsweise mit einem "äußeren" und einem "inneren" Bereich) ist es ja sofort kein Problem mehr. Werker geht in den äußeren Bereich -> Roboter bremst ab -> Werker erreicht den inneren Bereich -> Roboter hat limitierte Geschwindigkeit. Springt der Werker mit Anlauf, knallt die Überwachung rein.

Das wird so - in diversen Abwandlungen - ja in unzähligen Anlagen so gemacht. Nur geht es halt nicht mit einem einzigen Signal, welches man geschickt verzögert, aus guten Gründen.

Kannst ja mal messen, wie lange Deine sps.sub für einen Durchlauf braucht... nicht wundern, wenn das Ergebnis 12ms zeigt (oder, in extremen Fällen, ein Vielfaches davon).

Sie ist nur nicht synchron zu irgendwas, das muss man im Hinterkopf behalten.

Der Satzvorlauf ist freilich eine Sache...

Zitat von Brgs

Kann man den irgendwie dauerhaft deaktivieren

Ich hab' kein Image mehr von den alten Sachen zur Hand und weiß daher nicht, ob der Ikarus darin gestartet wird - aber in sehr seltenen Fällen lohnt vielleicht ein Blick in die \KRC\BIN\StartKRC.exe.config, gerade was Timeouts angeht (auch testweise) und manchmal auch Startreihenfolgen von Optionen.

Wenn's nur eine Denkaufgabe ist...

Der Code ist schon oberflächlich betrachtet Quark, weil ERST das $Base zugewiesen wird, um es DANACH neu zu berechnen, aber mit dem ALTEN noch gefahren wird. Dadurch hängt der Regler eh' einen Schritt hinterher.

Warum man in der .sub nicht auch gleich die Istverschiebung laufend berechnet (nicht das Base, aber die Istposition vor der Übernahme in selbiges) ist mir auch nicht klar. Die wäre ja deutlich sensitiver als das Fahrprogramm.

Und dann müsste man sich vielleicht mal Gedanken machen über das Regelverhalten. Einfach nur I ist vielleicht zu wenig.