Beiträge von DiDi

Hallo,

im Pro_IP sieht man, das der Interpolator den Punkt zwpu_ablage aus dem Befehl LIN zwpu_ablage c_dis in Satznummer 29 abarbeitet. Den Punkt hat er erreicht aber den Befehl noch nicht abgeschlossen. Der Vorlauf steckt inzwischen in einem Modul Einleger1.src Satznummer 51.

Offenbar hat er noch keinen Punkt gefunden zu dem er überschleifen kann.

Die Abfrage $Ext_Start==FALSE macht wenig Sinn. Das ist ein Puls der im Betrieb immer FALSE ist. Hier hat er wohl die Routine verlassen. RETURN führt zum Verlassen des Programms, EXIT zum Verlassen der Schleife.

Allgemein sind die Continues vor Bewegungsanweisungen überflüssig, ebenso bei Geschwindigkeitsvorgaben. Sie müssen auch nicht prinzipiell vor Loop und IF stehen, sondern nur dann, wenn EA's oder Systemvariablen abgefragt werden. Dann aber vor jeder einzelnen Zeile.

Gruss DiDi

Hallo,

Ursache kann sein, das der VW_USR_R im Submitinterpreter mitläuft. Der Baustein ist dann #P_Active und man kann nichts einfügen. Der XEdit weiss aber nichts davon und zeigt den Code als eingefügt an. Im Echtzeitsystem ist er aber micht drin.
Man kann das daran erkennen, das der VW_USR_R im Navigator als aktiv markiert ist.
Zum Test kannst du den Submit Interpreter abwählen und deine Änderungen dann machen.
Ursache so eines Verhaltens kann sein, wenn eine globale Variable aus dem VW_USR_R im VW_Usr_S benutzt wird oder eine Routine aus dem VW_USR_R vom VW_USR_S aus aufgerufen wird oder ein Baustein, der im VW_USR_R gebunden ist, wie z.B. Makros im VW_USR_S aufgerufen wird.

Gruss DiDi

Hallo,

der Roboter schaltet die Antriebe normalerweise bei Fehlermeldungen weg. Kommen da welche? Bei Fehlermeldung uns asynchron schalten fallen mir fehlende SBM ein. Damit gibt es dann nur eine Bremsleitung und die Achse die angekoppelt bleibt geht in Schleppfehler. Ähnlich bei falschen MaDa.

Wer schaltet denn die Antriebe wieder ein. Das macht der Roboter sicher nicht selber. Ist das die SpS?

Gruss DiDi

Hallo,

90 Grad Offset in Achse1 könntest du in $Mames[1] eintragen. In Justagestellung wird $Axis_act[1] dann auf 90Grad statt 0Grad gesetzt. Alternativ mit VK_Edit alle Programme auswählen, alles markieren und dann um 90 Grad in A1 verschieben.

Gruss DiDi

Hallo,

kann mich dunkel an diese Fehler erinnern. Die Software ist sicher schon sehr alt. (A4Wob!)
Hatte aber eher den PTP-Überschleif in Erinnerung.
Von den Daten her sind die Lastdaten extrem. Da gibt es eine 100kg Last ohne Trägheit. So was war im Einstein Universum bisher nicht bekannt.
LOAD_DATA[1]={M 100.0,CM {X 0.0,Y 0.0,Z 400.0,A 0.0,B 0.0,C 0.0},J {X 0.0,Y 0.0,Z 0.0}}
Würde da vorsichtshalber mal was reinschreiben evtl. ist die Bahnplanung auf so was nicht vorbereitet.
LOAD_DATA[1]={M 100.0,CM {X 0.0,Y 0.0,Z 400.0,A 0.0,B 0.0,C 0.0},J {X 5.0,Y 5.0,Z 5.0}}

Falls es daran nicht liegt, kann die Bahnplanung die entsprechende Bewegung nicht berechnen. Da hilft dann nur an den Parametern acc, vel spielen und wenn das nicht geht, auch noch die Positionen ändern bis es geht.
Würde aber auf ersteres tippen.

Gruss DiDi

Gruss DiDi

/R1/$machine.dat
FRAME $ROBROOT={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0} ;ROBOTER IM WELTKOORDINATENSYSTEM [MM,GRAD]

Gruss DiDi

Hallo,

die Steuerung plant auch bei Überschleifen zunächst mit Einzelsätzen, d.h. wie mit Genauhalt.
Danach wird der Punkt bestimmt, an dem der Einzelsatz PTP verlassen wird und die Steuerung sich auf die Überschleifkontur begibt. Der Punkt richtet sich zum einen nach dem Maschinendatum $APO_DIS_PTP. Das ist eine Gradzahl pro Achse. Auf diese Gradzahl wirkt noch der Prozentwert $apo.cptp. Wenn bei der ptp-Bewegung, z.B. die achse1 die längste Bewegung hat, im Maschindatum 20Grad stehen und in $apo.cptp 50% steht, so geht der Roboter 10 Grad in A1 vor Erreichen des überschliffenen ptp Punkts auf die Überschleifkontur und zwar mit der Geschwindigkeit die er beim Einzelsatz hätte. Allerdings kann man max. 50% der Bewegung überschleifen, d.h. wenn die führende A1 im Beipiel im überschliffenen PTP nur 10Grad fährt beginnt die Überschleifkontur 5 Grad in A1 vor Erreichen des überschliffenen PTP.
Danach wird der Punkt bestimmt, an dem der Roboter wieder auf den programmierten LIN Einzelsatz trifft. Bei c_dis wird dieser Punkt in mm vom Start des LIN in $apo.c_dis bestimmt. Bei c_vel ist es ein Prozentwert der Geschwindigkeit beim Beschleunigen, C_ori ist eine Gradzahl. Es ist wieder maximal 50% des Lin möglich.
Zusatzachsen können das Ganze nocht mal stören, da diese auch apo_dis_ptp Werte haben, die eingehalten werden müssen.
Die Überschleifkontur wird am schnellsten, wenn Roboter am Anfang und Ende der Überschleifkontur möglichst schnell ist, d.h. die Parameter so gesetzt werden, das man jeweils an die 50% Grenze kommen (beim LIN reicht auch Konstantfahrphase, falls vorhanden). Ausserdem ist es gut wenn man mit möglichtst langen Bewegungen ptp/lin arbeitet, weil der Roboter da bei 50% Bewegung flotter ist. Da ist länger manchmal schneller. Leider muss man auch noch um die vorhandenen Ecken kommen, und findet bei besonders knappen Sachen raus, das es nur bis 90% gut geht oder der Vorgänger so programmiert hat, das man nur noch mit Überschleif fahren kann und die Einzelsätze auf Crash liegen.

Gruss DiDi

Hallo,

in diesem Fall spricht überhaupt nicht dagegen mit $robroot zu drehen. $robroot wird gedreht, wenn die Maschine gedreht aufgestellt wird, z.B. wenn der Roboter an der Decke hängt oder auf einer Schräge steht. Damit kann die Schwerkraft richtig in das Modell eingerechnet werden. Von daher kann es falsch sein, irgendwie an $robroot zu drehen. Mit A um Z drehen wenn der Roboter ungünstig steht ist in aber sicher nicht verkehrt.

Gruss DiDi

Hallo,

die cwrite Funktionen mit stop, reset, cancel, run sind bei der VKRC identisch zur KRC (gleiches Grundsystem) und können im VW_USR_S programmiert werden.

Würde das aber vorab mit dem Kunden klären, die gibt es sehr konservative Leute.

Gruss DiDi

Hallo,

wenn das zyklisch passieren soll, würde ich mit einem Interrupt z.B. im 100ms Takt anfangen. Im Up kannst du den OV jeweils neu berechnen.
Z.B.
$Timer[1]=-100
Interrup When $Timer[1]>0 Do Up1()

DEF UP1()
$Timer[1]=-100
$OV_PRO=$ANIN[1]*Faktor
END

Etwas schneller wie 100ms Takt geht noch, für viel schneller, genauer oder sogar Regelung muss man dann aber doch grössere Geschütze auffahren.

Gruss DiDi

Hallo,

die Frage nach dem Kaltstart kann man nicht allgemein beantworten. Es gibt Daten, die sofort nach dem Wiederherstellen aktiv werden: z.B. alle Anwenderprogramme, Maschinendaten, INI von Feldbustreibern und es gibt Dateien die erst nach einem Kaltstart aktiv werden: z.B. hw_inf.ini, progress.ini, etc.
Wenn man sicher ist, das sich nur Anwenderdaten geämdert haben, kann man sich den Kaltstart sparen. Wenn man nicht so genau weiss, kann ein Kaltstart nicht schaden. Mir fällt aber nichts ein was ohne Kaltstart einen 30mm Versatz verursachen kann.

Gruss DiDi

Hallo,

Problem war, das die Roboterausgänge unsynchronisiert in die IO Page geschrieben wurden. Es konnte so sporadisch passieren, das die ersten Bits eines Signal ausgegeben wurden, und der Rest erst 12ms später. $Data_Integrity beseitigt das Problem. Allerdings dürfen Signals dann nicht mehr über Bytegrenzen definiert werden. Ab den neuen Versionen funktioniert das zuverlässig, vorher gab es unter Umständen noch Fehler. Das weiter oben erwähnte Validbit war die Lösung, bevor es die Data_Integrity gab. Würde aber sicher auch noch funktionieren.

Gruss DiDi

Hallo,

der Stopmessinterrupt ist ein Sonderfall. Er ist der einzige Programmteil auf dem R_INT, der auch nach einer stoppauslösenden Meldung (z,B. Antriebe aus, Not Aus) weiter läuft. Ausnahme ist die Stoptaste in #EX mit passiver Stop. Der Interrupt reagiert zwar, die Ausführung wird aber gestoppt. Das ist aber ganz sinnvoll, da es sonst gar keine Möglichkeit gäbe den Interpreter anzuhalten.

Für Bahnapplikationen würde ich eher einen Submit Interrupt nehmen z.B. mit $Vel_act==0. Der reagiert bei allen denkbaren Situationen und ist mit Reaktion <=24ms auch schnell genug.

Gruss DiDi

Hallo,

evtl. hast du den Programmnummerntyp auf 1ausN. Beit 8bit und 1ausN können nur die Folgen1-8 angewählt werden.

Gruss DiDi

Hallo,

Lastwechsel im Überschleif ging soweit ich weiss noch nie. Es gibt wahrscheinlich auch kaum praktische Anwendungen. Da müsste ja im Überschleif etwas abgeworfen oder aufgefangen werden. Das wird wohl selten der Fall sein.

Gruss DiDi

Hallo,

wenn du in der VKRC das Base benutzen willst, musst du in $config.dat ADV_Tool[n]=#Tool_Base setzen. n ist die Nummer des Wzg im Bewegungsbefehl. Die Korrektur sollte dann auch in Base_Data[n].

Gruss DiDi

Hallo,

wie wäre folgendes:

INTERRUPT DECL 1 WHEN $Distance>NextStep DO PulseNextStep ( )
NextStep=$Distance+10
Interrupt ON 1

DEF PulseNextStep()
NextStep=$Distance+10
Pulse($OUT[1],TRUE,0.1)
END

Gruss DiDi

Hallo,

der Funktionsgenerator kann deine Aufgabe losen. Du solltest dir die Doku besorgen. Wenn ich richtig erinnere war da ein Anwendungsbeispiel mit einem analogen Abstandssensor drin, entspricht genau deiner Aufgabenstellung.
Alternativ kann man das neuerdings mit dem XML RSI Paket angehen, finde ich aber komplizierter.

Gruss DiDi

Hallo,

mit der GLOBAL Deklaration kann man auch Variablen zwischen den Interpretern austauschen. Wenn eine Variable in einem Modul global deklariert ist, das auf dem R_INT läuft, so kann man sie durchaus von einem Modul aus lesen, das auf dem S_INT läuft.
Nachteil ist dabei allerdings, das das Modul auf dem R_INT den Status vom S_INT bekommt. Das heisst solange der S_INT läuft ist es aktiv und kann nicht überschrieben werden. Wenn das stört sind Systemvariablem wie $Flag[] möglich, ansonsten ist die $config.dat wohl die einzige Alternative.

Gruss DiDi

Hallo,

habe schon mal mit mit einem Heidenhaim Messtaster vermessen. Zusammen mit der Option schnelles Messen, ist das wohl das genaueste was man machen kann. Mit günstig ist da aber nichts. Zum einen sind die Taster schon teuer und die leicht brechenden Messtifte kosten auch noch einiges. Die Messgenauigkeit ist aber für die meisten Anwendungen überzogen. Mit einem normalen Endschalter oder Lichtaster reicht das meist.
Wenn du die Vermessung selber programmieren willst ist schon einiges knowhow erforderlich. Bei 3D vermisst du im Prinzip die Palette auf der du teachtst und merkst dir die Werte. Bei den folgenden Bauteilen misst du die Unterschiede und packst sie auf deine Base drauf. Bei 4D-6D kommt noch etwas Dreiecksberechunung dazu.
Wenn du das nicht selber machen willst gibt es ein fertiges Paket bei KUKA.
http://www.kuka.com/germany/de…are/application/start.htm

Gruss DiDi