Beiträge von halbesYoyo

Zitat von Programmiersklave

Steht so im Handbuch

Moin Michael,

steht auch in der Fehlermeldung drin (Siehe oben). Nach ein bissl rumprobieren hat sich das (bereits mehrfach bewährte) Umladen des Wertes als Lösung gefunden:

PERS loaddata lWeight{16} := [ [], [], ...];
  PERS loaddata lWeightCurrentPart := [...];

  ...

  lWeightCurrentPart := lWeight{nCHousTyp};
  GripLoad lWeightCurrentPart;

Nicht schön, funktioniert aber.

Gruß
Jörn

Moin,

ich habe eine handvoll Bauteile, für die ich die Lastdaten ermittelt habe. Sie stehen in einem Array:

! Loaddata of the part (weight, COG, ...).
  PERS loaddata lWeight{16} :=
  [
    [1.7, [-1183.9, -49.7, 322.2], [1, 0, 0, 0], 0, 0, 0],
    [1.7, [-1183.9, -49.7, 322.2], [1, 0, 0, 0], 0, 0, 0],
    [2.5, [-1261.6, -90.8, 225.6], [1, 0, 0, 0], 0, 0, 0],
    ...
  ];

Wenn ich die Lastdaten mit GripLoad lWeight{nCHousTyp} zuweisen will, bekomme ich die Fehlermeldung 41422 angezeigt:

41422: Referenzfehler
Der Verweis in Argument Load ist keine vollständige persistente Variable.
...
Datensatzkomponente oder Datenfeldelemente nicht in Argument Load verwendbar. Nur vollständige persitente Variablen sind für Tool, WObj oder Load in einer Bewegungsinstruktion möglich.

Das verstehe ich nicht so ganz. Was ist denn eine "vollständig" persistente? Ein PERS Array offensichtlich nicht.

Ich hab versucht den Roboter auszutricksen:

PERS loaddata lWeight_1  := [1.7, [-1183.9, -49.7, 322.2], [1, 0, 0, 0], 0, 0, 0];
  PERS loaddata lWeight_2  := [1.7, [-1183.9, -49.7, 322.2], [1, 0, 0, 0], 0, 0, 0];
  PERS loaddata lWeight_3  := [2.5, [-1261.6, -90.8, 225.6], [1, 0, 0, 0], 0, 0, 0];
  ...

  %"GripLoad lWeight_"+ValToStr(nCHousTyp)%;

Das hat leider nicht geklappt. Da poppte folgende Meldung auf:

40226: Ungültiger Name
Prozedurname GripLoad lWeight_3 ist kein RAPID-Bezeichner, reservierte Wörter ausgeschlossen.
...
Prozedurname muss ein zulässiger RAPID-Bezeichner sein, der nicht identisch mit reservierten Wörtern der RAPID-Sprache sein darf. Namen ändern.

GripLoad ist aber eine PROC.

Gibt es eine einfache Möglichkeit, oder muss ich jetzt tatsächlich ein riesiges TEST aufmachen:

TEST nCHousTyp
        CASE 1:
          GripLoad lWeight_1;
        CASE 2:
          GripLoad lWeight_2;
        ...
      ENDTEST

Vielen Dank für alle sachdienlichen Hinweise.

Gruß
Jörn

Hab ich eben ausprobiert. Neues Signal erstellt. Nur Name und Typ angegeben. Warmstart. Im Programm einen Wert zugewiesen. Funktioniert einwandfrei!

Vielen Dank.

Gruß
Jörn

Und wie definiere ich dann ein Signal als virtuell? Wenn ich ein neues (virtuelles) Industrial Network ohne Name hinzufügen will, bleibt der [OK] Button ausgegraut.

Bei den Signalen selber kann ich nirgendwo Virtual oder Simulated auswählen.

Gruß
Jörn

Moin,

ich versuche in RobotStudio ein PROFINET Device für virtuelle Signale einzurichten:

Konfiguration -> I/O System -> Industrial Network -> [RMB] -> Neu Industrial Network...

Das Identification Label kann ich ausfüllen und Simulated kann ich auswählen, aber der Parameter Name ist schreibgeschützt.

Direkt am Panel das gleiche:

ABB -> Systemeinstellungen -> Konfiguration -> Industrial Network -> Virtual

Vor dem Virtual ist ein kleiner Schlüssel abgebildet. Klicke ich auf Bearbeiten wird ganz oben Schreibgeschützt angezeigt und alle Werte sind ausgegraut.

Ein neues anlegen geht ebensowenig:

ABB -> Systemeinstellungen -> Konfiguration -> Industrial Network -> Hinzufügen

Auch hier ist der Parameter Name ausgegraut, als Wert sieht man hier aber tmp0 eingetragen.

Ich habe schon jeden Benutzer ausprobiert und der Security Manager sollte eigentlich passende Rechte haben (Installierte Systeme verwalten, Konfiguration ändern, Steuerungseigenschaften ändern).

RobotStudio 6.08
RobotWare 6.07
Option 888-3 Profinet Device ist vorhanden

Weiß jemand warum es schreibgeschützt ist und wo/wie ich den Schreibschutz aufheben kann?

Gruß
Jörn

Sooo ... an meiner Station wird gerade eine Ausrichteinheit versetzt, deswegen hatte ich ein bissl Zeit. Derweil hab ich mir das Teachen von robtargets in Arrays und Records angeschaut.

Gruß
Jörn

<snip>
RECORD recTestRobtargets
robtarget numberOne;
robtarget numberTwo;
ENDRECORD

PERS recTestRobtargets robtargetRecordTest{2} :=
[
[
[[0,0,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],
[[0,0,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]]
], [
[[0,0,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],
[[0,0,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]]
]
];

PERS robtarget robtargetArrayTest{2} :=
[
[[0,0,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],
[[0,0,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]]
];

PERS robtarget rBuffer := [[0,0,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
<snap>

<snip>
! So kann das robtarget geteached werden, indem man das komplette MoveL oder
! auch nur das robtargetArrayTest{1} markiert und "Position korrigieren"
! antippt.
MoveL robtargetArrayTest{1}, v10, fine, tGripper;

! Mit dieser Schreibweise kann das robtarget dann geteached werden, wenn man
! nur das robtargetArrayTest{nTypeToTeach} markiert und "Position korrigieren"
! antippt. Das Panel fragt dann nach dem Index des Array-Elementes, das
! geändert werden soll.
nTypeToTeach := 2;
MoveL robtargetArrayTest{nTypeToTeach}, v10, fine, tGripper;

! So kann das robtarget nicht geändert werden. Wenn man nur das
! robtargetArrayTest{nTypeToTeach}.numberOne markiert und "Position
! korrigieren" antippt fragt das Panel zwar nach dem Index, es wird aber
! nur die Schaltfläche "Schließen" angezeigt. Einen Index kann man nicht
! auswählen.
MoveL robtargetRecordTest{1}.numberOne , v10, fine, tGripper;

! Genau wie zuvor. Ein robtarget in einem RECORD kann man weder direkt noch
! indirekt teachen ...
nTypeToTeach := 2;
MoveL robtargetRecordTest{nTypeToTeach}.numberOne , v10, fine, tGripper;

! ... man muss den Umweg über einen Puffer gehen. Hier funktioniert es dann aber
! wieder wie im ersten Fall. Das komplette MoveL oder nur rBuffer markieren, usw..
! Man darf nur nicht vergessen die nächste Zeile mit der Zuweisung auszuführen,
! sonst steht die geänderte Position anschließend nicht in robtargetRecordTest{nTypeToTeach}.numberTwo
! Zudem muss der Puffer als PERS deklariert und mit Wertzuweisung vorhanden sein.
! Siehe dazu auch voriges Posting.
nTypeToTeach := 2;
rBuffer := robtargetRecordTest{nTypeToTeach}.numberTwo;
MoveL rBuffer, v10, fine, tGripper;
robtargetRecordTest{nTypeToTeach}.numberTwo := rBuffer;
<snap>

Zitat von Iceberg

... Noch dazu wird man die Vorteile einiger Vorschläge auch erst verstehen, wenn man mal so programmiert hat ...

Sehe ich genauso. Mit steigender Erfahrung kristallisiert sich das irgendwann heraus. Besonders im Hinblick darauf:

Zitat von Programmiersklave

... Häufiges und ernstzunehmendes Beispiel ist die Produktinflation, wenn auf einer Anlage mehrere laufen sollen. Wenn mir einer sagt: "auf der Anlage laufen später zwei Produkte!", dann multipliziere ich gedanklich mit 50. Was bei zwei vielleicht noch übersichtlich ist, wird bei 7 (kommt immer was dazu) unerträglich. Lege ich im Vorhinein Arrays und Switches an, um das bis dahin fiktive Problem einzugrenzen, ist das Programm nicht mehr ganz so übersichtlich, lässt sich aber einfach erweitern ...

Ich programmiere auch lieber mit Variablen. Bei wenigen Verwendungsstellen mag das übertrieben erscheinen, aber wenn man das erste mal mehrere Positionen ändern muss, die dutzendfach im Code verwendet werden, lernt man es zu schätzen, obwohl es etwas Mehraufwand ist.

Bei Vergleichen hat sich bei mir gut bewährt: Bis 2 Vergleiche verwende ich IF, für alles darüber hinaus CASE. Und, ganz wichtig, falsche Wertebereiche immer mit ELSE bzw. DEFAULT abfangen! Sonst macht das Programm u.U. ziemlich merkwürdige Sachen. Schlimmstenfalls bewegt sich der Roboter irgendwo hin, wo schon was anderes ist. Und da fängt dann der lustige Teil an. Interessanterweise haben Bediener für sowas ein geradezu magisches Händchen.

Gruß
Jörn

Das Forum ist mittlerweile hier zu finden:

https://forums.robotstudio.com

Gruß
Jörn

Zitat von Krayzzee

Eine weitere Frage die mich beschäftigt: Wie gehe ich am besten vor wenn ich ein Projekt in angriff nehme?
Zuerst die sicherheitsrelevanten Sachen oder doch zuerst die gewünschte Funktion und dann den Rest außen rum?
In welcher Reihenfolge ist es am sinnvollsten zu arbeiten?

Das hängt von den genauen Umständen ab. I.d.R. richte ich anfangs eine SafeZone in SaveMove ein (bei KUKA SafeOperation!?), die der Größe der Zelle, d.h. dem Schutzzaun drumherum, entspricht und die der Roboter nicht verlassen darf. Dann kommt der eigentliche Programmablauf und zuletzt - wenn ich weiß wo der Roboter wann hin muss - grenze ich die SafeZone entsprechend ein. Sonst musst Du während des Programmierens da schlimmstenfalls mehrfach drin rumpulen. Je nach Projekt kommt u.U. auch eine Achsbegrenzung hinzu.

Auf größeren Baustellen mit viel Publikumsverkehr ist das Einrichten einer NOT-Aus-Verkettung und/oder eines Bedienerschutzes (wie Schutztüren, Lichtgitter, ...) vor dem Umschalten auf den Automatikbetrieb auf jeden Fall dringend anzuraten (1), da sich immer mal wieder "plötzlich" irgendwelche Leute ohne weiteren Kommentar in die Roboterzelle verirren! :angry:

Gruß
Jörn

(1) Ehrlich gesagt weiß ich nicht, wie die rechtliche Lage dazu ist. Da kann vielleicht jemand anderes etwas detaillierter drauf eingehen?

Moin Krayzzee,

vorweg sei gesagt, daß alleine Einrückungen und die Wahl sinnvoller Variablen- und Unterprogrammnamen schon die halbe Miete sind.

Auf dieser Seite (1) ist das Thema insgesamt relativ ausführlich behandelt. Die meisten Programmierer haben Vorlieben und werden das eine oder andere im Detail sicherlich anders machen. Wie Du es ganz am Ende machst bleibt natürlich auch Dir überlassen. Aber es ist eine gute Basis.

Nachtrag:
Gerade bei größeren Projekten finde ich Programmablaufpläne sehr sinnvoll. Für Windows kann ich den PAPDesigner empfehlen. Klein, schlank und für Privatpersonen kostenlos.

Gruß
Jörn

(1) https://de.wikibooks.org/wiki/Strukturierte_Programmierung

Zitat von Sven Weyer

es ist mit zwei Funktionen möglich. Die aktuelle Position in der aktuellen Konstellation in Achsdaten, CalcJointT - Berechnen der Achsenwinkel vom Roboterziel. umrechnen un die Achsdaten kann man dann beliebig auf andere Koordinatensysteme umlegen, CalcRobT.

Moin,
genau die Info habe ich gesucht. :kiss:

FUNC robtarget TranslateRobtarget(robtarget rSource, PERS tooldata tSource, PERS tooldata tTarget, PERS wobjdata wSource, PERS wobjdata wTarget)
  var jointtarget jBuffer;
  var robtarget   rTarget;

  jBuffer := CalcJointT(rSource, tSource \wobj:=wSource);
  rTarget := CalcRobT(jBuffer, tTarget \wobj:=wTarget);

  RETURN rTarget;
ENDFUNC

Gruß
Jörn

Zitat von Joern_E

Steht leider in der "Bedienungsanleitung - RobotStudio" so nicht drin. Ist wohl irgendwie geheim. :angry:

Da muss ich mich korrigieren. Es steht sehr wohl drin, allerdings unter Call Stack.

Gruß
Jörn

Zitat von 6303_6349

... Aus diesem Grund bin ich der Meinung, dass das nicht funktioniert. Zusätzlich meine ich zu den Weltzonen gelesen zu haben, dass diese die SafeMove-Funktionen nicht ersetzen und daher wäre eine Kombination vermutlich auch nicht erlaubt.

Dir bleibt wohl nichts anderes übrig, als SafeMove Pro zu kaufen oder dein Greifer so geschickt zu gestalten, dass er um den TCP symmetrisch liegt und immer den gleichen Abstand zur Weltzone hat

Guten Morgen,

da solcherart Probleme regelmäßig auftauchen hoffte ich auf einen Lösungsansatz von jemandem, der schonmal ein ähnliches hatte. Ich hatte allerdings befürchtet, daß es nicht geht. Deswegen mache ich es jetzt im Programm. Sobald der Roboter die Vorposition verlässt wird ein Zonensignal gesetzt.

Eigentlich ist es egal wo am Greifer sich der TCP befindet. Er ist 1200mm lang und die Zelle ziemlich klein. Die Weltzone müsste so groß sein, daß der Roboter kurz nach dem Verlassen von HOME schon drin wäre. Lange, bevor er die Vorposition erreicht hat.

SafeMove Pro? *träum* Ja, das wäre toll.

Gruß
Jörn

Moin,

kann man eigentlich die in Visual SafeMove für ein Werkzeug festgelegte Geometrie (hier eine Capsule) irgendwie zur Abfrage einer WeltZone benutzen, d.h. kann ich z.B. ein Signal ausgeben lassen, wenn die Capsule um den Greifer sich in eine WeltZone bewegt?

Der Greifer ist für den, wie üblich, sehr begrenzten Platz in der Zelle ein wenig groß geraten, weshalb "nur" die Überwachung des TCP zu so großen WeltZonen führte, daß jede davon einen Großteil der Zelle ausfüllte.

Das System läuft mit RobotWare 6.07 und - leider - nur mit SafeMove Basic (Option 1125-1) und die einzig verfügbare SafeZone ist schon für die Geometrie der Zelle draufgegangen.

Ich bin auch für jeden anderen Tip dankbar, falls es zwar nicht so aber anders geht.

Gruß
Jörn

Moin allerseits,

beim Klicken durch die verschiedenen Menus entdeckt: Signalanalyse online (Unter Steuerung -> Steuerungstools)

Da kann man bis zu 10 eigene Signale, Systemsignale, Eigenschaften der mech. Einheit (z.B. Position, wobj, Motoleistung, ...) und sogar Meldungen des Ereignisprotokolls bunt gemischt auswählen und in einer Art Trace mit Zeitleiste protokollieren lassen. Anschließend kann man sie noch abspeichern.

Gruß
Jörn

Zitat von 6303_6349

...
Oder spricht da etwas dagegen?

Moin,

nur der (trotz alledem) anschließend nötige Neustart. Ansonsten ist es schonmal eine deutliche Arbeitserleichterung. Vielen Dank.

Gruß
Jörn

Moin,

gibt es eine Möglichkeit eine beliebige Zusammenstellung von Ein-/Ausgängen in der Ansicht E/A-System (Steuerung -> Eingänge/Ausgänge) anzeigen zu lassen ohne die Labels bearbeiten zu müssen?

Wie im Anhang zu sehen benutze ich derzeit einen Filter um alle Ein-/Ausgänge anzuzeigen, in deren Namen oder Label Job vorkommt. Ich hätte zusätzlich gerne diMoveEnable und noch einige andere in der Liste. Eine Möglichkeit ist jedes mal die Labels zu bearbeiten, z.B. indem man ShowInList hinzufügt. Geht das auch irgendwie unumständlicher?

Gruß
Jörn

Zitat von Robot1986

... Gibt es Irgendwo eine Übersicht was ich womit bei welchen Rechten Unterbinden kann?
... und kann ich das in der Log Liste sehen wer wann sich angemeldet hat?

Guten Morgen,

schau im RobotStudio mal unter Steuerung -> Benutzerauthorisierung -> Benutzer verwalten bzw. in der Bedienungsanleitung - RobotStudio unter Benutzerautorisierung.

Im LOG wird ein Benutzerwechsel protokolliert, ja.

Gruß
Jörn

Mit geschweiften Klammern werden bei ABB arrays (Datenfelder) deklariert. Arrays können bis zu 3 Dimensionen haben, d.h. ...

VAR num    nEinDimensional{5}      := [1, 3, 2, 5, 2];


VAR string sZweiDimensional{2,3}   := [["bla", "blubb"], ["irgendwas", "nochwas"], ["guckmal", "nummer6"]];


VAR bool   bDreiDimensional{2,2,2} := [[[true, true], [true, false]], [[false, false], [true, false]]];

Für Details guck mal im Technisches Referenzhandbuch - RAPID Überblick ab Seite 31 unter Variablendeklarationen.

Gruß
Jörn

Zitat von EddiFox

... welche Schreibweisen sollte man verwenden?...

Moin Eddi,

welche Schreibweise Du verwendest ist - grundsätzlich - Deiner Vorliebe überlassen. Gut lesbar sind die schon vorgeschlagenen Varianten ...

IF bBool THEN
  ...
ENDIF


IF NOT bBool THEN
  ...
ENDIF

Wenn Du außerdem noch sinnvolle Variablennamen verwendest, wird der Code ohne zusätzliche Kommentare gut lesbar.

Das gleiche Problem wie Du habe ich nämlich auch gerade. Ein Programm, in dem alle möglich Varianten (=TRUE, =FALSE, <>TRUE, ... ) vorkommen. Nach dem Ausmisten und vergeben vernünftiger Variablen-, Prozeduren- und Funktionsnamen konnte ich 90% aller Kommentare entfernen.

Gruß
Jörn