Beiträge von Programmiersklave

Zitat von [wEm

link=topic=10517.msg50130#msg50130 date=1338966820]
Mit der ProConOs hättest du noch eine weitere Task , in welcher du allen möglichen Schindluder betreiben kannst

Hab' ich ja sogar in der aktuellen Anlage
Nur muss ich das dem SPS-Programmierer überlassen. Der will ja auch noch was zu tun haben. Hilft mir also nix bei meiner krassen Greiferverwaltung mit einem guten Dutzend Zuständen und so...

Grüße,
Michael

Zitat von Hermann

Man kann doch in dem einen alles reinbauen was man braucht. Das dürfte dann in den meisten Fällen auch übersichtlicher bleiben.

Multitasking ist 'ne feine Sache, wenn man eine Anlage steuern will, und wenn man es gewohnt ist
Die schnelle, zyklische SPS-Task ist ja nur eine Sache. Die Programmierung zeitabhängiger Aktionen ist darinnen eine mühselige Sache, so habe ich dann gerne noch eine langsame Taktgeber-Task, und eigene Tasks für die Positionierung externer Antriebe, wo man auch mal WAIT-Befehle verwenden kann oder gar Interruptgesteuert arbeitet. Und ganz am Rand liegt dann noch 'ne Task, die den Dialog mit dem Bediener macht, dann können die anderen Tasks die Klappe halten und arbeiten. Bin ja schon dankbar, dass man in der KRC4 ein Dialogfenster absetzen kann und dann NICHT auf die Antwort warten muss, sondern jene später irgendwann auslesen kann.

Zugegebenermaßen ist die SPS.SUB erst in den letzten paar Jahren überhaupt für anspruchsvollere Aufgaben brauchbar geworden... man lotet ja immer Grenzen aus....

Grüße,
Michael

Hallo,

(KRC 4)
von der SPS.SUB aus kann man ja in beliebige *.SRC springen, macht KUKA ja schon bei den Technologiepaketen. Andererseits ist es auch möglich, als global deklarierte Routinen in einer *.SUB unterzubringen, und diese aus einer beliebigen SRC heraus aufzurufen.
Jetzt habe ich mal getestet, eine solche Routine im Submitinterpreter zyklisch aufzurufen und "gleichzeitig" aus dem Roboterprogramm reinzuspringen -> geht problemlos, schrittweise oder kontinuierlich, egal. Der zyklische Aufruf durch den anderen Task bleibt davon unberührt. Auch interne Variablen kommen offensichtlich nicht durcheinander.

Ich gehe also davon aus, dass die beiden Tasks verschiedene Instanzen derselben Routine benutzen. Anders als vom ABB gewohnt, der zwischen den Tasks recht strikt trennt, kann man hier also Code taskübergreifend verwenden.

Jetzt frage ich mich allerdings: wieso geht dann - zusätzlich zum Bewegungstask - nur ein einziger Hintergrundtask? Oder gibt es Tricks, ein paar mehr auszuführen? Ich finde das irgendwie halbgar, jetzt mal abgesehen von Leistungslimits. Oder habe ich was übersehen?

Grüße,
Michael

Was aber ausdrücklich CHAR-Strings nicht betrifft.

def test()
melde("Kompatibilitaet programmieren... funktioniert auch")
end






GLOBAL DEF melde(meldetxt[]:in, inpar[]:out)


 int nummer
  decl KrlMsg_t mymessage 
  decl KrlMsgPar_t mypar[3] 


  decl KrlMsgPar_t inpar[] 
  decl KrlMsgPar_t zpar
  decl KrlMsgOpt_t myoptions 
  decl KrlMsgDlgSK_T softkey[7] 
  int nhandle ,z,f
  decl char meldetxt[]

 


   if varstate("inpar[1]")==#initialized then
    mypar[1]=inpar[1]
   endif
   if varstate("inpar[2]")==#initialized then
    mypar[2]=inpar[2]
   endif
   if varstate("inpar[3]")==#initialized then
    mypar[3]=inpar[3]
   endif
     mymessage.msg_txt[]=meldetxt[]
     mymessage.modul[]="Roboterprogramm:"
     mymessage.nr=999
     myoptions={vl_stop FALSE,clear_p_reset TRUE,clear_p_SAW FALSE, log_to_DB FALSE}
     nhandle = Set_KrlMsg (#notify, mymessage, mypar[], myoptions) 
end

Grüße,
Michael

Zitat von thoms

Was nicht funktioniert ist Aufruf:

Code

... hinweismeldung ("es funktioniert nicht")

Weil da ein OUT steht.

Ich hab zuletzt das hier verwendet:

global def melde(meldetxt[]:in)


  DECL CHAR meldetxt[]
  DECL INT ANSWER, OFFSET
  DECL STATE_T STATE
  DECL MSG_T EMPTY_MSG, Meldg
  Meldg={MSG_T: VALID FALSE,RELEASE FALSE,TYP #NOTIFY,MODUL[] " ",KEY[] " ",PARAM_TYP #VALUE,PARAM[] " ",DLG_FORMAT[] " ",ANSWER 0}
  $MSG_T=Meldg
  wait sec 0.2

        offset=0
	swrite(MELDG.KEY[],STATE,OFFSET,"%S",meldetxt[])
  $MSG_T=MELDG
  $MSG_T.TYP=#NOTIFY
  $MSG_T.VALID=TRUE


end

und hat eigentl. funktioniert...

Grüße,
Michael

Zitat von SpeedFreak

life is a beta-version....full of bugs and no manual.

Aber die Grafik ist endgeil.

Grüße,
Michael

Ich habe auch mal die x-te Nachkommastelle aus den aktuellen Achswerten als Startwert verwurstet.
Zufallsgeneratoren programmiert man normalerweise so, dass sie einen REAL-Wert zwischen 0 und 1 auswerfen. Der Rest ist multiplizieren mit dem Maximalwert und dann Runden.

Grüße,
Michael

Möglicherweise ist der Bremsentest nur scheinbar ausgeführt? Knallt er wirklich in die Bremse oder fährt er nur ein Stück mit jeder Achse?

Ich hatte den lustigen Fall, dass ich mich mit der "sicheren Geschwindigkeitsreduktion" selbst blockiert hatte. Die Geschwindigkeit wurde reduziert, weil der Bremsentest nicht erfolgt war. Der Bremsentest aber schlug fehl, weil er nicht die 100% Override einschalten konnte.... ein Teufelskreis.

Ansonsten gibts noch die Möglichkeit, den Bremsentest von aussen anzufordern über ein entsprechend konfiguriertes Systemsignal in \STEU\MADA\$machine.dat. Standardmäßig liegt der auf 1026, dauerfalse.

Grüße,
Michael

Ungefähr so (verzeih mir Syntaxfehler, bin gerade voll verKUKAt.)

pers jointtarget testjoint := [ [ 0, 0, 0, 0, 0, 0], [ 0, 9E9, 9E9, 9E9, 9E9, 9E9] ];
pers jointtarget lastjoint := [ [ 0, 0, 0, 0, 0, 0], [ 0, 9E9, 9E9, 9E9, 9E9, 9E9] ];
pers bool achse_dreht_noch:=FALSE;


lastjoint:=CJointT(\TaskName:="T_ROB1");


!Endlosschleife
while  (doutput(di_kill_task)=0)  do
  testjoint:=CJointT(\TaskName:="T_ROB1");
  achse_dreht_noch:=(ABS(lastjoint.extax.eax_a - testjoint.extax.eax_a) > 0.01);
  lastjoint:=testjoint;
  waittime 0.1;
endwhile
exit;

Erklärung:
Zwei Jointtarget permanent speichern. Eins neu einlesen, externe Achse 1 vergleichen, wenn Differenz > Minimalwert, dann Bingo. Anschließend den eben eingelesenen Wert als Altwert speichern, eine Winzigkeit warten und dann dasselbe von vorn.
Im boolschen Merker steht dann das Ergebnis, was Du sosntwo auswerten kannst, oder meinetwegen auch direkt dahinter einen Ausgang schaltet oder so.
Guck mal in der Doku bei Datentypen Jointtarget.
Der Vergleich auf 0 (also wenn Du versuchst zu vergleichen ob (lastjoint.extax.eax_a = testjoint.extax.eax_a) ) könnte fehlschlagen. Eine exakt identische Achsposition ist eher selten, daher besser auf eine gewisse kleine Mindestdifferenz testen wie im Beispiel.

Die Bedingung in "while" sollte Dir helfen, die Task zu beenden, falls nötig, dazu muss ein entsprechender (virtueller) Ausgang konfiguriert werden.
Die Task als semistatisch anlegen, und zu Testzwecken erst ohne Fehlerauswirkung konfigurieren. Später kann man dann die Bedingung verschärfen, wenn alles läuft.
Semistatische Tasks laufen immer von vorn an bei Neustart, oder wenn Du ein Programm im Haupttask auch nur einen Schritt weit ausführst. Anhalten zu Umprogrammierzwecken kannst Du sie dann immer mal mit dem Ausgang.

Grüße,
Michael

CJointT() ist aber recht einfach, es gibt einfach nur ein Jointtarget zurück, in welchem die Achsposition enthalten ist. Und eine halbe Sekunde wird den Robbi auch nicht überfordern.

Grüße,
Michael

Die stehen ganz normal darin, z. B. unter [DEVNET] oder was man sonst für ein Bussystem hat.
Proconos reißt die erst später an sich, durch eine eigene Konfiguration.

Verwirrend ist dann nur, dass es dann auch einen Haufen EAs gibt, die NICHT dort explizit auftauchen. Man kann im Multiprog nämlich EA-Bereiche definieren, die ausschließlich für die Kommunikation zwischen Roboter und SPS gedacht sind. So kann es passieren, dass Du z. B. in der EA-Ansicht einen Ausgang mit Namen findest (vielleicht sogar auf ein physikalisch vorhandenes Ding verweisend, z. B. "Greifer öffnen"), der in der IOSYS.INI gar nicht gemappt ist. Das Signal geht dann an die SPS und wird von der vielleicht weitergeleitet oder erst noch verarbeitet.

Die physischen Eingänge kann der Roboter übrigens problemlos mitlesen und verwerten. Aber separate Kommunikationseingänge (die aus Proconos-Sicht dann Ausgänge sind) kann es natürlich zusätzlich noch geben.

Normalerweise ist das egal, ich sag's nur, falls Du vorhast, die physikalischen EA zu erweitern oder vom Programm her irgendwelche (scheinbar) unverbundene Ausgänge als Merker zu missbrauchen oder so. Da könnte es nämlich zu Überschneidungen kommen. Es wäre also auf jeden Fall besser, eine EA-Konfigurationsliste oder -Übersicht aus Multiprog heraus dabeizuhaben, wenn man da heran will.

Grüße,
Michael

Die Ausgänge, die für Proconos reserviert sind, sind von der KRC aus schreibgeschützt. In Multiprog könntest Du sie forcen. Sehen kannst Du sie aber vom KCP aus.

Grüße,
Michael

Wäre ganz praktisch, wenn irgendwo ein Fragezeichen formuliert würde...

Grüße,
Michael

Zitat von Müller_87

Wenns nach mir geht soll die Überwachung dieses "Sperrbereichs" permanent aktiv sein. Ist das möglich?!

Die Weltzone kann man in einer Routine deklarieren, die man als Ereignisroutine mit dem Hochfahren des Systems verknüpft. (Das geht in den Systemparametern)
Mit dem Interrupt wäre ich vorsichtiger, man kann sich da sehr bedienerunfreundlich selbst blockieren, falls es die Robbis doch mal schaffen, gleichzeitig in die Zone zu fahren, oder falls man nur einen Robbi fahren möchte, der andere aber ein permanentes Signal vorhält. Man sollte auf jeden Fall im Handbetrieb wieder rauskommen können aus dem Schlamassel.

Wenn man es gescheit machen will und die Signale über ein Kabel austauscht, benutzt man inverse Logik, das heisst, man gibt frei, wenn das Signal vorhanden ist, und sperrt, wenn es weg ist. Dann ist man auf der sicheren Seite, allerdings fehlt dann was, wenn man nur mit einem Robbi arbeitet.

Angehalten habe ich damals (vor MultiMove) immer über StopMove; .... StartMove;

Grüße,
Michael

Wir hatten vor ein paar Wochen auch die Not, dass wir die Gerätedateien von Beckhoff runtergeladen hatten, davon arbeiteten aber einige nicht mit WorkVisual zusammen. Der Fehler erschien dann beim Import (oder war es beim Integrieren in den Katalog?) im Meldungsfenster. Betroffen war z. B. EL2xxx usw.
Abhilfe war dann ganz pragmatisch: die angemeckerten Tags in der XML-Struktur rausgelöscht, dann ging's.

Grüße,
Michael

titan: ich hab's mal spaßeshalber versucht, sinngemäß analog zum o2i-driver in KRC2, mit dem man das ja konnte, und es ging NICHT. Habe die Einzelheiten aber vergessen.

Grüße,
Michael

Ich verstehe das Problem nicht.
Char SIND Integer.

Probiert es aus:
test.dat:

DEFDAT  test PUBLIC


DECL CHAR h[5]
h[]="     "


ENDDAT

test.src:

DEF test( )


int a[5]
int z


a[1]=77
a[2]=78
a[3]=79
a[4]=80
a[5]=81


for z = 1 to 5 
h[z]=a[z]
endfor


END

Nach dem Abfahren steht in h[]="MNOPQ".

SWRITE ist da natürlich zuerst die falsche Option.

Grüße,
Michael

Such' mal im Forum nach SWRITE.

SWRITE($MSG_T.PARAM[],STATE,OFFSET,"%d",zahl)

Grüße,
Michael

Wenn Integer als Variablen genommen werden, dann ist 12 / 12 = 1. Und 23 / 12 sind immer noch 1.
Das heisst: Reihenversatz ist "(zähler_Kiste_x / 12) * Reihenabstand_in_mm". Spaltenversatz ist der Rest * Spaltenabstand. (Bei 0 zu zählen anfangen!) Damit errechnet man sich nur aus einem Zähler pro Kiste eine brauchbare Baseverschiebung.
Wenn man dann die Bases und Zähler noch in einem Array ablegt, dessen Index der Produktnummer entspricht (1, 2 oder 3) braucht man Zählschleifen und IF-Verzweigungen gar nicht mehr, sondern errechnet mit drei Sätzen das Fahrziel. (Unwahrscheinliche Vorgaben sollten aber abgefangen werden. Wenn in einem Zähler plötzlich -2987 steht, darf der Roboter keinen Mist machen.)
Rücksetzen der Zähler erfolgt nach Bedarf und wenn sicher ist, dass die Kiste gewechselt wurde. Die Zähler sollten dazu global gespeichert werden.

Grüße,
Michael

$MSG_T ist entfallen.

Grüße,
Michael