Posts by Sven Weyer

Schau mal beim TotalCommander rein, hier kannst du ganze Ordner incl. Inhalt mit einander vergleichen.

Ist auch kein Invest.

Gruß

Deshalb ist ja die Integration eines separaten eigenen Task, sub Programms, gelegentlich von Vorteil, da hier dann unabhängig von anderen Abläufen ein völlig eigenständiger Ablauf existieren kann.

Du kannst diesen src in der sps.sub einbinden. Sollte kein Problem darstellen.

Aber Achtung vor Warteanweisungeb, wenn benötigt dann ein separates sub Programm definieren, ist ganz easy.

Also die Brücken sind ja nicht nach Plan drin, so scheint es zumindest nach dem ersten Bild.

Naja je nach dem wie ihr das gemacht habt?

Da gibt's einige Möglichkeiten der Ausführung.

Bei SafeMove bleiben diese Brücken alle drin.

Jetzt wirds spannend, was im SaveMove konfiguriert worden ist.

Hier ist ein AutoStop uu definieren incl. einem Safesignal von der SpS.

Entweder du definierst dir ein weiteres subprog oder du kannst es integrieren innerhalb der aktuellen sps.sub. Je nach dem wie groß und aufwendig es ist.

Sollte halt keine Roboterbewegungen enthalten sei . 😉

Kannst du bitte einmal einen Test machen.

Kommentiere mal bitte das Stop und die WaitUntil aus und füge mal bitte ein TPwrite mit eine Meldung fürs TP hinzu.

Dann Teste das bitte noch einmal.

Puh, nee, EPlan IRC5.

Dat weiß ich leider nicht aus dem Kopf. Aber das sieht doch schon Standard gedrückt aus.

Wie hängt der sonst dran an der Safety?

SafeMove?

Könntest du bitte einmal den Inhalt deiner Trap-Routine zeigen?

Was machst du in dem Trap?

Ja das hab ich auch gelesen, das ist wirklich komisch und hat meine Vermutung wieder etwas entkräftet.

Habt ihr eventuell eine weitere MOLEX-Karte zur Hand?

Naja, zumindest wäre es eine kurze Arbeit die drei Phasen mal zu prüfen ob alle fest sind und keine eine Wackler hat.

Kannst du mal kurz beschreiben wie du bei deinem Test vorgehst, nur das man das gedanklich nachvollziehen kann.

Welchen Anschluss hat deine Steuerung?

230V oder 400V, bei 400V kann sich eine Phase verabschiedet haben das kann das ein Auslöser sein.

Achja, versuch einmal es mit Robotstudio in einer anderen RobotWare, man weiß ja nie wo der Fehlerteufel wieder zugeschlagen hat.

Was ich noch einbringen wollte, okay ist eigentlich allgemeines Grundwissen und sollte Voraussetzung sein aber manchmal sind es die unscheinbarsten Dinge.

Interrupts werden nur bearbeitet und der Wechsel des Zustands der definierten Kondition nur erkannt und registriert in der Steuerung wenn das Programm abgearbeitet wird.

Sprich wenn dein Programm nicht läuft wird der Interrupt trotz Definition etc. nicht anschlagen.

Entschuldige, ich gehe eigentlich davon aus das dies Grundlage ist, daher nur als Hinweis noch einmal.

Was auch wichtig wäre ist das sämtliche Interrupts einmal deaktiviert werden sollten, sprich alle zusammen. Nicht das IDelete für jede Definition separat durchführen, sondern für alle vorhanden Interrupts nacheinander so das es eine Situation gibt wo sämtliche Interrupts mit IDelete gelöscht worden sind bevor du den ersten wieder definierst und verbindest.

Hierbei spielt ein interner Zähler in der Steuerung eine Rolle der nur zurückgesetzt wird wenn alle Interrupts einmal gelöscht worden sind.

Wir hatten da schon einmal ein Problem mit dem Überlauf dieser Variablen.

Ich muss mich leider korrigieren IWatch benötigst du nur wenn du vorher mit ISleep den Interrupt deaktiviert hast. nach einer Definition ist dieser in der Steuerung bekannt und aktiv. Wir verwenden das ISleep standardmäßig um eine unfreiwilliges Auslösen zu verhindern. Demnach sollte das eigentlich funktionieren ohne IWatch. Sorry war ich auf dem Holzweg.

Da ich eigentlich keinen Grund sehe warum das an sich nicht funktionieren sollte wenn die Rahmenbedingung gegeben sind.

Jupp, ohne IWatch funzt dat nicht.

Danke Dir,

jupp dort habe ich es gefunden.

Moin DS,

danke für den Hinweis, da kann man so alt werden wie man will aber das mit der Doku lesen wird im alter nicht besser.

Ich habe einmal einer Doku vom RobotStudio nachgesehen und konnte leider dein Kapitel nicht finden.

Ich verwende gerade:

Technical reference manual

RAPID kernel

RobotWare 6.14

Document id: 3HAC050946-001

Revision J

Könntest du einmal prüfen, wenn du Zeit hast , mit welcher Dokumentenversion du arbeitest?

Die Beschreibung zu dem Thema würde mich schon interessieren.

Gruß

Danke dir.

Also ich hab es jetzt noch einmal getestet.

Das Fragezeichen verhindert im RobotStudio einen Fehler, die Steuerung selber merkt dies aber und bringt diesen Fehler in einem normalen Programm wenn man bei der Werkobjetübergabe in Bewegungsinstruktionen das ":=" mit "?" ersetzt und das Werkobjekt nicht vorhanden ist.

Bei deiner Routine ist es so, dass der Übergabeparameter WobJ optional ist und da bei den Bewegungsinstruktionen, auch MoveJ etc., das Werkobjekt nicht zwingen übergeben werden muss, Default wäre wobj0. Wird hier mit dem Fragezeichen dafür gesorgt das du ohne weitere Auswertung, ob die Übergabevariable initialisiert wurde oder nicht innerhalb deiner Routine, die Instruktion für den Roboter abarbeitungsfähig bleibt ohne einen Fehler zu generieren.

Wenn du jetzt alles auf ":=" änderst kann das unter Umständen Fehler erzeugen.

Interessante Information, liegt aber nur daran das die Bewegungsinstruktionen den Parameter wobj als optional ansehen.

Also schön vorsichtig mit deinen Änderungen.

Am besten mal im gesamten Programm nach schauen ob dort deine Routinen auch einmal ohne Wobj-Übergabe aufgerufen werden.