Beiträge von Willie

Ist zwar schon wieder 15 Tage her seit dem letzten Post, aber was soll's?

Mir hat mal ein Kukaner vor ca. 25 Jahren beigebracht:

PTP fährt der Robi auf dem schnellsten Rechenweg von A nach B. Die Steuerung rechnet sich die am Schnellsten mögliche Achsbeschleunigung für alle Achsen aus und gibt einfach Vollgas. Letztendlich hängt alles von der am langsamsten, möglich zu beschleunigenden Achse ab! Alle anderen Achsen werden so nachgeregelt, bzw. abgebremst, dass sie zeitgleich am programmierten Punkt eintreffen werden.

LIN ist ganz klar: Absolute Priorität hat das Einhalten der Bahn, der Werkzeugspitze zu jedem Zeitpunkt der Bewegung von A nach B. Und es werden auch keine Kompromisse eingegangen!

CIRC: Dasselbe!

Vielleicht ist das noch eine Unterstützung in der Denkweise...

Hello, joke

Hast du die Justage bzw deine Referenzfahrt mit dem richtigen Tool gemacht?
Stichwort: Lastdaten.

Gesendet von meinem SM-G900F mit Tapatalk

Von Leoni gibt es das TCP3D-Vermessungstool mit Korrektur.
Bestehend aus einer Gabellichtschranke mit Infrarotsensoren und einer Control-Unit.
Beides leider relativ teuer: Gabellichtschranke, so ca. 1500€, Control-Unit ca. 2500€.
Damit lässt sich der TCP in 3D oder auch 2D sehr genau korrigieren.

Die frühere Version funktionierte noch über den schnellen Messeingang der KRC2 und hat im 1/10-Bereich sehr gute Messergebnisse geliefert. Musste also nicht mit Control-Unit betrieben werden (Ersparnis: 2500€).
Das Technologiepaket dazu ist zwar aufwändig geschrieben, aber wie gesagt, es funktioniert sehr zuverlässig.

Wäre evtl. ne Lösung für dich. ?

Kaltstart auch schon erzwungen, Problem besteht immer noch.
Der Compiler findet ja auch keine Fehler, die Datei, in der die lokalen Variablen deklariert sind befindet sich fehlerfrei im R1 Verzeichnis. Angewählt funktioniert sie auch. Und wenn ich dann die Variablen einzeln anzeigen lasse, gehts auch. Nur in der Übersicht gehts nicht!?
Es ist definitiv nichts fehlerhaft, keine Syntaxfehler!
Ich kopier die files morgen mal raus und/oder mach n screenshot davon und poste sie hier.
Vielleicht kann man sich dann eher ein Bild davon machen.

Hallo Gemeinde,
ich hab folgendes Problem, was ich bis jetzt nicht lösen konnte:

(KRC2, Ver.5.5)

Ich habe auf 2 verschiedenen Robotern 2 verschiedene selbst geschriebene Technologiepakete. Dazu werden die wichtigsten lokalen Variablen in der Configmon visualisiert, was auch alles problemlos funktioniert.
Nun musste ich beide TP's auf einen! neuen Robi aufspielen. Auch soweit kein Problem.

Um die Configmon auf den neuen Stand zu bringen, habe ich mir beide Configmon's kopiert, die von; sagen wir mal Robi2; umbenannt und in den gleichen Ordner kopiert. Somit hatte ich jetzt configmon von Robi1 und configmoni von Robi2.

Aus der configmoni habe ich mir jetzt den kompletten Eintrag von Group1 über den Windows-Editor von der Steuerung rauskopiert, die kopierte configmon geöffnet und den Inhalt der Zwischenablage dort nach der bestehenden Group1 eingefügt.
Dann die eingefügte neue Group auf Group2 umbenannt (alle weiteren Groups entsprechend fortlaufend weiternummeriert), gespeichert und gut.

Diese modifizierte configmon habe ich nun auf den neuen Robi kopiert.

Problem: Alle Variablen der ursprünglichen configmon werden fein angezeigt und lassen sich bearbeiten, nur die Variablen der eingefügten Group2 werden nicht gefunden

Ich habe auch die richtige Pfadangabe verwendet (R1\Program\BR213\chk_standmenge\...). Testweise habe ich eine der Variablen in der config.dat global deklariert; das funktioniert! Nehme ich die globale Deklaration wieder raus, findet config die Variable wieder nicht mehr.
Fehlermeldung: "Objekt nicht gefunden".

Das Problem bezieht sich auch nur auf die Group, die ich im Windows-Editor aus der einen configmon rauskopiert und in die künftig zu verwendende configmon reinkopiert habe. Die anderen Groups (es gibt noch 2 weitere) funktionieren problemlos.
Alle Einträge von der Group2 passen, keine Syntaxfehler. Ich versteh's nicht.

Kann mir jemand helfen?

Gruß: Daniel

Hi Polterer,
es war eine Funktion, trotzdem wollte es nicht. Zuerst war mein Code tatsächlich falsch (nur ne Kleinigkeit, Syntax), danach hab ich es aber korrigiert und als Funktion wieder getestet. War dann ok, wollte aber in der Submit trotzdem nicht laufen.
Vielleicht teste ich es mal als Programm, oder sogar wie du es machst, als eigene .sub.
Probiere das die nächsten Tage mal.
Danke mal.

Danke Euch zwei.
Ich hab heute wieder meinen Code in die SPS.sub reingehackt und getestet; funzt.
Ich werde das wohl in nen normalen Flag ändern.

Aber, hab ich auch probiert, wie in einem Beitrag beschrieben, einen Unterprogramm/Funktionsaufruf in die SPS.sub einzubinden. In der Funktion stehen nur meine 3 Programmzeilen drin, hat aber nicht funktioniert. Wieso??

Meldung war: "Fehler beim Binden"

PS: Gibts keine elegantere Lösung, als die Einbindung in die SPS.sub

Gruß: Willie

Hi Robi-Gemeinde.

bei meiner langwierigen Suche nach CYCFLAG ist meist nur der User mit entsprechendem Namen aufgetaucht, auch bei "Merker setzen" hatte ich keinen Erfolg.
Daher meine Frage:

Ich möchte einen Zähler zu jeder Zeit (auch bei beendetem, oder abgewähltem Programm) mit ner Variablen über die Config.mon z.B. zurücksetzen können.
Wie kann ich das evtl. realisieren, ohne in den Submit einzugreifen?

Im SPS.sub hatte ich das schon mit Erfolg versucht:

IF MAN_BUE_WE==TRUE THEN
$CYCFLAG[1]=TRUE
ENDIF

Ganz einfach! Aber bringt das nicht Probleme mit der Zykluszeit mit sich, wenn man was in die Submit hinzufügt? (Abgesehen davon, das ich das nach Standard nicht darf).

Problem ist einfach folgendes:

Manche Kollegen setzen die Variable und setzen sie gleich wieder zurück!

Mit diesem Hintergrund wollte ich mir einen Merker setzen, der auch bei wieder rückgesetzter Variable den Merker gesetzt lässt, dadurch den Zähler beim nächsten Durchlauf meiner Funktion rücksetzt und erst dann auch den CYCFLAG zurücksetzt um wieder bei 0 anzufangen.

Welch elegante Methode gibts hierfür (evtl. ohne Submit-Interpreter) ??

Ok, ich hab es so nur noch nie gemacht. Ist für mich auch neu die Korrekturgeschichte und da hab ich mir halt selber was gepfriemelt.
Außerdem wollte ich bezüglich experimientieren mit verschiedenen Wkz alle Variablen beeinflußbar machen.

Aber danke für den Tip, ich hab ihn heute früh schon ins Auge gefasst und werde es mal ausprobieren sobald ich ran kann (Produktion läuft)

Mir ist grad noch was eingefallen

So müsste es gehen, oder

IF Buerstenwechsel==TRUE THEN
Base_Versatz=0
IVAR=10
I[1]=1
ENDIF

While I[1]<(IVAR-9)
IVAR=IVAR-10
Endwhile

While I[1]>(IVAR+9)
IVAR=IVAR+10
Endwhile

;Beginn des Zaehlen und Versetzen
If I[1]>IVAR Then
Base_versatz=Grundversatz*(IVAR/10)
IVAR=IVAR+10
Endif

Zitat von soma

mein Senf:

Warum Baseverschiebung?
Dein Base ändert sich ja garnicht sondern dein tool.
Es wird quasi kürzer.
Mit Baseverschiebung geht es jetzt gerade in deinem speziellen Fall, doch was ist wenn dein chef kommt und sagt:
"Schleif mal noch die gegenüberliegende oder irgendeine andere Seite".

Alles anzeigen

Naja, weil ich mit meinem Tool nicht im rechten Winkel oder parallel an meine Base fahren kann. Ich möchte aber in Bezug zu meiner rechtwinklig vermessenen X-Achse an den Schleifer fahren.

Wenn mein Chef das sagt, dann programmiere ich sowieso neu und wieder mit meiner Offset-Base. Habe ich also wieder den richtigen Bezug zu meiner Base und kann verschieben.

Sicher, ich kann auch nach jeder Bahn verschieben, nur hätte ich dann bei meiner bisherigen Programmierung 1500 If-Bedingungen gehabt
Daher ja auch meine Frage nach ner eleganteren Lösung.

Der Denkanstoß war gut
Hab mir grad Gedanken gemacht. So wäre das Aufaddieren lösbar:

IF Buerstenwechsel==TRUE THEN
Base_Versatz=0
IVAR=10
I[1]=0
ENDIF

;Beginn des Zaehlen und Versetzen
If I[1]>IVAR Then
Base_versatz=Grundversatz*(IVAR/10)
IVAR=IVAR+10
Endif

Nur, wenn I[1] jetzt 101 wäre, wäre bei einem Grundversatz von 0,1 mein Base_Versatz 1
Wenn ich jetzt I[1] auf 50 zurücksetzen möchte, bleibt mein Base_Versatz und meine IVAR 51x gleich.
Optimal wäre, wenn ein zurückücksetzen des Zählers meinen Base_Versatz entsprechend zurücksetzen würde.
Das müsste noch lösbar sein.

Hallo Leute.
Bin neu hier und habe allein durch Lesen bei Euch schon viel gelernt.

Ich habe die Aufgabe, eine Blech-Bauteilkante zu entgraten. Mechanisch habe ich das vorerst mit einem sog. Fächerschleifer realisiert. Da sich dieser relativ schnell abnutzt, habe ich mir eine Baseverschiebung gebastelt, die nach x Schleifvorgängen den Robi näher an meinen Schleifer fahren lässt. Funktioniert soweit auch wunderbar
Die Verschiebung und die Bedingungen dazu habe ich mir in einem Unterprogramm geschrieben, daß jedesmal vor dem Schleifen durchlaufen wird. Hierbei zähle ich auch nach dem Schleifen eine globale Zählvariable hoch, nach der ich nach jedem zehnten Schleifen meine Base um 0.05mm verschiebe.

Jetzt meine Frage: Die Bedingungen zur Baseverschiebung habe ich mit 150 If-Abfragen realisiert, Bsp.

Base_Versatz=0

If I[1]>10 Then
Base_Versatz=Grundversatz*1
Endif

If I[1]>20 Then
Base_Versatz=Grundversatz*2
Endif

usw. und das 150mal. Das funktioniert auch, denn ich kann meiner Zählvariable jederzeit einen anderen Wert zuweisen und der Baseversatz ändert sich entsprechend real. Auch meinen Grundversatz kann ich ändern und so über die Standzeit des Schleifers stärker oder schwächer an diesen ranfahren.

Nur: die 150 If-Abfragen sind mir ein Dorn im Auge! Geht das nicht auch eleganter

Gruß: Willie

PS: Ich hab die If-Abfragen editiert, sie waren nicht ganz richtig.