Beiträge von fischertech

... Zu der Dialogbox, kann ich Dir folgende App empfehlen:

SmartInputBox von OrangeApps.

Hallo TheSheep.

Das zu Deinem WoV Problem:

die Security für den WoV ServiceHost auf der Steuerung (unter Rechteverwaltung/Fernzugriff) abschalten,
dann sollte die SecurityException nicht mehr auftreten.

Dann WoV Neustart.

Hallo panic mode.

Ja das ist ein cooler ein-Zeilen-Blinker! .

Will hier mal meine 7-Zeilen-Variante (jedoch ohne TIMER) posten.
Alles auch in Submit.

INTERRUPT DECL 21 WHEN $OUT[33]==false DO IrBlink( )

Pulse($OUT[33],true,0.5) ;Start-Pulse
INTERRUPT ON 21

...

DEF IrBlink()
 PULSE ( $OUT[33], true, 1 ) ;Ein- und Auszeit
 PULSE ( $OUT[34], true, 0.5 ) ;eigentlicher Blinker
END

CU Roland

Hallo DS186 und Afri.

Oben wurde Fanuc erwähnt. Ich habe mir auch schon sagen lassen, dass Fanuc langlebige Robis baut mit fast keinen Bugs. Aber ich kann glaube mit dem "Taschenrechner" nicht leben. Ich finde das Bediengerät antiquiert. Man muss dazu sagen, dass ich das Display des Robis auch für unsere HMI nutze. Da meine Programme alle Positionen für das Pick-and-Place selbst berechnen, hat der Kunde mit der Programmierung nichts am Hut. Und auch kein Wissen dafür. Also einfache Maschinenbediener, stehen an unseren Zellen.

Afri, ja Du hast recht, es war zu pauschal formuliert. Aber ich sage Dir was ich für wichtig halte:

Wenn ich ein neues Auto kaufe und muss gleich in die Werkstatt, weil ab Werk ein Bug drin ist oder er in den ersten 1000 km liegen bleibt, wegen irgendwas. Dann ist das nicht OK. Generell sollte das Auto natürlich ein paar tausend km nicht liegebleiben. Das ist mein Anspruch. Ob ich da ein paar Zeilen mehr oder weniger programmieren muss ist mir nicht so wichtig. Und die Bedienung für den Kunden sollte so einfach wie möglich sein.
Also zusammengefasst: einfach bedienbar und wenig Ausfälle.

Die unerwarteten Ausfälle sind natürlich die schlimmsten und teuersten. Für den Kunden und für uns.

Bei meinem Fabrikat hatte ich im letzten Jahr folgende Firmware-Stände:

8.7.3, 8.7.3 HF1, 8.7.4 HF2 und 8.7.5.

Bei jedem wurden wahrscheinlich Bugs behoben. Aber auch neue generiert.

Die Bugs für die Konfigurations-Software und die Hardware kommen noch dazu.

Aber DS186 Du hast schon Recht. Die Hotline von KUKA ist gut. Was würden wir ohne Martin Hintermayr und das Team machen? Ich bin froh dass es sie gibt!

Was mich mal interessieren würde: Hat jemand Erfahrung mit Yaskawa-Robis mit dem neuen Smart Pendant?

Danke DS186 für Deine ehrliche Meinung.

Ich habe jetzt über 120 KUKA Robis verkauft und in Betrieb genommen. Und auch ein paar ABB.

Und dann hat man ja noch Geräte von Herstellern wie Siemens, Sick, ifm, Leuze, Festo …

Da ist man auch immer einer der ersten als Integrator wenn Bugs da sind.

Wie es halt so ist - steht man gegenüber dem Kunden immer blöd da.

Es kostet Nerven, Zeit und Geld.

Hallo zusammen.

So kann es nicht mehr weitergehen . Soft- Firm- und Hardware-Bugs kommen immer häufiger bei neuen Robis .
Welches ist denn Eurer Meinung nach die perfekte Industrieroboter-Marke?

Langlebig, solide, wenig Bugs bei Neumaschinen.

Freue mich auf Eure Meinungen.

CU Roland

Hallo Nitro-Haiza.

Ich rate Dir die DIN EN ISO 10218-2 (Industrieroboter – Sicherheitsanforderungen – Teil 2: Robotersysteme und Integration) zu lesen (kostet leider was) und eine Risikobeurteilung zu machen.

Und natürlich die EG Maschinenrichtlinie zu lesen (gibt's kostenlos zum Download) ...

Viel Erfolg

Gruß Roland

Ja ich weiß, das ist nicht einfach.

Aber unsere Palettierroboter stehen immer im Wettbewerb zu Stapelportalen. Da drückst Du morgens nach dem Einschalten die Starttaste. Das fährt dann (egal wo es steht) langsam nach oben in eine sichere Position, dann in die HOME und dann geht es los.

Ohne einen Betriebsartenwechsel und ohne irgendwelche Meldungen.

Ich sage immer das des Ingenieurs Aufgabe ist: komplizierte Dinge einfach zu machen.

Ich habe die "idiotensichere" Maschine auch noch nicht. Nähere mich aber mit kleinen Schritten

Ja ist mir schon klar was SAK ist.

Und glaube mir, bei uns ist manchmal das automatische Freifahrprogramm zu Begin umfangreicher wie das eigentliche Handlingsprogramm.
Verstehe meine Anmerkung als Wunsch an KUKA.

Mir ist schon klar, dass eine Systemlogik prüfen müsste was die erste Position ist.

Vor Jahren hätte man auch gesagt es ist nicht möglich das auskommentierte Zeilen in der KSS ausgegraut dargestellt werden.

Grüße von IBN

Hallo Ihr.

Ja SJX Du hats recht. Er kann in EXT auf die anfängliche HOME fahren ohne T1.
Aber ich finde auch dass es den Bediener irritiert, wenn beim Neuaufruf eines Programms die Meldung steht "SAK Fahrt in T1/T2 ausführen", obwohl die erste Pos. die XHOME sein soll und $IN_HOME true ist.

Ich wünschte mir auch dass diese Meldung nur angezeigt wird, wenn der Roboter wirklich nicht in HOME steht in Verbindung mit erste anzufahrende Position XHOME.

Wenn ich hier korrekte Bediener habe, dann gehen die morgens in T1 für die erste Position. Und wenn es irgendwie geht, will ich sie eigentlich von T1 fern halten.

Gruß Roland

Hallo Michael.

Für eine Vision-Anwendung müsste glaube ich auch KONI (also KUKA.OptionalNetworkInterface) gehen?

Also Schnittstelle XF7 an der KRC5.

Ist aufpreispflichtig bestellbar/nachrüstbar.

Gruß Roland

Hallo Ihr.

Ich wollte KONI als Windows-Zugang nutzen auf der KRC4 (KSS8.6.8 mit KONI3.0).
Zur Vorgeschichte: Bisher verwendete ich die KLI als Windows-Schnittstelle, was nicht immer perfekt ist, da all meine PN-Teilnehmer im Kundennetz sichtbar sein können.
Nun wollte ich KONI verwenden für Windows.

KLI hat feste Adresse für PN-Teilnehmer und KONI dynamische Adresse für Kundennetzwerk. Irgendwie komme ich aber nicht in's Internet mit KONI von der KRC aus.
Übrigens: mit meinem Laptop komme ich via Kundennetz ins Internet.

Hat jemand einen Tipp?

Wäre Dankbar.

Gruß Roland

Danke SJX!

Hallo Zusammen.

Hat eigentlich jemand mal die Zykluszeit der Submit nachgemessen?

Ich weiß das die unterschiedlich ist und je nach Programm-Umfang, Auslastung des Roboter-Interpreters, ... anders sein kann.

Aber wo (von ... bis) bewegt man sich da?

Gruß aus Freiburg

Hallo WernerRob.

Sichere Rückzugsstrategien sind begehrte Themen. Sieht man auch hier im Forum. Wäre mal eine Idee für KUKA hier was brauchbares im Grundsystem zu programmieren.

Bei uns, werden alle Palettierer mit einer funktionierenden Rückzugsstrategie ausgeliefert.
Es ist dann generell bei "Check HOME" angesiedelt. So dass bei einem Programm-Reset oder z.B. bei einem Stromausfall, nach einem Kaltstart wieder automatisch ein sicherer Weg zu HOME gefunden wird.
Ich sage zu unseren Kunden immer spaßhaft: das Handlings-Programm braucht 10% der Programmzeilen. Der Rückzug 90%.

Nun, bei unseren Palettierern ist es meist einfach. Ist $IN_HOME==false speichere ich die aktuelle Achs-Position in einer Variablen. Ich fahre dann ein wenig in Z nach oben (z.B. LIN_REL {Z -100} #TOOL), dann überschreibe ich die A2-Pos. mit einem absoluten Wert und fahre die Position an. Das mache ich ein paar Mal noch mit anderen Achsen. Wenn alles außer Bereich ist gehe ich in HOME.

Bei unseren 6-Achsern, bin ich auch immer noch am herausfinden der besten Strategie. Mit Merkern setzten (wie schon oft beschrieben) bin ich nicht wirklich glücklich geworden. Dann habe ich versucht anhand der Act.-Pos. von A1 herauszufinden wo ich bin (vor allem ob ich noch in einem speziellen BASE bin). Funktioniert aber auch nicht immer so genau (vor allem wenn's eng wird).

Meist habe ich für unterschiedliche Base's spezielle Stoßrichtungen des Tools. Also wäre es für mich schon eine Hilfe, wenn ich wüsste ob ich noch in einem BASE-Bereich bin und wenn ja in welchem. Dann könnte ich oft gegen die Stoßrichtung wieder weg fahren.

Weg fahren am besten auch mit einem Absolutwert und nicht mit einem Relativwert (da man mit zwar vom Werkstück/Maschine wegkommt, aber nach hinten wieder anstößt oder an die Grenzen kommt)

Aktuell mache ich das so:

Ich bilde mir pro Base einen Kartesischen Arbeitsraum (mit KUKA Arbeitsraumüberwachung) und weiße diesem einen Ausgang (auch für die SPS) zu. Den Arbeitsraum bemesse ich nur im Bereich wo ich definiert rückziehen müsste.

Wenn ich dann am Programm-Anfang nicht $IN_HOME bin, setzte ich ein TOOL aktiv.

Dann prüfe ich die Ausgänge der Arbeitsraumüberwachungen. Ist einer TRUE, setzte ich das entsprechende Base aktiv und fahre mit einigen absoluten, kartesischen Positionen frei. Bin ich dann im ungefährlichen Bereich, geht's weiter gen HOMAE wie mit den Palettierern.

Bei mir tut's so meistens ziemlich gut, ohne dass der Bediener eingreifen muss.

Aber ich weiß, es gibt auch kompliziertere Anlagen, wo selbst das nicht hilt.

Gruß Roland

Hallo Aleks-83.

Du fragst ja hier die Grundlagen ab. Da empfehle ich die alten Dokus, da diese noch ausführlicher sind (Siehe Anlage).
Kannst ja am Wochenende mal durchlesen.

Gruß Roland

Hallo zentrumdermachtt.

Ich habe auch schon festgestellt, dass wenn Du die XHOME numerisch in der config.dat änderst das Signal $IN_HOME nicht kommt.
(zumindest bei bestimmten Softwareständen).
Wenn Du die neue HOME jedoch teachen tust, kommt das Signal wieder korrekt.
CU Roland

Ist kein Hexenwerk:
Erst Interrupt deklarieren. 16 für steigende Flanke, 17 für fallende Flanke.

INTERRUPT DECL 16 WHEN $IN[1]==TRUE DO UP1( )
INTERRUPT DECL 17 WHEN $IN[1]==FALSE DO UP2( )

Dann Interrupt's scharf schalten

INTERRUPT ON 16  
INTERRUPT ON 17

Am Ende der sps.sub dann noch die Unterprogramme einfügen die Abgearbeitet werden sollen bei den Flanken.
DEF UP1()

DEF UP1()
;hier Code einfügen
END
DEF UP2()
;hier Code einfügen
END

Kannst ja einfach das bestehende sps.sub öffnen. Dort ist ja schon einer angelegt. Einfach noch Deine Sachen an den entsprechenden Stellen dazuschreiben.
Reagiert astrein auf Flanken ohne erst Merker mit den alten Werten anzulegen.
Gruß Roland

Zur Flankenerkennung nutze ich liebend gerne einen Interrupt. Auch in der Submit.
Im Aufrufprogramm zum Interrupt, würde ich dann noch den Timer abfragen.
Gruß Roland