Name vom letzten angefahrenen Punkt

  • Hallo zusammen,


    ich suche seit einer Zeit eine Lösung für mein Problem, vielleicht hat jemand eine Lösung?


    Zuerst kurzes Info:


    Unser Prozess ähnelt sich der Oberflächenlackirung, wir fahren mit dem Robi (ABB) einen Raster an der Oberfläche eines Bauteils hin und zurück. Nach jeder Bahn fahren wir mit dem Werkzeug raus, um den neue orientieren/positionieren. Jeder Ausfahrt kostet natürlich Zeit. Und als Lösung war natürlich die Verkürzung von diesen Ausfahrtabständen. Am Ende haben wir jetzt so ein Zustand, dass wenn der Robi sich neue orientiert/positioniert (zw. letzten und ersten Bahnpunkten), berührt der Spot den Bauteilrand. Und das ist immer noch OK. Das Problem fängt erst dann an, wenn der Bediener bei einem Prozessfehler den Robi stoppen muss, um den Werkzeug auszutauschen oder reparieren. Dabei versucht man den Prozess mit dem Robi gleichzeitig am Bahnende zu stoppen. Da kommt erstes Problem: nach dem Drücken der STOP-Taste fährt der Robi noch ca. 0,3 - 0,5s weiter (auf den Bauteil zurück, nächste Bahn) und bleibt am Bauteil stehen, was unschöne Spuren hinterlässt. Das ist noch akzeptabel, nur der Kunde stellt natürlich mehreren „WWWW“ Fragen...


    Um den Bauteil weiter zu bearbeiten, wird der Robi an den letzten Punkt der Bahn gefahren (schrittweise oder bei 1%), der Werkzeug wird repariert/ausgetauscht. Und beim Start kommt das großes Problem: der Prozess wird gestartet, und solange bis die Nennwerte erreicht werden (zwei - drei Minuten), bleibt der Robi stehen. Dabei wird der Bauteil mit dem Spotrand die ganze Zeit berührt und fast zum Schrott gemacht...



    Ich habe mir gedacht, dass ich am Ende einer Bahn, den Zustand eines DI (ein Schalter für den Bediener) kontrolliere und wenn der =1 ist, wird eine Interruptroutine aktiviert, die den letzten Bahnpunkt mit z.B. Offset z+100 anfährt und den Robi stoppt.
    So weit so gut.


    Und jetzt die Frage: wie kann man den Name vom letzten angefahrenen Punkt rausfinden, um diesen in Offset zu integrieren? Hat jemand eine Idee?


    Unsere Programme sind groß, ca. 2000 – 3000 Punkten mit ca. 200 – 250 Bahnen. Mal mehr, mal weniger. Und für jede Bahn eine Interruptroutine mit dem bestimmten Punkt zu schreiben, habe ich keine Lust (die Programme werden immer geändert, einigen Punkten werden eingeführt oder gelöscht).

  • ANZEIGE
  • Hi,


    den Namen der zuletzt angefahren Position ist für das Freifahren nicht wichtig, denn Du kannst die momentane Roboterposition in einer Robtarget speichern. Anschließend fährst Du bezogen auf die gespeicherte Position in Werkzeugrichtung zurück und beim Fortsetzen des Programms fährst Du die gespeicherte Position wieder an.


    Weitergehende Informationen findest Du auch am Ende des Referenzhandbuchs im Kapitel "TRAP Routinen mit Bewegungen".



    Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind. (Albert Einstein)

  • Zu Deiner eigentlichen Frage weiß ich keine praktikable Antwort.


    Aber - ist Dein Ansatz nicht zu weit gedacht? Am Ende jeder Bahn ist er ja auf dem Punkt, den er (abzüglich Offset) haben soll. Man müsste an dieser Stelle ja eigentlich nur eine Routine aufrufen, die bei Eingang=1 den Offset anfährt. Wozu soll der Interrupt dienen?


    Ungefähr so:


    Jetzt müsste man "nur noch" diesen Routinenaufruf ans Ende jeder Bahn einfügen. Oder an den Anfang, dann wäre die Anwendung auf den letzten Punkt der vorigen Bahn bezogen, was wohl auf dasselbe herauskäme. Oder eben zwischen die Bahnen. Wie man das allerdings hinbekommt, ohne das Programm selbst zu ändern, wäre noch mal ein Frage für sich.


    Grüße,
    Michael

    Edit: Micky hatte überholt....

  • Hi,


    Danke für eure Vorschläge! Die * CRobT * - Funktion ist mir bekannt, leider laut der Doku:


    „Beachten Sie, dass die Position erst abgelesen und berechnet wird, wenn sich der Roboter im
    Stillstand befindet“


    und das ist keine (absolute) Lösung für mein Problem, weil wenn der Robi bei dem laufenden Prozess auf dem Bauteil (auch am Rand) stehen bleibt, bleiben an der Oberfläche die Spuren... Und dann kommen die Fragen wie bei B. Clinton... :icon_rofl:
    Ich werde trotzdem eure Vorschläge testen, an einem Blechstück :grmpf:, vielleicht werden die Spuren nicht sooo dramatisch sein. :pfeif:


    Ich suche eigentlich nach eine Lösung, bei der der Robi am letzten Bahnpunkt nicht stehen bleibt, sondern flüssig pTemp bzw. zwischenziel anfährt. D.h. pTemp bzw. zwischenziel wird beim laufenden Robi ausgerechnet, direkt wenn Programmzeiger pletzterBahnPunkt abgelesen hat und wenn DI=1 ist (ob das Interrupt oder eine Routine wird, mit RelTool oder OffSet, ist egal). Ich habe wahrscheinlich falsch geschrieben: „Name vom letzten angefahrenen abgelesenen Punkt“ bzw. Koordinaten von dem. Werden diese irgendwo im Steuerungsspeicher an bestimmter Stelle abgelegt, die man gezielt ablesen kann?

  • Hm, dann wäre da ja noch die Möglichkeit, mit einem TriggL / TriggJ oder etwas aus dieser Klasse zu arbeiten. (Dann wäre es doch wieder ein Interrupt.) Ich könnte mir durchaus vorstellen, dass man dann die aktuelle Position auch unterwegs ausgelesen bekommt, zumal man ja sogar die "InPos"-Bedingung mit stoppointdata selbst definieren kann. Rapid macht bei SearchL ja was Vergleichbares.
    Aber das ist jetzt nur geraten, probiert habe ich das komischerweise noch nie auf die Art.


    Was mir gerade noch einfällt: was ist denn, wenn Du den letzten Punkt jeder Bahn IMMER RelTool anfährst, und einfach nur die Z-Komponente (oder was auch immer) je nach Schalterstellung in einer Funktion berechnest? Danach kannst Du ja immer noch weitere Aktionen durchführen, entweder wie vorgeschlagen, oder eben auch in einer synchronen Routine.
    MoveL RelTool(Punkt, 0,0,(-100.0*di_parkanforderung)), .....;
    müsste theoretisch funktionieren.... das ließe sich sogar mit ein paar regular expressions recht simpel in alle bestehenden Programme einfügen lassen, oder über Dein OLP, falls Du eines benutzt...


    Grüße,
    Michael

  • Hallo Michael,


    ich glaube, dein Vorschlag „den letzten Punkt jeder Bahn IMMER mit RelTool anzufahren“ ist die Lösung, die mir helfen kann!!! Sehr kreativ! :grinser043::gutidee: Über so eine Möglichkeit habe ich bis jetzt nicht nachgedacht. Da muss man 2x IF einsetzen, z.B. Z – Wert bei DI=1 zu vergrößern und dann, nach dem Anfahren von den Punkt, auch STOP zu aktivieren.
    Das wichtigste ist, dass diese Instruktionen sich immer auf den letzten Bahnpunkt beziehen, egal ob in OLP einigen Punkte dazwischen eingeführt/gelöscht werden.


    Einziges Problem ist die Kollisionskontrolle, weil der Werkzeug mal so mal so ausgerichtet und in OLP wird dieser Punkt mit „RelTool“ nicht dargestellt und auch nicht simuliert.


    Trotzdem DANKE!!!
    :danke:

  • Hm.....
    Ich habe mich zu früh gefreut... In OLP (FAMOS) muss man in Instruktion RelTool den Name vom bestimmten Punkt eingeben, z.B.:


    MoveL RelTool (p23, 0, 0, 100), v100, fine, twerkzeug1;


    Und wenn ein Punkt gelöscht/eingeführt wird, dann ist der letzte Bahnpunkt nicht mehr p23, sondern p22/p24 ist. Und in Instruktion bleibt der Punktname unverändert, was falsch ist...
    :wallbash:

  • Hättste ja gleich sagen können, dass es Famos ist. :P Da kenne ich wohl ein paar Tricks mehr....
    Hast Du eine 8er Version?
    Dann brauchen wir auch nicht mehr RelTool fahren, sondern können eine einfache Routine einsetzen, der wir den letzten Punkt als Parameter übergeben. Der einzige Nachteil wäre, dass diese Routine dann nach JEDEM punkt aufgeruefen würde. Wir müssten also auch noch den Parameter mit übergeben, um besagter Routine mitzuteilen, dass man nichts machen möchte.


    Du kannst durchaus auch mit Variablen arbeiten in Famos. Eine Möglichkeit wäre:
    1.) Integer-Parameter anlegen (frei verknüpfbar) und mit 0 initialisieren lassen, min 0, max 1.
    2.) Nach dem Bewegungsbefehl einfügen (post)
    3.) Verknüpfter Befehl: zwischenstop "%v","%Target.Name";
    4.) Alle Endpunkte markieren (Menü Bearbeiten | Markieren)
    5.) dort den Parameter auf 1 setzen.


    Die Ausgabe müsste jetzt so aussehen bei jeder Bahn:


    In der noch zu deklarierenden Routine müsste man dann sofort wieder zurückspringen, wenn der erste Parameter 0 ist. Ist er hingegen 1, kann man das im zweiten Parameter übergebene Roboterziel mit beliebigen Offsets anfahren und dann stoppen.
    Wenn Du willst, kannst Du Famos aber auch x, y und z an die Routine einzeln übergeben lassen. (Die Orientierungen leider nicht). Oder auch den Offset, geht auch.
    Experimentiere einfach mit verschiedenen frei verknüpfbaren Parametern und deren Parametervariablen und schau Dir die Ausgabe an.


    Eine verknüpfter Befehl eines Parameters wird von Famos immer rausgeschrieben, wenn sich entweder der Parameter selbst ändert oder eine der im verknüpften Befehl verwendeten Variablen. Ausserdem am Anfang jeder Bahn. Das ist der Grund dafür, warum der Aufruf von "zwischenstop" hier nach jedem Punkt geschieht: der Punktname ändert sich.
    Man kann einen Parameter auch als "pre" einrichten, dann erfolgt der Aufruf des verknüpften Befehls vor dem Anfahren des Punktes. Das könnte man sich auch zunutze machen, denkbar ist z. B. das vorherige Aktivieren einer Verschiebung mit PDispSet. Wobei mir das Angst machen würde, denn das wirkt dann modal und müsste irgendwo explizit auch wieder zurückgesetzt werden.


    Ein weiterer Ansatzpunkt in Famos wäre der TCP-Offset. Dieser Parameter rechnet eine Toolverschiebung drauf, die wird auch mitsimuliert etc. Im Konfiguratinsdialog des Postprozessors müsste man dann abwählen, dass Famos die Routine zum Draufrechnen des Offsets selbst schreibt ("Hilfsfunktion für die Berechnung der Zustaellung erzeugen"), und stattdessen eine angepasste Routine im System hinterlegen. Darin könnte man dann auch auf Eingänge wie die Park-anforderung reagieren.



    Grüße,
    Michael

  • Hallo Michael,


    danke für Deine Vorschläge! Kaum zu glauben, dass nur ein Wort „FAMOS“ macht es möglich, dass Du gleich mehreren Tipps hast!!! :applaus: Wie viel Zeit hast Du damit verbracht?


    Ich habe die beiden auf dem PC ausprobiert, die 2. Variante gefällt mir besser. Ich habe nur eine Bemerkung:
    In der 2. Variante, wenn die Verschibung/Ausfahrt gewünscht wird, wird der letzten Punkt nicht angefahren, sondern nur seine verschobene Position. D.h. z.B. von p30 auf p31+Verschiebung z/y/x. Diese Verschiebung liegt natürlich nicht auf der möglichen Bahnverlängerung, d.h. von p30 auf p31+Verschiebung läuft TCP nicht auf der programmierten Bahn, sondern nimmt die „Abkürzung“... weil die Bahn nicht parallel zu den Achsen läuft. Die beste Variante wäre natürlich p31 anzufahren und dann p31+Verschiebung.
    Hast Du Ideen dafür?
    So weit wie ich weiß, es ist nicht möglich, in FAMOS mit OffSet verknüpften Punkten zu erzeugen... :???:

    Einmal editiert, zuletzt von Bocmok ()


  • So weit wie ich weiß, es ist nicht möglich, in FAMOS mit OffSet verknüpften Punkten zu erzeugen... :???:


    Doch, auch, aber nicht ganz so easy. In den jüngeren Versionen gibt es bei den Parametern "Target Manipulation", da kannst Du auf alle Punkte noch mal irgendwas anwenden. Ein Offs(...) wäre da das geringste Problem. Ist aber, glaube ich, etwas oversized.


    Eigentlich dachte ich schon, dass meine Version funktioniert. Wenn Du den Parameter als "post" bestimmt hast, wird NACH dem Bewegungsbefehl eine Routine, deren einer Parameter das Robtarget des Punktes davor ist, aufgerufen. Das heisst eigentlich, dass der Bewegungsbefehl selbst erst einmal ausgeführt wird. Wo man dann innerhalb der Routine hinfährt, und ob überhaupt und wie und mit welchen Zonen etc., das bleibt Dir dann überlassen.


    Insofern weiß ich gerade nicht, was Du meinst... :huh:
    Oder warst Du bei dem Beispiel mit dem TCP-Offset? In dem Fall hättest Du Recht, da wäre es etwas schwierig....


    Grüße,
    Michael

  • Hallo Michael,


    ja, ich meinte damit 2. Beispiel mit Offs. Leider habe ich keine gute Doku von FAMOS... Über diesen besonderen Parametern wie "Target Manipulation", stehen da nur drei allgemeinen Sätze. Etwas Vernünftiges rauszukriegen, habe ich nicht geschafft.
    Sinn der Sache ist eigentlich mit FAMOS etwa folgenden Code zu bekommen:


    PROC Bahn22()
    !~#GroupName#Programm
    ConfL\ON;
    ConfJ\ON;
    VelSet 85, 5000;
    MoveL p40,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p50,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p60,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p70,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p80,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p90,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p100,v250,z0_1,twerkzeug1\WObj:=WOb1;


    IF di_1=1 THEN
    MoveL Offs(p100, 0, 0, 100) ,v250,z0_1,twerkzeug1\WObj:=WOb1;
    STOP;
    ENDIF


    MoveL p110,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p120,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p130,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p140,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p150,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p160,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p170,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p180,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p190,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p200,v250,z0_1,twerkzeug1\WObj:=WOb1;


    IF di_1=1 THEN
    MoveL Offs(p200, 0, 100, 0) ,v250,z0_1,twerkzeug1\WObj:=WOb1;
    STOP;
    ENDIF


    MoveL p210,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p220,v250,z0_1,twerkzeug1\WObj:=WOb1;
    MoveL p230,v250,z0_1,twerkzeug1\WObj:=WOb1;
    ENDPROC


    Ich schaffe es nicht den Punkt in „MoveL Offs“ mit den vorherigen in OLP zu verknüpfen. Wie ich schon geschrieben habe, in OLP werden die Punkten eingeführt/gelöscht, die Verbindung zw. dem letzten Bahnpunkt und dem Punkt in Offs muss bleiben, deswegen ist diese Verknüpfung so wichtig.
    Die IF und STOP Befehle kann man per Hand extra eintragen.
    Außerdem, wie man sieht, habe ich wg. Bauteils 3D Form, Offs mit unterschiedlichen Werten, mal X, mal Y oder Z.


    Deine 1. Variante mit dem verknüpften Befehl NACH JEDEM Punkt hat mir zuerst nicht gefallen, weil der Code unübersichtlich ist und ev. Programm langsamer wird?


    Jetzt aber, wenn ich im Texteditor mit „Suchen und Ersetzen“ alle Zeilen in Quellcode mit dem Eintrag
    zwischenstop 0
    suche und lösche, und überlege, dass als Parameter nicht nur 0 und 1 einzugeben, sondern auch die anderen Werten, die die Offs – Richtung bestimmen, z.B. 1 --> Z – 100; 2 --> Z + 100 usw. scheint mir diese Lösung wirklich als die beste zu sein. :denk:

  • Hi,
    sorry, dass ich erst jetzt antworte, war auf Baustelle.


    Weitere Möglichkeit (habe ich schon lang nicht mehr benutzt, deshalb sehe ich den Vorteil erst jetzt): nimm einen booleschen Parameter statt eines Integers. Dort kann man scheinbar auch den Punktnamen als Variablen übergeben, ohne dass er in jeder Zeile rausgeschrieben wird, sondern nur, wenn sich tatsächlich der Wert ändert. Für die Änderung auf TRUE setzt Du "post" ein und trägst den Routinenaufruf ein. Für die Änderung auf FALSE lässt Du die Verknüpfung leer. Dann sollte der Aufruf nur an dem Punkt stattfinden.


    Dann gibt es noch ein ganz heftiges Ding, was mir persönlich am zweitbesten gefiele:
    - Boolschen Parameter einfügen.
    - JEDE Bahn so bearbeiten, dass der ERSTE UND der VORLETZTE Punkt ein "Wegfahrpunkt" sind (in Famos, d. h. jede Bahn braucht am Anfang einen und am Ende zwei zusätzlichen Punkte. Sowohl der dann erste als auch der vorletzte Punkt sollten dann da liegen, wo Du hinfahren würdest, wenn der Schalter 1 ist), die Position des allerletzten Punktes wäre jetzt allerdings bedenkenswert, denn der wird immer angefahren
    - den Boolschen Parameter so bearbeiten:
    - Name egal
    - Initialisierung FALSE
    - Ersatztext so lassen
    - Verknüpfter Befehl für den wert "TRUE", VOR dem Bewegungsbefehl einfügen:

    Code
    if dinput(di_1)=1 then "\n"


    -Verknüpfter Befehl für den Wert "FALSE", VOR(!!!) dem Bewegungsbegfehl einfügen:

    Code
    STOP; "\n" ENDIF


    - immer die Verknüpfung verwenden.
    ("\n" macht einen Zeilenvorschub)


    Jetzt auf ALLEN Startpunkten UND vorletzten Punkten den Parameter auf TRUE schalten (grüner Knopf) -
    fertig.
    Damit erzeugt die Ausgabe jeweils vor dem ersten Punkt ein If... und danach ein ...endif. Ebenso vor und nach dem vorletzten.
    Das Gewürge mit den drei zusätzlichen Punkten ergibt sich daraus, dass sonst am Anfang nur ein Endif auftauchen würde (Syntaxfehler) und hinten nur ein If (ebenfalls Syntaxfehler). Wenn es aber komplett so gemacht wird, dann gehört zu jedem If ein Endif.


    Wenn Du bei der Programmerzeugung grundsätzlich ein Script drüberlaufen lassen willst, gibt es im Famos-Postprozessor-Konfigurationsdialog auf dem letzten Tab die Möglichkeit, einen Befehl zu definieren, der immer bei der Generierung des Programms ausgeführt werden soll. Ich benutze da entweder ein UltraEdit-Makro oder -JS, neuerdings auch lieber Python-Scripte, die blödsinnig einfach zu programmieren sind.


    Wenn Du niemals Programme umteacht und re-importierst, kannst Du die Spezialkommentare auch abschalten, dann wird das Programm hübscher.


    Grüße,
    Michael

  • Hallo Michael,


    vielen Dank für Deine Hilfe! Jetzt verstehe ich langsam wie diese besonderen Parametern in FAMOS funktionieren. Wenn ich über allen Deinen Vorschlägen nachdenke, dann komme ich auf so eine Lösung:
    beide Value BOOL und Integer einfügen!


    Bool-Value eingeführt mit post
    False – aktiv
    Verknüpfung mit:
    IF di_1=1 THEN ausfahrt "%Integer-Value.Value", "%Target.Name" "\n" ENDIF;
    Post – aktiv


    FALSE – leer



    Dann auch Integer-Value, dient nur um einen Integerwert weiter zu übergeben (damit wird die Richtung in Ausfahrt bestimmt), mit:


    Min=0; Ini=0; max=10 z.B.
    Verknüpfung mit:
    Leer gelassen


    Nur bei der letzten Bahnpunkten BOOL aktivieren.


    Als Ausgabecode war



    d.h. wenn di=1 ist, wird „ausfahrt“ mit „2“ und p230 ausgeführt:
    „ausfahrt“ soll den bekommenen Punkt (p230) mit einem Offs in eine Richtung (in Abhängigkeit vom Wert z.B. 2) anfahren.


    Zu viel Kommentaren :P oder?


    Danke auch für den Tipp mit Famos-Postprozessor-Konfigurationsdialog, damit muss ich mich noch kennenlernen. Ab und zu teachte ich die einzelnen Programmpunkten nach und reimportiere dann alles natürlich zurück in FAMOS. Für diesen Fall kann ich natürlich alle Kommentaren im Programm lassen. Sonst lieber weg damit.


    Michael, ich habe noch eine Frage. Wenn Du so gut mit FAMOS bist :grinser043:, kennst Du eine Möglichkeit im FAMOS den Winkel zwischen dem, auf die Oberfläche gerichteten, Werkzeug und der Oberfläche zu messen? Bei der Programmerstellung ändere ich die Ausrichtungswinkeln vom Werkzeug, um Kollision zw. Werkzeug und dem Bauteil zu vermeiden. Und dann kommt natürlich die Frage, mit welchem Winkel treffe ich jetzt die Oberfläche?

  • Natüüürlich :zwink:


    Die simpelste Methode besteht darin, einfach "mal schnell" eine Hilfsbahn auf der Fläche zu fangen. Diese kann aus einem Punkt bestehen, sollte deaktiviert sein und kann anschließend wieder gelöscht werden. Einfach "neue Bahn", "Positionen auf Fläche", "Einrasten auf UV-Gitter", und dann dorthin klicken, wo Dein Punkt ungefähr ist. Der ist dann automatisch ausgerichtet, jedenfalls in der Ebene. Weitergehende Ausrichtung erreichst Du mit dem Menüpunkt "ausrichten an Vektor" und dem Beibehalten der Stoßrichtung.
    Dann diesen neuen Bahnpunkt anklicken, und im Positionseditor im Feld links oben den Bahnpunkt als Referenzkoordinatensystem holen. (Siehe Bild). Danach siehst Du jeden Bahnpunkt, den Du sonst anklickst, im Koordinatensystem dieses Punktes.


    Hinterher nicht vergessen, das Koordinatensystem wieder auf "eigenes" umzuschalten.


    Hört sich jetzt kompliziert an, aber ich verwende oft Hilfsbahnen für Ausrichtungszwecke.


    Grüße,
    Michael

  • Eeee? Bist Du von Carat-Robotic?
    Michael, wenn es wirklich so ist, dann habe ich jede Menge Fragen bezüglich FAMOS… :grmpf:
    Aber nicht hier, lieber in "allgemeines zur OLP und Simulation von Robotern" :zwink:

Hilfe und Support für ABB Roboter Programmierung, Konfiguration, Inbetriebnahme finden Sie hier im ABB Roboter Forum. ABB Rapid Programmierung ist einfach, die Roboterforum Community hilft sehr gerne.

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden