Posts by Kevin97

    Bin zwar aus der Kuka-Sparte aber finde die Idee grundsätzlich gut, bin eh ein Freund davon eher einen "vernünftigen" Dauerlauf zu haben als eine bis ans Ende ausgereizte Taktzeit mit dafür häufig verbundenen Fehlern.


    Ein weiterer Vorteil wäre nach außen hin natürlich aus der der Roboter "keine Stillstands Zeiten" mehr hat, was ja alle immer gerne sehen wollen.


    Sehe nur auf Dauer ein Problem von eventuell anderen abhängigen Anlagenteilen...seien es Sensoren die wegen gewissen Bauteilen früher/später kommen oder Mechaniken die verschleißen und mal länger brauchen können.


    Dann fängst du nach einem "langsamen" Prozess an nach unten zu regeln, wobei der nächste aber wieder so schnell ist das die Anlage sogar auf den Roboter wartet :/

    Vielleicht wäre es ja eher eine Idee mal z.B. 100 oder 1000 Durchgänge zu beobachten und dann gewisse Geschwindigkeiten & Beschleunigungen einfach Dauerhaft zu reduzieren wenn immer die nahezu selbe Stillstands Zeit besteht ^^

    Ich weiß nicht ob ich dich richtig verstanden habe, aber prinzipiell könntest du deine Startposition jedes mal neu errechnen lassen und über manuell eingegebene verschieben.

    Am besten legst du dafür Variablen an, die du dann wenn nötig einfach mit einem Wert beschreibst und ansonsten eine 0.0 einträgst wenn sich nicht verändert


    z.B.

    Die Lizenz muss für jeden Roboter einzeln erworben werden.

    Das wird sogar überwacht. Ohne gültige Lizenz kann die Anlage nicht in EXT betrieben werden.

    (Für den Fall kann für ein paar Tage eine "Notfall Lizenz" aktiviert werden, das funktioniert aber auch max. 3 mal glaube ich.

    Ich persönlich finde AppTech völlig überladen... (gibt dennoch einige Sachen die ich gut finde)

    Du hast aber halt immer "alles" dabei und musst/solltest rauslöschen was du nicht benötigst.


    Solltest du/ihr wirklich AppTech einsetzen wollen würde ich die Schulung definitiv empfehlen.

    Du kannst dich halt auch durch die Doku arbeiten, aber die direkte praktische Umsetzung schadet auf keinen Fall.

    Sofern die Anlage/Roboter also nicht schon steht und du direkt dran kannst würde ich definitiv die Schulung empfehlen.

    Martl

    Ja kann ich auch nicht so ganz nachvollziehen...mit vernünftigen Signalnamen arbeitet es sich viel leichter


    falkone63

    Habe die Tage eben eine Bauteil Auswertung mit Timer geschrieben.

    Bin allerdings auch noch nicht zum testen gekommen. Vielleicht hilft es dir ja trotzdem weiter oder inspiriert dich ^^

    Das wird aber so nicht funktionieren oder doch ?

    Müsste nicht "$OUT[50]==FALSE" in der IF Bedingung stehen ?

    Ich würde dir in dem Fall eh immer AEG empfehlen..

    Habe bereits festgestellt, dass wenn man die SmartHMI.exe neu ausführt es passieren kann das gewisse Sachen nicht richtig laden/angezeigt/genutzt werden können... (Digitale Ein & Ausgänge Ansicht z.B.) :S

    Ich glaube ich habe ein ähnliches Problem..
    Ich habe mir folgende Struktur überlegt:

    Code
    STRUC S_ARTIKELINFOS INT Artikelnr, REAL Teilelaenge, INT Platinennr, INT Kopfstuecknr, BOOL Mit_Griff, REAL Blechdicke

    Die Struktur wollte ich jetzt in einem Array haben um im laufenden Prozess das Array nach einzelnen Teilen der Struktur zu durchsuchen und je nachdem etwas auszuführen.
    Hier das gekürzte Array:


    Code
    DECL S_ARTIKELINFOS Artikelliste[3]; eigentlich 32
    Artikelliste[1]={13400, 2998.0, 8732, 9085, TRUE, 1.25} ;
    Artikelliste[2]={13399, 2498.0, 8852, 9085, TRUE, 1.25} ;
    Artikelliste[3]={13398, 1998.0, 8851, 9085, TRUE, 1.25} ;

    In OrangeEdit wird mir nichts angezeigt. Möchte ich die Kombination in WorkVisual nutzen kommt die Meldung " Ein Wert vom Typ 'S_Artikelinfos' kann nicht einer Variable vom Typ 'S_Artikelinfos' zugewiesen werden". Verstehe jetzt aber den Fehler nicht so ganz.
    Kann mir einer sagen wo das Problem ist bzw. wie ich es beheben kann ?

    Ich weiß nicht welche Version von ArcTech Basic ihr verwendet, aber eigentlich sollten die Statustasten beachtet werden bzw. ein "Schlüsselschalter" konfiguriert sein wenn nicht. (Stand Version 3.1)


    Wir haben bei uns aber an allen Schweißanlagen einfach den Schlüsselschalter über die SPS konfiguriert (Eingang zum Roboter). Die Einrichter/Bediener können über einen Schieberegler dann einfach das Schweißen ein oder ausschalten falls das mal nötig ist.

    Falls das für euch eine Möglichkeit ist.

    Ich habe befürchte ich das selbe bzw. ein ähnliches Problem.

    Das Bauteil das wir bearbeiten wollen hat an Zwei stellen die exakt selben Schweißnähte.

    Nachdem ich den Programmteil welchen ich brauche kopiert und eingefügt habe, wollte ich es über "markierter Bereich" um das passende Maß verschieben.

    (Der Fehler tritt auch auf wenn ich es nicht verschiebe, sondern nur kopiere und einfüge.)


    Den Rest vom Programm kann ab dann komischerweise auch nicht mehr anfahren...

    Wenn der Fehler ansteht und ich mir die einzelnen Variablen anzeigen lasse steht

    $VEL.CPauf 0.5 und $VEL_MA.CP auf 3.0


    Mit den bisherigen Antworten konnte ich ehrlich gesagt auch nicht wirklich was anfangen, kann mir nochmal jemand erklären wie der Fehler jetzt zustande kommt bzw. was ich dagegen tun kann ?

    Was ist dann mit anderen Programmen die mit dem Tool fahren?

    Wird dann nicht bei dem haken im ganzen Projekt aktualisiert?

    Ja klar, das wird im ganzen Projekt verändert.

    Aber so hatte ich die Frage auch verstanden. Du kannst ja eh nur jedem Werkzeug einen Namen zuweisen. Entweder wird genau dieses dann verwendet und der Name im Inlineformular ändert sich dadurch, oder es ist eh ein anderes Werkzeug, dann passiert nichts.

    Ob genau das zu Problemen führt kann ich nicht sagen.

    Der Master vermisst den Schweißbrenner vernünftig und beendet die Vermessung auf dem Draht...der Slave endet komischerweise immer wieder auf der Gasdüse/Kappe des Brenners, was das TCP Ergebnis verfälscht.

    Die Funktion des Messens ist aber gegeben.

    Mich wundert es nur da in der Dokumentation von TraccTCP immer nur von "B00000000" geredet wird, sprich 8 Eingängen. Nie aber von "B000000" oder "B0000".


    Würde nur erst gerne dieses "Problem" aus der Welt geschafft haben, bevor ich mich mit dem Problem bei der Vermessung eventuell an Kuka wende.

    Hi,

    vielleicht kann mir jemand von euch weiterhelfen.

    Ich bin gerade dabei eine neue Anlage in Betrieb zu nehmen:

    Team Roboter Zelle

    KR C5

    KSS 8.7.4


    Für die TCP Vermessung/Überprüfung habe ich Lichtschranken angeschlossen die direkt in den Roboterschrank gehen.

    Im Workvisual Projekt habe ich bei beiden Robotern in den Steuerungsoptionen die "Schnelle Messeneingänge" Option aktiviert.

    Der Master hat jetzt komischerweise aber 8 Kanäle bekommen, so wie auch in sämtlichen Dokus erwähnt, der Slave nur 4.


    Leider kann ich absolut keinen Fehler finden.

    Habe in der betreffenden Xml Datei beim Slave einfach mal händisch die 4 fehlenden Channel eingetragen. Dann kriege ich aber die Fehlermeldung: "Antriebstreiber: $Meas_Pulse[X] falsch konfiguriert"

    Vielleicht für andere als Info..

    In den Teil "Position der Messmarkierung" mussten die X, Y & Z Daten des vermessenen Werkzeug des Masters eingegeben werden, damit der Slave weiß wo die Messmarkierung zum Flansch liegt dem er folgen will.

    Wenn man es weiß klingt's irgendwie logisch..

    Es ist aber wichtig wo die Base0 des Masters zur Base0 des Slave liegt, habe ich das richtig verstanden ?

    Nicht wo wie Base0 des Masters zum Vermessenen Referenzwerkzeug des Slave liegt oder ähnliches?


    Sprich wenn die Roboter z.B. 2m auseinander stehen, könnte ich mal versuchen X=2000mm Y=0mm & Z=0mm anzugeben ?

    Also wir haben im Betrieb noch eine Team Anlage stehen in der die Roboter miteinander gekoppelt sind. Das gekoppelte Verfahren funktioniert an dieser auch vernünftig. Allerdings ist der Kollege der diese Anlage in Betrieb genommen hat nicht mehr im Unternehmen.

    Ich habe mir natürlich seine Vermessung angeguckt und geschaut was er für Werte eingetragen hat, aber auch diese sind für mich absolut unerklärlich...