Beiträge von Karsten36

Hallo zusammen,

in einem MultiMove/MultiTasking System kann man ja persistent deklarierte Variablen über Tasks hinweg lesen/schreiben.
Kann mir jemand sagen wie hier das timing bei "gleichzeitigem" Zugriff funktioniert?

Konkretes Beispiel: mehrere Motion Tasks warten vor einer Station auf Einfahrfreigabe, zB:

WaitUntil nStation=0
nStation:=nRoboterNr;

mache Dinge, verlasse die Station

nStation:=0;

Falls das bei beiden Tasks in der exakt gleichen Stelle im Vorlauf stehen würde (sagen wir hypothetisch direkt main Zeile 1), wäre es dann möglich dass beide Tasks gleichzeitig über Zeile 1 laufen?
Sprich muss ich mich darum kümmern dass gleichzeitige Zugriffe nicht möglich sind oder werden die Tasks in der CPU sequentiell abgearbeitet sodass immer ein Zugriff "zuerst" erfolgt?

Nachdem ich es spaßeshalber wirklich mal mit main Zeile 1 ausprobiert habe "gewinnt" immer Task 1.



Edit: Das Ganze ist eher ein Duschgedanke, mich interessiert hauptsächlich wie die unterschiedlichen Tasks von der CPU abgearbeitet werden. Bei den meisten PLC's und Motion Controllern hat man darauf ja Einfluss oder zumindest Informationen und die zyklische Abarbeitung ist für mich auch nachvollziehbarer als Satzabarbeitung mit undefiniertem Vorlauf.

Danke und Grüße

Karsten

Die meinte ich. Der tooltip sagt "ziehen um bytereihenfolge zu swappen" und rastet in Vielfachen von 16. In der Hilfe sieht es ähnlich aus, hier werden noch Datenlänge und -typ angezeigt.

Hallo zusammen,

vermutlich ein sehr banales und sehr häufiges Problem... Siemens PLC und KUKA Roboter über Profinet.

Im Signaleditor ist ein 16 bit Wort gruppiert und in der EA-Verschaltung auf eine 16 bit Wort "Gruppe" gemappt. Leider hat die Byteswap Funktion im Signaleditor keinerlei Auswirkung, sprich mit oder ohne "orangen Balken" links über die 16 bit kommt die selbe byteorder an.
Wenn ich das Wort als 2 Bytes deklariere und manuell 1->2/2->1 mappe funktioniert es. Wenn ich die Hilfe richtig interpretiere sollte "ziehen um Bytefolge zu swappen" aber doch genau das bewirken? Was mache ich falsch?

KRC4 V8.6

Danke und Grüße

Karsten

Hallo zusammen,

folgende Konstellation: Roboter mit 2 "H-Wendern" mit je 2 Zusatzachsen, die beiden Achsen für den Drehwechseltisch sind über $EX_AX_ASYNC permanent asynchron geschalten und werden aus der SPS.sub gesteuert.
Die übrigen 4 Zusatzachsen sind per default asynchron geschalten und es wird immer nur die für die Station benötigte Achse per Systemvariable $Async_Axis='Bxxxxxx' aktiv geschalten.
Der Programmzeiger bleibt allerdings hier stehen solange noch eine asynchrone Bewegung aktiv ist was dazu führt dass der Roboter warten muss wenn er einen Jobstart bekommt während der andere Drehwechseltisch noch dreht.
Geht das irgendwie eleganter?

Gibt es außerdem eine Möglichkeit den Status einzelner asynchroner Achsen abzufragen (Kommandoausführung aktiv/beendet) oder nur den Status des asynchronen "Befehlsstapels" über

$ASYNC_STATE?


Danke und Grüße
Karsten

Vielen Dank für die Hinweise!
Ich werde sehen wie es sich zusammenfrickeln lässt wenn die Hardware da ist. Richtig endlos drehen muss sie nicht so lange ich den Umdrehungszähler nullen kann. Zum Be- / Entladen muss ich auch wieder positionieren können.

Die Safety wird ein Problem wenn ich keine unabhängige Achse behandeln (im Idealfall ganz ausblenden) kann.

KUKA Xpert ist mir prinzipiell bekannt, was ich bisher herausfinden konnte war aber nur dass es zwar einen unabhängigen modus für PTP gibt aber das wohl inkompatibel ist mit Safe Robot?

Evtl. hat ja jemand ein workaround.

Hallo,

ich habe demnächst eine neue Anlage (KRC5, aktuelle Firmware) bei der angeheftete Halter an ein über eine externe Roboterachse geführtes langes rundes Bauteil angeschweißt werden sollen. Aus prozesstechnischen Gründen muss die Achse sich durchgehend mit einer definierten Drehzahl drehen, der Roboter soll sich von Position zu Position bewegen, mittels Linienscanner den Stoß finden, nachpositionieren und dann laserschweißen. Leider wurde hierfür eine externe Roboterachse geplant, eine standalone Achse mit integriertem Umrichter und Busmodul ist aus Gründen keine Option.

Ich bin recht neu in der KUKA Welt, mit ABB wäre es für mich kein Problem:
externe Achse aus der Interpolation nehmen, mittels Techpaket unabhängig auf Drehzahl kommandieren, Roboterbewegung läuft parallel, am Taktende Kommandoausführung stoppen, Umdrehungszähler ablöschen, unabhängigen Modus beenden und die das verbliebende delta zur 0° Position PTP anfahren.

Ich habe über die Suche ein paar ältere Beiträge mit teils recht abenteuerlichen Lösungen gefunden, gibt es dafür mittlerweile evtl. ein Techpaket wie das ABB IndependentMove mit einer Doku zum einlesen?

Grüße
Karsten

Hallo zusammen,

ich mache mir mittlerweile gerne Simulationen in Robotstudio in der Angebotsphase von Projekten und visualisiere dabei Kinematiken wie Transfershuttles oder Rundschalttische mit.

Gibt es bei den selbst erstellten Kinematiken vom Typ "Gerät" eine andere Möglichkeit Positionen zu speichern als in "Kinematik ändern\ Position hinzufügen" über den Slider? Leider "trifft" man damit nicht sauber und es sieht einfach in der Präsentation blöd aus wenn der Rundschalttisch bei 178,5° steht...

Grüße
Karsten

Den selben Adressbereich noch mal als GI deklarieren und über Cross auf einen GO mit dem Adressbereich des Analogausgangs kopieren? Damit sollte die Bit Folge doch unverändert weitergegeben werden.

Zitat von RobiMan

Ist der saubere Weg demnach den NotHalt über die Brücken am Board A21 wie gehabt Hardwaremäßig zu verdrahten? das sollte ja auch funktionieren.

So erscheint ja am Roboter TPU auch die Meldung NOT Halt und nicht die komische Superior Meldung wenn es über Profinet reinkommt.

Meiner leider auch aber ich habe es bisher ohne Probleme so konfiguriert. Wenn das Signal das mit dem Emergency Stop verknüpft ist abfällt geht die IRC5 in Not Halt incl. der Meldung. Ich meine Superior Stop ist de Meldung für das fehlende Safety Enable... dann dürfte auch die Not Halt Meldung nicht kommen.
Da jetzt etwas hart zu verdrahten würde irgendwie das ProfiNet Safe ad absurdum führen?

Der Hinweis ist sogesehen auch richtig, was über den Bus kommt ist elektrisch nicht Bestandteil des internen Not-Aus Kreises der ja erst mal unabhängig ist. Das F-Device meldet dann seinen Zustand an die F-CPU und reagiert auf die übergeordneten Stops.

Die Option Profinet Master/Slave lässt sich leider immer nur einem Netzwerk Port zuweisen. Die IRC5 verwendet dann den selben PN stationsnamen + IP sowohl als Master als auch als Device. Es gibt noch eine ProfiNet Slave Option mit zusätzlichem Anybus Koppler mit der es möglich sein müsste das Roboter PN Subnetz vom restlichen Maschinennetz zu trennen.

Ich handhabe es auch wie meine Vorposter und lasse einfach alles über den WAN Port laufen.

Hallo zusammen,

kann mir jemand sagen ob bei der IRC5 die Feldbusoption Ethernet/IP standardmäßig vorhanden oder eine extra Option/Lizenz benötigt?
In der Steuerung sieht es so aus als könnte ich ein Device anlegen, leider habe ich gerade nichts passendes zum testen da...

Hintergrund ist dass ich eine Schrittmotorsteuerung integrieren müsste, ich aber nichts passendes mit unserem üblichen Feldbus Profinet finde...

Grüße
Karsten

Im Prinzip entspricht mE "drive enable feedback" dem Zustand der Zustimmung.

Laut Auskunft des ABB Support ist der General Output eine Sonderfunktion für einen großen Automobiler die auch gesonderte Hardware benötigt, hat für uns also keine Relevanz. (ich hatte das beim ersten SafeMove 2 Projekt nach dem rumspielen vergessen wieder raus zu nehmen, man bekommt dann eine Warnmeldung wegen des fehlenden Feedback)

Hallo,

nachdem die Frage bei uns auch immer wieder kommt und die Anforderung diesmal recht explizit im Lastenheft steht grabe ich das hier mal wieder aus... evtl. gibt es etwas neues zu der Thematik?

Restriktiv gäbe es mit SafeMove ja die Möglichkeit ohne Token an der HMI zB. das komplette SafetyEnable zu entziehen (setzt voraus dass der user keine Rechte für den SM IB mode hat) aber andersrum einen USAS user "extern" einzuloggen (und nach Entnahme des tokens auch wieder auszuloggen) sehe ich bisher keine Möglichkeit?

Grüße
Karsten

Soll die IRC5 als Controller oder Device dienen?

Wenn die IRC5 als Device an einen Beckhoff Controller soll und die Schnittstelle nicht riesig ist bietet sich evtl. ein Gateway an? Ich habe mit den Anybus X Gateways gute Erfahrungen gemacht um "exotischere" Komponenten mit Profinet zu verheiraten.

Die tool position auf immer aktiv, no stop, innen zulassen und Arm nicht überwachen sollte ein TRUE ergeben wenn sich die Hüllkurve vom tool vollständig in der Zone befindet. TPO und TOR nicht auf einen Busausgang sondern einen internen "Merker" (müsste nachsehen wie ABB sie nennt, kann man im SafeMove unter E/A deklarieren) und die beiden AND verknüpfen. Ginge natürlich auf mit mehreren fdo aber ich bevorzuge ein Sammelsignal sodass man nicht auch noch das F-CPU Programm anfassen muss wenn sich was am Bearbeitungsraum ändert.

Prinzipiell geht das auf Jeden Fall, ich habe es bisher in allen Roboterzellen mit Laser BeaKo so verwendet.
(Mehrere) SafeZone(n) mit jeweils tool position+tool orientation in der PostLogic zu einem Sammelsignal verknüpft welches über F-CPU den Laser Shutter schaltet.

Aber wie Robiman schon angedeutet hat kann man sich mit Sicherheitstechnik halt schnell die Finger verbrennen...

Zitat von EricH

Mal so am Rande, es lässt sich auch viel Taktzeit einsparen, wenn die Zelle entsprechend konstruiert wurde.

Eine Optimierung bei Stopp-Punkten bringt eigentlich pro Stopp-Punkt nur ein paar 100 ms ein.

Zum Thema: Eine Möglichkeit wäre evtl. bei der letztmöglichen Position zum Bremsen ein DO zu schalten und mit der Schaltung dann zu prüfen ob gestoppt wird.

Könnte man, nur hab ich darauf sehr bedingt Einfluss, bzw. ändert es an der generellen Problemstellung nichts. Wegen einem fine Punkt auf Stillstand bremsen und wieder beschleunigen kostet bei vmax und ungünstiger Pose schnell mal 500ms. Bei den Automobilzulieferern sind das Welten.

Das mit dem DO verstehe ich ehrlich gesagt nicht?

Ich möchte Bedingungen präzise "fly by" prüfen können und dann nur bei Bedarf stoppen/warten. Der Code im ersten Post ist im Prinzip das Vorgehen bei TriggCheckIO aus der Doku (dort beschrieben für den Fall dass der Robi ggf. auf ein gate warten muss) "erweitert" auf einen TriggInt um auch mit Variablen arbeiten zu können. Funktioniert ja prinzipiell, ich hatte nur gehofft dass es eine elegantere Lösung gibt.



@Gerhard: Schaue ich mir morgen mal an, danke!

Damit hätte ich doch wieder das Problem dass ich dank undefiniert vorlaufendem Programmzeiger nicht weiss wann er diese Bedinung prüft und das in meinem vorherigen Post beschriebene Verhalten?

Ansonsten mache ich ja genau das in der Trap.

Zitat von Programmiersklave

Hm, WaitUntil u. WaitDi wird im Vorlauf abgearbeitet; wenn die Bedingung stimmt, dann geht er mit Zone drüber. Ist halt nur etwas undefiniert, wo er dann stehenbleibt, wenn die Bedingung NICHT zutrifft, er ist aber innerhalb der Zone. Ausser man verwendet \InPos, dann endet er immer auf dem Punkt, auch wenn man mit Zone programmiert.

Genau das meinte ich. Im Endeffekt möchte ich in einem sehr definierten Bereich "in letzter Sekunde" prüfen ob Bedinungen erfüllt sind und dann entspechend wenn nötig stoppen.

Bei zB.

Move zone Vorposition
WaitUntil ...
Move fine Greifposition

habe ich doch das Problem dass die Bedingung irgendwann während der Bewegung geprüft wird, evtl erst ein paar ms später aber eben noch vor Erreichen des relevanten Bereichs TRUE geworden wäre und der Roboter dadurch auf diesem Punkt unnötig stoppt. Da fast alles bei vmax stattfindet ist "etwas undefiniert" ein Problem.



Offtopic:

Ausgänge triggern ist kein Thema und Kollisionserkennung auch nicht.
Ich mache das mittlerweile zusätzlich zum Programm gerne auch auf Safety Ebene. Dank SafeMove und dessen sehr definierbaren Zonen + ProfiNet Safe zum Motion Controller kann ich zB. die Servos von Shuttles oder Drehwechseltischen in STO bzw. SS2 schalten wenn der Robi im Kollisionsbereich ist und andersrum die Zone für den Robi verbieten wenn der Servo Reglerfreigabe hat. Die neue ABB Kollisionserkennung der Kinematiken gegeneinander funktioniert mittlerweile auch bei MultiMove Independent echt gut. Selbst im Einrichtbetrieb müsste man schon kreativ werden um noch größere Kollisionen zu verursachen... schont die Nerven auf IB.