Beiträge von Roland Keller

Zitat von PA

Thema Kontrolle Programmänderung (teachen):
Ich bin mir nicht sicher, aber ich würde mal im Logbuch (Anzeige ->Logbuch) nachschauen. Da standardmäßig nur 200 ? Einträge vorgesehen sind (kann aber erhöht werden), werden unwichtige Einträge bald wieder gelöscht. Man kann zumindest sehen, ob jemand den Betriebswahlschalter gedreht hat oder jemand ein Programm ab- und angewählt hat.

Gruß

PA

Ob geteacht wurde steht da drinn. Du kannst das Logbuch auch exportieren dann geht nichts verloren.
Das Logbuch liegt dann unter C/ KRC/ Roboter/ log als Logbuch.txt vor.

Hier mal so ein Eintrag. Daraus ist ersichtlich daß dieser Punkt am 17.09.2004 um 9:47 Uhr geteacht wurde.
#1134 ----------------------------------------------------------------------
09:57:44'724 17.09.2004 Nr.:0: Aendern: SN 723: From: PTP P_Battenfeld CONT Vel= 100 % PDAT40 , To: PTP P_Battenfeld CONT Vel= 100 % PDAT40 (KRC:\R1\RDS4_HAUPTPROGRAMM.SRC)
Source: TP_KUKA

Hallo Wolfram,
das gibt es. Zwar nicht als Button in dem Sinn, sonder als anklickbare Zeile.
Links oben neben deinem User pic
Gruß
Roland

Diese Aussage ist dann wohl starker Tobak. Oder vielleicht doch schon unverschämt??
Hier sind User die schon mehr Roboter programmiert haben als du jeh gesehen hast.
Aber nachdem du ja anscheinend jetzt alles kannst, bewirb dich doch hier als Moderator

Was soll das eigentlich werden
Eine Fragestunde?
Wenn du wirkliches Interesse am Roboter-Coden hast ist diese Art die schlechteste um das zu Erlernen.
Mach deinen Lehrgang fertig und probier ein wenig.
Danach kannst du offenstehende Frage stellen...............
Probieren ist eh das wichtigste, dann klappt das so manchesmal auch ohne Lehrgang

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

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

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.

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?

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

Ich hab bei der KRC32 auch noch keinen Submitinterpreter gefunden.

Interessant, wusste gar nicht daß die Erkennung einstellbar ist

Jup, es funktioniert
Thx an alle

Jup, es funktioniert
Thx an alle

Das mit dem NWAIT funktoiniert zum setzen der Ausgänge während des Ablaufs sehr gut.
Allerdings sieht es so aus als würde bei einem folgenden Call Job der Satzzeiger nicht vorrauslaufen
Oder täuscht das nur

Danke,
ich geh dann mal testen

Ja, der kurze Stop kommt durch die Ermittlung des gültigen Palettenplatzes.
Ich dachte an eine Lösung, daß während des Ablaufs in einem Unterprogramm der nächste Platz bereits ausgewertet wurde und in ein Variable geschickt wird so daß dieser Stop verkürzt oder gar umgangen werden kann.
Da die Taktzeit relativ gering abweicht sprechen wir hier nur von einer Zehntelsekunde die ich pro Palette dadurch gewinnen müsste.
Der Roboter ist bereits ausgequetscht wie eine Zitrone

Diese Blauen sind einfach umständlich zu programmieren

Hallo zusammen,

ist es bei den Blauen eigentlich möglich wegbezogene Aktionen (Ausgang setzen, Unterprogramme aufrufen) ähnlich wie bei Kuka (trigger when) durchzuführen?
Hintergrund ist ein kleines Taktzeitproblem.
In dem Falle werden Gussteile aus einer Palette entnommen und nach Bearbeitung in anderen Paletten wieder abgestapelt.
Dabei kommt es bei jedem Anfahren der Paletten zu einem kurzen Stop um den gültigen Palettenplatz auszuwerten.

Muss ich da tatsächlich zig Jump---If verwenden oder geht das auch einfacher?
Bin für jeden Vorschlag dankbar

Na den Unterschied hätte ich aber gerne mal genauers erkärt...............
Ausser den Wörtern sehe ich keinen.
Dinge wie Loop oder Switch sind nichts anderes als ein verbessertes oder besser gesagt, verstecktes Goto.
Solange manche Roboterhersteller keine zyklisch laufeneden Steuerungen entwickeln können oder wollen wird sich daran auch nichts ändern.

Die Antwort ist leider nein
4.1 und 5.2 laufen nicht auf einem Rechner

Stimmt, aber bei so einem "kleinen" Programm geht das schon