Steuern einer Automation

Roland Keller · 24. April 2006

Hallo zusammen,
ich hab hier eine Aufgabe vorliegen bei der ich nicht so richtig weis wie ich sie angehen soll.
Gegeben sind 1 Roboter KR100 comb, 1 Stanzautomation mit verschiedenen Zwischenstops und Positionen sowie eine Spritzgiessmaschine.
Der Roboter soll dabei die Spritzgiessmaschine mit den Stanzteilen bestücken und parallel dazu den Ablauf der Stanzautomation steuern.
Alle Funktion der Stanze, des Robotergreifers sowie der Ablauf des Spritzzyklus sollen vom Roboter über Profibus parallel realisiert werden.
Ich kann mir nun nicht so richtig vorstellen wie das funktionieren soll.
Gibt es die Möglichkeit ähnlich wie bei den Blauen einen Paralleljob oder etwas ähnliches zu starten?
Oder ist hier Bastelarbeit angesagt?

Für Vorschläge oder Ideen wäre ich dankbar

c.hennig · 24. April 2006

Hallo

Haben die Spritzgiessmaschine und die Stanze eine eigene Steuerung, so dass du nur noch Signale hin und herschieben musst, oder sollen deren kompletten Funktionen auf der Roboterseite abgewickelt werden?

Wenn es die Aufgabenstellung zulässt, würde ich eine SPS dazwischenpacken, weil es damit doch einfacher ist Steuerungsaufgaben und Abläufe zu programmieren (aus meiner Sicht).

Gruß
Carsten

Roland Keller · 24. April 2006

Die SGM hat eine eigene Steuerung. Dort erfolgt nur eine Kommunikation.
Der Greifer selbst (ca. 20 E/A`s) und die Stanze (ca. 35 E / A`s) sollen gleichzeitig vom Kuka gesteuert werden.
Demnach sollten dort zwei src-Programme gleichzeitig ablaufen.
Die Frage ist kann das der Kuka und wenn ja, wie?

stefanM · 25. April 2006

Ja,

du hast einen zweiten Taks auf dem Roboter, mit dem das moeglich ist.
Den findest du in C:/KRC/Roboter/KRC/R1/System/SPS.SUB.
Diesen Task kannst du ganz normal wie ein SRC File editieren.
Weil du nur einen Paralleltask hast, musst du beim Programmieren halt aufpassen, dass dieser zyklisch durchlaeuft (keine Wartezeiten, Warten auf Signale etc.)
Alternativ kannst du auch andere Sub-Dateien im Submit interpreter startet.

Gruss Stefan

Roland Keller · 25. April 2006

Das mit dem Submit wollte ich eigentlich vermeiden, da ich den immer zur Kommunikation verwende.
Wenn ich mir den vorgegebenen schematischen Ablauf betrachte komme ich um kurze Wartezeiten und wait for-Befehle nicht herum.
Mal sehen ob ich das Zyklisch auf die Reihe bekomme (müssen wohl viele Flags oder Merker hin und her geschoben werden) oder ob ich doch noch zusätzlich eine S7 mit einbinde die die Stanze steuert.

Thruest · 25. April 2006

Ich bin leider sehr neu in der Kuka Programmierung aber wäre es nicht einfacher die Stanze in Prinzip wie einen Greiffer handzuhaben und das modul selbst zu schreiben, hab das erst kürzlich so gehandhabt bei einen externen Tuckerstation. im ablauf src file dann nur mehr "greifer (#GR_U_OPEN, 1, 0)" und er ruft über ein unterprogramm die funktion auf mit triggern usw. und überprüft dann auch gleich wie es aussieht ob wirklich zu macht usw. find ich viel übersichtlicher wenn dann eine IH nur mehr Teachen braucht fals änderungen gibt, was haltest davon? und für die gefährlichsten sachen würde ich zusätzlich nen interupt auslösung machen.

Roland Keller · 25. April 2006

Das Problem ist, daß es nicht nur darum geht an einer Stanze einen Stanzzyklus auszulösen.
Das Ding ist sehr komplex, mit Bandhaspel, Taktvorschub, verschiedenen Zwischenstationen und Zentriereinheiten.
Die Taktzeit würde es ja eigentlich zulassen die Arbeitsabläufe (Bestückung der SGM, Stanzen von neuen Einlegteilen) hintereinander auszuführen.
Das will aber der Kunde wiederum nicht.
Mal sehen, ich werd mal versuchen etwas zusammen zu basteln.
Oder vielleicht auf einen Multitask-fähigen Roboter wechseln

IrrerPolterer · 25. April 2006

Wie wär's denn, die Stanze über eine SoftSPS zu steuern. z.B.: Proconos? Im Submit ist das bei 35 E/A s doch verdammt unübersichtlich, da du keine Wait for Befehle usw. programmieren kannst bzw. solltest! Da muß man sich dann mit Timern und Status-Variablen helfen.

z.B.:
1 Zylinder soll bei $IN[1] ausgefahren gefahren werden $OUT[10], und nach 3 Sekunden wieder eingefahren werden $OUT[11]. Zur Kontrolle , ob er ausgefahren ist dient $IN[10] und eingefahren $IN[11].

Code

In $Config.dat: 
INT Stanzzylinder_status=0


Im Submit:


Switch Stanzzylinder_status
 Case 0   
  IF $IN[1] then      
    $OUT[1]=true   
   Stanzzylinder_status=1
  endif
 Case 1    ;warten das zylinder ausgefahren ist
   If $IN[10]  then  ;ausgefahren
    $Timer[1]=-3000    ;Timer auf 3 sec.
    $Timer_stop[1]=false
    Stanzzylinder_status=2
   endif
case 2
   If $Timer_flag[1] then ;Timer ist abgelaufen
    $OUT[10]=false   ;ausfahren ausschalten
    $OUT[11]=true   ;einfahren einschalten
    $Timer_stop[1]=true
    Stanzylinder_status=3
   endif
case 3
   IF $In[11] then ;Zylinder eingefahren
    Stanzzylinder_status=4
   endif
case 4 ;kann auch mit Case 3 zusammengefasst werden
   If not $IN[1] then ;Negative Flanke von Startbefehl abwarten
    Stanzzylinder_status=0
   endif
endswitch

Alles anzeigen

Dies ist nur ein einfaches Beispiel. Wenn du dann auch noch Fehlerabragen und noch mehrere Signale abfragen mußt und Komponenten gegeneinder verriegeln mußt, kannst du dir ja vorstellen, wie unübersichtlich das wird...

Außerdem sind die Zeiten im Submit doch sehr ungenau, da die Zykluszeit doch arg varieren kann, vor allem bei großem Submit.

Roland Keller · 25. April 2006

Genau darum wollte ich es ja vermeiden
Wird eben doch eine S7 zum Einsatz kommen
an Alle

Steuern einer Automation

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Gebrauchtroboter kaufen - Was ist zu beachten. Die Checkliste zum kauf von gebrauchten Robotern

Was macht ein Roboterprogrammierer genau und was verdient er?

Vernetzen, referenzieren, kollaborieren: Das B2B Portal für die Produktionsautomatisierung

Sie wollen Ihr Stellenangebot im Roboterforum schalten? Ab 149€

Werde Roboterprogrammierer bei ROBTEC GmbH in Mainburg / Bayern

Teilen

Tags

Wieviele Mitglieder waren heute eingeloggt?