Beiträge von Kevin97

Zitat von Andi13130

Jetzt stellt sich mir noch die Frage mit welcher Geschwindigkeit hier der Roboter fährt?
Grundsätzlich funktioniert das so, das hab ich grade am Robi getestet.

Du kannst die Geschwindigkeit für die Lin-Fahrt vorher beschreiben wenn du den Punkt nicht per ILF aufrufst.

$VEL.CP=0.5 ;gewünschte Geschwindigkeit

LIN Xziel:Offset

ich weiß die Frage war etwas komisch...

Danke euch allen für die Antworten!

Zitat von Robonator

Bei "WAIT FOR Input1 AND Input2 AND Input3" ist es egal in welcher Reihenfolge die 3 Signale auf TRUE gehen. Du sagst dem Robi ja nur, warte bis die Bedingung erfüllt ist. Da ist die Reihenfolge egal.

Zitat von woodys

Wenn man es genau nimmt hast du ja mindestens 8 Optionen.

Wie mein Vorredner schon sagte, wäre Option 2 die Reihenfolge dann egal ....

Ja also das die Reihenfolge wie ich den Befehl aufschreibe egal ist, ist mir klar, was ich aber eigentlich wissen wollte war mehr im Sinne von es sind als Beispiel 3 Eingänge von 3 Greifern.

Greifer 1 ist so gedrosselt eingestellt das er 50 Sekunden zum öffnen braucht.

Greifer 2 und 3 brauchen nur 20 Sekunden

Weiß der Roboter bei Option 2 denn jetzt nach 20 Sekunden schon das zwei Bestandteile der "Gesamtbedingung" erfüllt sind und hat es sich doof gesagt schon "gespeichert" oder kontrolliert er diese beiden Bestandteile erst nach 60 Sekunden nachdem der erste Eingang da war ?

Wie gesagt, das er auf die Gesamtbedingung wartet ist mir klar, ich wüsste halt nur für mich gerne ob er bei Option 2 trotzdem eine Reihenfolge einhält in der er prüft oder es ".sub mäßig" immer wieder durchkontrolliert wird bis irgendwann alle Bestandteile erfüllt sind

Hallo zusammen,

bei mir ist letztens eine Frage aufgekommen auf die ich bisher keine wirkliche Antwort finden konnte...

Es ist eine ziemlich banale Frage, aber trotzdem, wie ist die Bearbeitungsreihenfolge von "WAIT FOR" Befehlen ?

Was genau meine ich..

Wenn ich zum Beispiel auf 3 Eingänge warten will habe ich theoretisch ja mal zwei Optionen:

Option 1:

WAIT FOR Input_1
WAIT FOR Input_2
WAIT FOR Input_3

Hier ist die Reihenfolge in der die Befehle abgearbeitet werden ja klar.

Option 2:

 WAIT FOR Input_1 AND Input_2 AND Input_3

Spielt hierbei jetzt die Reihenfolge eine Rolle bzw. was ist die Reihenfolge in der die Signale geprüft werden ?

Also klar, es wird darauf gewartet, dass die "Gesamtfunktion" True ist, aber kontrolliert die Steuerung hier auch erst Input_1 und erst wenn dieser dann True ist Input 2 und dann 3 oder passiert das Schreibreihenfolgen unabhängig ?

Wirst du wohl als Optionspaket kaufen müssen wenn ich das richtig verstanden habe...

Das Optionspaket "AppTech" z.B. muss übrigens tatsächlich lizensiert werden. Man erhält beim Kauf von Kuka eine Lizenz dabei. Die muss sich auf der Steuerung befinden und wird immer wieder im Hintergrund überprüft.

Ist die Lizenz abgelaufen und/oder nicht vorhanden, wird der EXT Modus gesperrt und man kann den Roboter nur noch in T1/T2 bedienen.

Denke mal das sowas auf Dauer bei mehreren neuen Optionspaketen folgen wird..

Wenn ich mich nicht täusche benötigte man für OfficeLite ja auch eine gültige Lizenz.

Im Zweifelsfall:

Anzeige -> Variable -> Einzeln -> "$PAL_MODE" eingeben und bei neuer Wert FALSE eintragen. Wert setzen.

Nachher dann das selbe nur mit TRUE als neuer Wert.

Für alle die eventuell auch nochmal das Problem haben..

Vorgehensweise:

> Dateien in Template-Ordner kopieren

> Auf Win wechseln, C:\KRC\UTIL\KRCCONFIGURATOR\KrcKonfigurator aufrufen, Reiter "Templates, Templates list"

> Neues Template Definieren (Name, -> Add to all…

> Enable for Directory (Directory Default ist nicht ausreichend! -> Program usw. extra einrichten!, Vergleich mit den bestehenden Templates)

> Full path setzen (es muss natürlich das betreffende neue src/dat-File im Template-Ordner vorhanden sein.

> Define for users

> Apply

Bin zwar aus der Kuka-Sparte aber finde die Idee grundsätzlich gut, bin eh ein Freund davon eher einen "vernünftigen" Dauerlauf zu haben als eine bis ans Ende ausgereizte Taktzeit mit dafür häufig verbundenen Fehlern.

Ein weiterer Vorteil wäre nach außen hin natürlich aus der der Roboter "keine Stillstands Zeiten" mehr hat, was ja alle immer gerne sehen wollen.

Sehe nur auf Dauer ein Problem von eventuell anderen abhängigen Anlagenteilen...seien es Sensoren die wegen gewissen Bauteilen früher/später kommen oder Mechaniken die verschleißen und mal länger brauchen können.

Dann fängst du nach einem "langsamen" Prozess an nach unten zu regeln, wobei der nächste aber wieder so schnell ist das die Anlage sogar auf den Roboter wartet

Vielleicht wäre es ja eher eine Idee mal z.B. 100 oder 1000 Durchgänge zu beobachten und dann gewisse Geschwindigkeiten & Beschleunigungen einfach Dauerhaft zu reduzieren wenn immer die nahezu selbe Stillstands Zeit besteht

Ich weiß nicht ob ich dich richtig verstanden habe, aber prinzipiell könntest du deine Startposition jedes mal neu errechnen lassen und über manuell eingegebene verschieben.

Am besten legst du dafür Variablen an, die du dann wenn nötig einfach mit einem Wert beschreibst und ansonsten eine 0.0 einträgst wenn sich nicht verändert

z.B.

DECL REAL Verschiebung_X=100.0
DECL REAL Verschiebung_Y=50.0
DECL REAL Verschiebung_Z=10.0


XStartposition_Neu=XStartposition
XStartposition_Neu.X=XStartposition.X + (Verschiebung_X)

XStartposition_Neu.Y=XStartposition.Y + (Verschiebung_Y)
XStartposition_Neu.Z=XStartposition.Z + (Verschiebung_Z)


PTP XpStartposition_Neu

Die Lizenz muss für jeden Roboter einzeln erworben werden.

Das wird sogar überwacht. Ohne gültige Lizenz kann die Anlage nicht in EXT betrieben werden.

(Für den Fall kann für ein paar Tage eine "Notfall Lizenz" aktiviert werden, das funktioniert aber auch max. 3 mal glaube ich.

Ich persönlich finde AppTech völlig überladen... (gibt dennoch einige Sachen die ich gut finde)

Du hast aber halt immer "alles" dabei und musst/solltest rauslöschen was du nicht benötigst.

Solltest du/ihr wirklich AppTech einsetzen wollen würde ich die Schulung definitiv empfehlen.

Du kannst dich halt auch durch die Doku arbeiten, aber die direkte praktische Umsetzung schadet auf keinen Fall.

Sofern die Anlage/Roboter also nicht schon steht und du direkt dran kannst würde ich definitiv die Schulung empfehlen.

Ja habe ich.

Haben es bei uns an 3 Anlagen im Einsatz.

Was willst du wissen ?

Martl

Ja kann ich auch nicht so ganz nachvollziehen...mit vernünftigen Signalnamen arbeitet es sich viel leichter

falkone63

Habe die Tage eben eine Bauteil Auswertung mit Timer geschrieben.

Bin allerdings auch noch nicht zum testen gekommen. Vielleicht hilft es dir ja trotzdem weiter oder inspiriert dich

DEF Bauteil_Auswertung ()

IF diBauteil_IO THEN                         ;Wenn SPS sagt Bauteil ist IO
 $TIMER[1]=-2000                             ;Timer auf 2 Sekunden einstellen
 doAbstecker_Out=TRUE                        ;Abstecker ausfahren lassen
 TimerAction(#TimerStart, 1, -1)             ;Timmer starten
 WHILE $TIMER[1]<=0                          ;Wenn innerhalb der zwei Sekunden:
  IF diAbstecker_Out THEN                    ;Endlage Ausgefahren erreicht
   TimerAction(#TimerStop, 1, -1)            ;Timer stoppen 
   doAbstecker_Out=FALSE                     ;Ausfahren nicht mehr ansteuern
   doBauteil_IO=TRUE                         ;Bauteil auf IO schreiben
   doBauteil_NIO=FALSE                       ;Bauteil NICHT NIO schreiben
   ELSE                                      ;Falls Endlage ausgefahren nicht kommt:
   ;TimerAction(#TimerStop, 1, -1)            ;Timer Stoppen
   doAbstecker=FALSE                         ;Ausfahren nicht mehr ansteuern
   doBauteil_IO=FALSE                        ;Bauteil NICHT auf IO schreiben
   doBauteil_NIO=TRUE                        ;Bauteil auf NIO schreiben
  ENDIF
 ENDWHILE

 IF doBAuteil_NIO THEN                        ;Wenn wir NIO melden: 
  WAIT FOR diBauteil_NIO AND NOT diBauteil_IO ;Warten das die SPS den Zustand auch auf NIO aendert
 ENDIF                                        ;Sonst wenn weiterhin IO nix tun
ENDIF

WAIT SEC 0
doAbstecker_In=TRUE                         ;Abstecker einfahren lassen
WAIT FOR diAbstecker_In                     ;Endlage eingefahren erreicht
doAbstecker_In=FALSE                        ;Abstecker einfahren lassen zuruecknehmen

END

Zitat von Martl

;Meldungen zur SPS => Niveau und/oder Druck n.i.O.

IF (($IN[21] == FALSE) AND ($OUT[50]=FALSE)) THEN

$OUT[50]=TRUE ;Fehler Niveau n.i.O. zur SPS

ENDIF

IF (($TIMER[1]>=0) AND ($OUT[50]=FALSE)) THEN

$OUT[51]=TRUE ;Fehler Druck n.i.O. an SPS

ENDIF

ENDIF

Alles anzeigen

Das wird aber so nicht funktionieren oder doch ?

Müsste nicht "$OUT[50]==FALSE" in der IF Bedingung stehen ?

Ich würde dir in dem Fall eh immer AEG empfehlen..

Habe bereits festgestellt, dass wenn man die SmartHMI.exe neu ausführt es passieren kann das gewisse Sachen nicht richtig laden/angezeigt/genutzt werden können... (Digitale Ein & Ausgänge Ansicht z.B.)

Aber natürlich...
Besten Dank!

Ich glaube ich habe ein ähnliches Problem..
Ich habe mir folgende Struktur überlegt:

STRUC S_ARTIKELINFOS INT Artikelnr, REAL Teilelaenge, INT Platinennr, INT Kopfstuecknr, BOOL Mit_Griff, REAL Blechdicke

Die Struktur wollte ich jetzt in einem Array haben um im laufenden Prozess das Array nach einzelnen Teilen der Struktur zu durchsuchen und je nachdem etwas auszuführen.
Hier das gekürzte Array:

DECL S_ARTIKELINFOS Artikelliste[3]; eigentlich 32
Artikelliste[1]={13400, 2998.0, 8732, 9085, TRUE, 1.25} ;
Artikelliste[2]={13399, 2498.0, 8852, 9085, TRUE, 1.25} ;
Artikelliste[3]={13398, 1998.0, 8851, 9085, TRUE, 1.25} ;

In OrangeEdit wird mir nichts angezeigt. Möchte ich die Kombination in WorkVisual nutzen kommt die Meldung " Ein Wert vom Typ 'S_Artikelinfos' kann nicht einer Variable vom Typ 'S_Artikelinfos' zugewiesen werden". Verstehe jetzt aber den Fehler nicht so ganz.
Kann mir einer sagen wo das Problem ist bzw. wie ich es beheben kann ?

Ich weiß nicht welche Version von ArcTech Basic ihr verwendet, aber eigentlich sollten die Statustasten beachtet werden bzw. ein "Schlüsselschalter" konfiguriert sein wenn nicht. (Stand Version 3.1)

Wir haben bei uns aber an allen Schweißanlagen einfach den Schlüsselschalter über die SPS konfiguriert (Eingang zum Roboter). Die Einrichter/Bediener können über einen Schieberegler dann einfach das Schweißen ein oder ausschalten falls das mal nötig ist.

Falls das für euch eine Möglichkeit ist.

Ja.

Wenn mehrere Roboter ausgewählt sind, müsste unten/mitte rechts irgendwo "Alle Archivieren" stehen. Dann werden automatisch für alle ausgewählten Roboter die Archive erstellt.

Ich habe befürchte ich das selbe bzw. ein ähnliches Problem.

Das Bauteil das wir bearbeiten wollen hat an Zwei stellen die exakt selben Schweißnähte.

Nachdem ich den Programmteil welchen ich brauche kopiert und eingefügt habe, wollte ich es über "markierter Bereich" um das passende Maß verschieben.

(Der Fehler tritt auch auf wenn ich es nicht verschiebe, sondern nur kopiere und einfüge.)

Den Rest vom Programm kann ab dann komischerweise auch nicht mehr anfahren...

Wenn der Fehler ansteht und ich mir die einzelnen Variablen anzeigen lasse steht

$VEL.CPauf 0.5 und $VEL_MA.CP auf 3.0

Mit den bisherigen Antworten konnte ich ehrlich gesagt auch nicht wirklich was anfangen, kann mir nochmal jemand erklären wie der Fehler jetzt zustande kommt bzw. was ich dagegen tun kann ?