Beiträge von Programmiersklave

    Eigentlich ist es ja schon falsch, wenn man das Problem des Sicherheitsingenieurs (wenn es einen designierten gibt) zu seinem eigenen macht. Der kann ja nicht nur dafür verantwortlich sein, dass irgendwas verhindert wird, der muss ja auch ermöglichen, dass die Anlage benutz- und bedienbar ist, schließlich ist er Teil des Teams.

    Man muss das als Inbetriebnehmer auch ab und an aussitzen können: wenn irgendwas nicht machbar ist, dann muss der eben kommen und es korrigieren.

    Und dann auch mal dumm stellen und eben nicht auf dem eigenen Rechner Sick FlexiSoft oder Wieland Samos installieren. An der Stelle fand ich es auch immer irgendwie unschön, dass der SPS-Programmierer auch ganz selbstverständlich den F-Teil zu programmieren hat und der Roboterprogrammierer mehr oder weniger selbstverständlich auch SafeMove etc. konfiguriert, ja, dass diese Konfiguration überhaupt untrennbar in die Programmiersuites der Roboterhersteller integriert ist.


    Was anderes ist es, wenn man alles in einer Person darstellt.

    Verstehe ich nicht, wo ist denn die definierte Stelle? Wenn der immer dort sein muss, wie wird der dann in das Schloss gesteckt um die Freigabe zu schalten? Oder ist die Stelle das Schloss,, dann ist's auch wieder komisch :kopfkratz:

    Die feiern sich richtig drauf.

    Zum Schlüssel gehören verschiedene Schlösser, und in einem muss der halt stecken und dort irgendwas mechanisch oder elektrisch betätigen, steckt er nicht draußen, geht die Anlage nicht, steckt er nicht drinnen, gehen die Handfunktionen nicht. Ich hab's auch einmal gesehen, da musste man den einen Schlüssel ausschalten und abziehen, um damit am Türschloss einen anderen Schlüssel freizugeben, mit dem man dann wiederum usw. usf., das Ganze gibt's auch mit mehreren Schlüsseln, die gleichzeitig irgendwo sein müssen... und die nehmen das wirklich, wirklich ernst.

    Ich bin einmal nur deshalb nach Birmingham geflogen, um mich (f***ing German) in meiner Zelle einschließen zu lassen, weil ich nur so merken konnte, dass die Frässpindel nicht mit Solldrehzahl läuft, und sich von denen keiner traute.


    Man kann mit sowas schon eine hohe Hemmschwelle schaffen, wollte ich damit sagen.

    Schlüsselschalter ja, haben wir Teilweise aber ist ihm nicht genug. Weil: Wie stellt man sicher das dies auf einen bestimmten Personenkreis eingeschränkt ist. Wir wären da schon zu frieden wenn dieser nach übergabe an den Kunden entweder Hardware oder Software mäßig entfernt wird.

    Da lohnt vielleicht auch ein Blick zu den Briten. Die haben einen eigenen Stil, was Türverriegelungen und Schlüsselaufbewahrung angeht. Da muss der Schlüssel sich immer an einer definierten Stelle befinden und kann nicht einfach mitgenommen werden.


    Unser Sicherheits Mensch lässt die Variante mit dem Zustimmtaster nicht zu

    Ist auch böse. Wurde in meiner alten Firma auch oft so geregelt, Zustimmtaster + Schlüssel und dann geht's, heisst aber auch : man muss höllisch auf seine Ausgänge aufpassen, sonst passiert unerwarteterweise was im Moment des Drückens des Zustimmtasters.


    dann gab es da schon mal die Möglichkeit dass man das ganze zu zweit bedienen musste, also eine zweite Person mit einem weiteren Zustimmtaster

    Ja, das sind die Anlagen, wo man mit zwei Panels in den Händen am Robbi steht und mit der Nasenspitze auf dem Touch versucht, den Ausgang umzuschalten. Unmöglich.


    Alle maßnahmen wo dann getroffen werden ist der Bediner/Inbetriebnehmer schuld.

    Bei einem Ding in einer Serie hatten wir mal einen Schlauchsatz, den der Inbetriebnehmer mitnehmen musste. Man konnte/musste dem "Ding" bei offener Anlage Luft von außen zuführen, eine Luftkupplung war hinter einer Wartungsklappe erreichbar.


    Eventuell reichen auch klassische Druckhalteventile am Zylinder aus, oder eine mechanische Arretierung.

    Ich brauche diese Routine nur bei bestimmten Anwendungsfällen und ich will die Resourcen vom Roboter in allen anderen Fällen nicht überstrapazieren.

    Beim KUKA kannst Du damit nichts überstrapazieren, die Ressourcen werden vom System vernünftig verteilt. Man kann elend riesige Programme im Submit-Interpreter unterbringen, das Schlimmste, was passieren kann, ist, dass sie dann pro Durchlauf länger brauchen. Die Zeit ist aber ohnehin nie Null.

    Man braucht schon 'ne ganze Menge Zeugs um die sps.sub dazu zu bringen, mehr als einen IPO-Takt zu brauchen, und selbst wenn - who cares.

    Sinniger scheint es beim ABB, die Rampe der Beschleunigung zu reduzieren, also die zweite Zahl der accdata. Das schont dann die Getriebe und nimmt Vibrationen raus (ist ein Punkt bei Anlagen auf Grundrahmen, besonders bei MultiMove-Systemen oder wenn Bearbeitungsmaschinen drin sind)


    Wobei man das nicht ohne Weiteres automatisieren kann, denn wenn dann einer den Override runtersetzt regelt sich das dann wieder rauf...

    Wenn ich wüsste was du damit meinst ? :/ ^^

    Das FOR ... ENDFOR ist eine Zählschleife. Das hast Du ja hinbekommen, dass in jedem Zählschritt eine Einheit tiefer gegangen wird.

    Die Fräsbahn besteht aus zwei Punkten xAnfang und xEnd. Durch die Schleife fährt er immer hin und her.


    Jetzt SCHEINT es mir so, dass Du sinngemäß das Gleiche nicht in die Tiefe, sondern in Längs- oder Querrichtung machen willst. Also brauchst Du eine zweite Schleife innerhalb der ersten, mit der Rechenoperation in x oder y statt in z.


    (Y berechnest Du in Deinem Testprogramm dort als "Beckenlänge", indem Du es auf "Anfang" draufschlägst. Das ist irgendwie komisch, zumal "End" nirgends berechnet wird. Insofern ist die Fragestellung schlecht nachzuvollziehen. Ist X die Länge oder die Breite, und wo liegt "End"?).


    Edit: in Hermanns Code sind auch zwei Schleifen verschachtelt...

    Man kann in der Not versuchen, das Panel neu kaltzustarten, ohne dass man dem Roboter dabei weh tut. Einfach den weißen Knopf drücken und dann in der angezeigten Frist das Kabel am Controller ausstecken. Dann wieder rein und abwarten, bis man wieder "drin" ist.

    Wenn es eine verwirrte Software auf dem Panel war, bringt man die dadurch wieder zur Besinnung - kommt tatsächlich gelegentlich vor. Wenn nicht - tja....

    Ich rate Dir DRINGEND, dazu zwei Programme zu verwenden.

    Also, das mit dem Deckelfräsen abfahren, dann abwählen, das dazwischen machen, dann das mit dem Becken fräsen anwählen und starten.


    Wenn Du das unbedingt in einem haben willst, benutze bitte die Anweisung

    Code
    HALT

    die hält das Programm an, bis Du wieder nachstartest.


    Was Du keinesfalls machen solltest: bei einem wartenden Programm im Arbeitsbereich rumfuchteln. Normalerweise ist der Roboter auch totgelegt, wenn man dort ist, aber ich fürchte, ich fürchte, ich fürchte....

    Den Dialog in Deinem letzten Bild habe ich noch nie benutzt. Ernsthaft. Den brauchst Du nicht.


    Das entwickelt sich gerade wieder komisch auseinander.


    Nochmal: Du hast ein Programm "fahren" oder wie immer es genannt wird, darin sind Punkte in einem BASE geteacht. Hier: BASE_DATA[1], oder eben, wie da zu lesen ist, Base 1.


    Und Du hast

    ENTWEDER eine Methode, Base 1 einzumessen über KUKAs Systemfunktion "Vermessen|BASE|...".

    ODER das von mir beschriebene Programm "ankratzen", nennen wir es mal so, aus dem Bild auf der vorigen Seite.


    In beiden Fällen steht VOR der Maßnahme (entweder / oder) in "Ansicht|Variable|Einzeln" bei Eingabe von BASE_DATA[1] was anderes als danach.


    Deswegen wird das Programm "fahren" nachher andere Positionen im "Weltraum" haben als vorher.

    Wenn es um das Programm in dem Bild geht: Ist klar, weil Du Punkt 2 anfährst VOR der Zeile mit der Baseänderung. (Zeilen 6 und 7 vertauschen)

    Punkt 1 ist ja im Welt, der wird in Welt umgeteacht. Der hat damit gar nichts zu tun, der speichert nur.

    Punkt 2 ist tatsächlich über BASE_DATA[1] verschiebbar und sollte sich ändern.

    Bits werden immer von rechts gezählt, also _aufsteigend_ ins Device-Mapping.

    Würde auch auf "unsigned" umstellen, da es nicht negativ werden kann.

    Dann braucht die Klemme, glaube ich, das komplette Wort, also 16 Bit. Die ignoriert nur die vier kleinsten wegen Mehrfachverwendung, (kannste eh nicht auflösen), und das Vorzeichen fällt raus, also maxBitValue auf 32767 stellen.


    Übrigens hilft Deine Tabelle ganz nett. Achte mal auf "10" und "19"....

    Ich hab das ja auch mit der Base kapiert... Wenn ich mein Becken programmiert habe, köännte ich auch einfach die Base verschieben... aber dann muss ich jedesmal alle Punkte markieren und dann kartetisch Base verschieben... ? Geht das nicht einfacher ?

    Die Punktdaten (was in Xp... drinsteht) beziehen sich auf das BASE-Koordinatensystem. Wenn die Punkte in BASE_DATA[1] programmiert sind, dann verschieben sich alle gleichzeitig, wenn Du BASE_DATA[1] änderst.

    $BASE ist modal, das heisst: entweder, Du benutzt die klassische Teacherei, dann steht (versteckt) bei jedem Punkt irgendwo $BASE=BASE_DATA[1]. Oder Du hast es Expertenmäßig von Hand programmiert, dann steht das irgendwo einmal obendrüber und gilt solange, bis was anderes kommt.


    Die andere Frage: touchUp, unten in der Menüleiste...

    Wir hatten ja damals schon mal drüber gesprochen... eines der Probleme sind Deine fehlenden Kenntnisse.


    Die allersimpelste Möglichkeit, Dein Problem zu lösen, wäre, dass Du Dein Base - bzw. das Base, was Du als Ausgangswert Deiner weiteren Baseberechnung nimmst, einfach mit dem Tool teachst. Das machst Du in einem völlig unabhängigen Programm, Du legst EINEN Punkt in Welt an ($NULLFRAME), und teachst den mit Deinem Fräser ("ankratzen", soweit ich mich erinnere, hast Du CNC-Kenntnisse). Das bedingt natürlich, dass der Fräser vernünftig eingemessen ist, vermutlich wäre es bei Deiner Situation am besten, dass Z in den Fräser hineinzeigt und X und Y so liegen, wie es nachher zum Becken passt.

    Also: mit diesem Tool in Welt(!) den Punkt "nullpunkt" (Datentyp "FRAME", weil BASE auch ein Frame ist) teachen, dabei peinlich darauf achten, wo er sein soll ("in der Mitte" oder "linke vordere Ecke", je nachdem, wie Dein Programm geteacht ist), und dann nach dem Teachen die folgenden Zeilen abfahren:

    Code
    BASE_DATA[1] = xnullpunkt

    Jetzt kommt es darauf an, wie Du die Winkel festlegen willst. Wenn Du sagst, ich teache das extrem präzise, dann reicht es so. Sagst Du aber, neenee, X und Y-Richtung muss immer dieselbe sein wie in Welt, wie bei CNC, dann musst Du das wieder angleichen:

    Code
    BASE_DATA[1].a=0 ; A dreht sich um Z (Welt), aber Du willst keine Drehung
    BASE_DATA[1].b=0 ; B dreht sich um das nun neue Y, aber...
    BASE_DATA[1].c=0 ; C dreht sich um das nun neue X, aber...

    Wäre sogar möglich, dass Du sagst: X-Richtung muss immer beibehalten werden, aber wenn der Stamm um die Längsachse verdreht liegt, dann will ich schräg fräsen - dann lässt Du in Obigem die letzte Zeile weg und bist fein (sofern der Stamm in X-Richtung liegt).


    DANACH steht in BASE_DATA[1] exakt die Stelle, die Du angekratzt hast, und das ANDERE Programm kann in diesem Koordinatensystem fahren bzw. Du kannst BASE_DATA[1] als Ausgangspunkt Deiner Berechnung verwenden. Du kannst dieses Base auch anwählen und darin teachen (das ist das normale Verfahren).

    Wenn es bisher in World geteacht war, hast Du natürlich jetzt das Problem, dass Du es neu machen musst.

    Und wenn Dein Frästool (TOOL_DATA[...]) nicht eingemessen war, dann geht das im Grunde gar nicht vernünftig.

    Wenn Deine Vorrichtung (also das, wo Du das Rohteil reinlegst) gegenüber WORLD schon verdreht liegt, dann musst Du diese Verdrehung drunterlegen, das ist auch kein Problem, muss aber nicht unbedingt hier schon erklärt werden.


    Und eigentlich ist all das Quark, weil:

    exakt dafür hat man die Bases erfunden und sogar eine Vermessung im System mitgeliefert. Nur teacht Du dafür nicht EINEN Punkt, sondern einen PUNKT, eine RICHTUNG und eine EBENE. Dreimal Teachen, neues BASE, einfacher geht es kaum. Entspräche also bei Deiner (vermuteten) Anordnung:

    1.) einmal "ankratzen", speichern.

    2.) einmal wild irgendeine beliebige Strecke manuell in X fahren, speichern

    3.) von da aus einmal wild irgendeine beliebige Strecke manuell in Y fahren, speichern

    Speichern, übernehmen bestätigen, fertig.