Moin,
als ersten Wurf würde ich sagen du müsstest dir Punkte(Positionen) auf einem Kreisbogen berechnen und diese in circularer Bewegung abfahren. Sind ja nur zwei variable Koordinaten dafür nötig.
Punkte auf einem Kreisbogen sind ja mit sin und cos kein Problem.
Gruß
Sven
Schau einmal unter ABB -> Eingänge und Ausgänge -> EA Einheiten.
Wenn der Roboter nix meldet und dort unter Einheiten deine Einheit mit dem Status "läuft" versehen ist.
Sollte das Thema in der SPS zu finden sein.
Die Signale sind aber schon auf der richtigen Einheit und Port angelegt, oder?
Gruß
Moin,
wir schicken die Real-Werte zwischen den beiden Systemen hin und her über den Feldbus.
Früher haben wir die ganzzahligen Werte im Roboter und SPS gesendet und dann umgerechnet um den korrekten Wert zu bekommen.
Aber die Möglichkeiten haben sich weiterentwickelt und nur kann man mit dem Roboter auf Real-Werte (4byte) senden und empfangen. Was immer noch wichtige ist, ist die Thematik High- bzw. Low-Byte Thematiken. Aber das ist bei ABB auch kein Hexenwerk, je nachdem mit welchem Typ SPS man zusammenarbeitet.
Gruß
Resettaster ist ein blaues Element mit einem schwarzen Taster.
Soweit mir bekannt, gar nicht. Hab das aber, ehrlich gesagt, noch bei keinen Roboter benötigt.
Soweit mir bekannt, kannst du beim Fanuc das nicht beeinflussen über eine Systemvariable.
Gripload kann man auch mit der Lastdatenermittlung ermitteln lassen vom Roboter. 
Phil24 leider frist er mir deine E-mail nicht und sagt unzustellbar zurück, hab diese kopiert von deinem Thread.
Icke habs jewusst!
Och die Doku hätte ich als pdf noch da.
Also das wird so nicht funktionieren.
1. du verwendest FINE -> Damit ist ein MoveSync überflüssig da der PZ eh erst nach erreichen und einregeln der Position weiter macht.
2. MoveSync verwendet den Verschleifbogen, da hier der Aufruf der Routine gestartet wird und je nach Prozessorauslastung du hier nach diesem Punkt eine Abarbeitung der Routine erwarten kannst. Achtung diese Abarbeitung hat nichts mit dem Pfad vom Roboter zu tun sondern ist Prozessorauslastungsabhängig. s.h. Referenzhandbuch -> MoveL/JSync
Deine Routine kann direkt hinter deiner Bewegung stehen und würde damit Funktionieren.
Kurze Frage: Warum hast du dich hier für ein MoveSync entschieden?
Gruß
Jupp, unter Diagnose kannst du sämtliche Signale vom Profinet Safety sehen.
Jupp, hab es gerade mal getestet und hab mich echt geirrt. Mir war so als ob ich das mal früher, wer weiß genau wann, geprüft und getestet habe bei dem Thema REAL<->NUM etc.
Hier war mir so das ich auf irgend eine Situation gestoßen war die nicht gefunzt hatte.
Aber trotzdem, danke für die Info.
Okay, wieder etwas schlauer.
Danke dir.
Wäre mir seitens KRC4 nicht begegnet.
Solche Symptome hatten wir auch schon, war aber immer zu 100% SPS-Themen.
Ich wüsste jetzt nicht das nach dem korrekten Verschalten im KUKA da etwas intern eigenständig passieren sollte.
Gruß
Soweit ich mich erinnern kann wir bei der Version vom Loipe nur der aktuelle Status des Signals beim Aufruf der Routine übergeben aber kein Wechsel des eigentlichen Signals innerhalb der Routine mehr erkannt, somit kann dies eine Signalwechsel nicht erkennen. Kann mich aber auch irren.
Der Vorteil eines ALIAS ist das man den aktuellen Bezug zu dem verbunden Signals hat und dessen aktiven Zustand zu jeder Zeit auswerten kann.
Aber, ich mag mich auch irren.
Und wenn du dir einen string beschreibst könntest du dir das erste Alias sparen, aber Hauptsache es funzt.
Hab das mit dionum vorher auch schon probiert, wird aber von Funktionen nicht als signaldi/do erkannt und somit nicht zu verwenden.
Warum machst du den Alias dort?
Übergib doch den Namen als String und den Alias einmalig im Unterprogramm
Kannst du bitte einmal deine Code posten, macht es eventuell leichter?
