Beiträge von Hermann

Da wirst Du um Handarbeit nicht rumkommen.
Für "Sternpukte" ist mir keine Möglichkeit bekannt sie in Berechnungen zu verwenden.
Wenn es nicht allzu viele Punkte sind, dann von Hand kopieren und "benamte" Punkte
daraus machen, mit denen kannst Du dann rumrechnen.
Andere Möglichkeit: im Werkobjekt den uframe benutzen und dort die Verschiebung eintragen.

privet199:

Bei der indirekten Basevermessung wird eine Verschiebung und drei Verdrehungen berechnet. Dazu benötigt man anscheinend 4 Punkte evtl. reichen auch 3 (müsste man mal drüber nachdenken).

Bei Deiner Aufgabe kann man eigentlich nur eine Verschiebung und eine Verdrehung ausrechnen, da die Kamera nämlich keine Tiefeninformation hergibt, sondern nur zwei Koordinaten. Zusätzlich kommt bei der Kamera dann noch der Abbildungsmasstab in X- und Y- Richtung dazu.

Was willst Du jetzt mit der Formel für die indirekte Basevermessung? Die wird Dir da nicht weiterhelfen. Da reitest Du auf dem völlig falschen Pferd.

Die Lösung zu Deiner Aufgabe ist Höhere Mathematik, und wenn sie einer hier in der Schublade hätte, dann würde er sie Dir vielleicht geben, wahrscheinlicher anbieten.
Um sich die Lösung selber zu erarbeiten wird man deutlich mehr als eine Stunde benötigen, und so was kannst Du von keinem unentgeltlich verlangen.

Nur mal so meine Gedanken dazu:
aus zwei abgelegten Klötzen kann man schon mal die Verdrehung ausrechnen. (Einfach der Winkel zwischen den beiden durch die Klötze gehenden Geraden, jeweils einmal auf der Kamera und einmal in der wirklichen Welt).
Wenn man dann den dritten Klotz senkrecht vom ersten Klotz parallel zur X-Achse der Kamera legt, und den vierten parallel zur Y-Achse, dann kann man sich daraus die Abbildungsmasstäbe in x- und y-Richtung errechnen.
Die Verschiebung sollte sich dann eigentlich auch noch berechnen lassen.

Sorry für das zu faul, hat sich halt irgendwie so angehört, als ob da alles auf den Roboter abgeschoben werden soll.
Manchmal denkt man nicht daran, dass andere das Allernaheliegendste nicht eh schon wissen und eben mal kurz auf dem Schlauch stehen.

Zu der Crash-Gefahr:
Man kann ja auch beim Umschalten auf EXT im SPS.SUB explizit das gerade angewählte Programm abwählen,
und dann das richtige Programm anwählen. In diesem Programm wird dann eine vernünftige Grundstellungsfahrt
gemacht, oder wie im CELL.src ein check auf home.

Ansonsten:
Im Automatik geht's gar nicht.
Im Ext liegt's wie schon richtig bemerkt an der fehlenden Flanke am ext_start.
Kann man doch in der SPS mit einem Federstrich beheben (wie oben schon beschrieben).
Ist das eher ein akademisches Problem, oder ist der SPS-Programmierer zu faul?
Auf dem Roboter alleine geht es ohne Hilfe der SPS nicht. Man könnte höchstens
einen Ausgang am Roboter durch die SPS wieder auf den Eingang ext_start zurückschleifen.
Aber was soll der Krampf? Da bastelt man im Roboter rum, am Ende blickt keiner mehr durch
und dabei ist es sehr einfach in der SPS zu lösen.

Und dann viel Spass bei der Master-Konfiguration. . Soll heissen, dass das nicht nur eine Zumutung ist, sondern schon an Körperverletzung grenzt.

180 Grad ist kritisch, 179.9 gehen. Ich hab' da immer 3 mal 120 hergenommen.

Da hab' ich mir mal die Mühe gemacht und nachgesehen wo das ganze gespeichert wird.
Naja landet halt wie üblich in der Registry. Dann eine .REG-Datei erstellt, seither geht das
ratzfatz: Doppelklick auf die reg-Datei und fertig.
Siehe Anhang.

Projektleiter sind immer der Meinung eine Aufgabe ist sehr einfach.

Aber die Ursprüngliche Aufgabenbeschreibung lautete:
" Möglicher Ablauf:

1. Praktisch der Roboter nimmt 4 Messbauteilen und liegt diese aufs Kameramessfeld.
..."
Hört sich nicht so an, als ob die Kamera am Roboter montiert wäre. ---> keine Hand-Eye-Calibration.

Denk' nochmal nach und beschreibe die Aufgabe etwas genauer. Oder frag den Projektleiter,
der weiß ja anscheinend wie es geht.

Naja, und warum dann nicht im ursprünglichen Thread weiterschreiben?
http://www.roboterforum.de/rob….0.html;msg40389#msg40389

Und da erst mal die Frage beantworten. Denn die gilt hier genau so.
Zu wenige Infos, um richtig helfen zu können.

Zu dem Beispiel siehe:
http://www.roboterforum.de/rob….0.html;msg28036#msg28036 (war ca. EINE Minute Suche )
Wird Dir aber wahrscheinlich nicht viel weiterhelfen, vermute mal dass da etliche Grundlagen fehlen.

Kann es sein, dass die Messeinrichtung eine Kamera ist??
Und ja, ich hab' da eine Idee. Da gab's hier im Forum schon mal ein Beispiel wie man die Base aus drei Punkten ausrechnen kann.

Wozu soll denn das ganze gut sein?
Einfach nur zum Spass irgendwelche Bases ausmessen, oder soll da auch etwas praktisches damit angefangen werden? Wenn da auch ein 'tieferer Sinn' dahintersteckt, dann wäre es besser den mal zu erklären.

Ich hab' auch schon Kamerakoordinaten im Roboter verwendet, da hat mich zumindest der Kameranullpunkt nicht im geringsten interessiert.

Und Notfalls noch einen Puls auf $conf_mess

Na dann doch einfach mal in der verdächtigen Routine ein CONFL \off einfügen. Und nochmal probieren.

Nun mal nicht gleich übertreiben. DAs Lehrbuch muss erst noch geschrieben werden.

Jo genau,
man sieht oder hört manchmal von so seltsamen Dingen die sich Grundstellungsfahrt nennen, und beim näheren Hinsehen dann eher Crashfahrt oder Garnichtfahrt heissen sollten. War halt etwas Ironie oder Sarkasmus dabei, war niemand persönlich gemeint.

Also hier für die Begriffsstutzigen (hab' ich's so schlecht erklärt?)

DEF haupt( )
INI
INTERRUPT DECL 1 WHEN $in[E_RESET]==TRUE DO RESTART ( )


Loop
 ; falls man fähig ist sowas zu programmieren:
 GRUNDSTELLUNGSFAHRT()
; Hauptprogramm
 MAINLOOP ( )  ; Aufruf der Hauptschleife, wegen Interrupt 1
endloop
END ; of hauptprogramm


DEF  MAINLOOP ( )
INTERRUPT ON 1


; Hier das Hauptprogramm
; Meistens auch wieder eine Endlosschleife


END


DEF  RESTART ( )
 BRAKE  ; Bewegung abbrechen
 INTERRUPT OFF 1
 wait sec 0
 RESUME  ; Ruecksprung in das Aufrufende Programm (dort wo Interrupt 1 deklariert ist)
END

So wie's der Polterer vorschlägt wird es wohl auch funktionieren, aber der erste Ansatz funktioniert ebenso. Wurde von mir schon in mehreren Anlagen (denke mal dürften deutlich über 100 sein) erfolgreich eingesetzt.
Entscheidend ist dabei wie man das Hauptprogramm aufbaut:
- Prozedur verwenden wie von OHuuck skizziert.
- Endlosschleife vor der man den Interrupt für den Reset deklariert,
- in dieser Endlosschleife ruft man nun das eigentliche Hauptprogramm auf, und fertig.
Mir ist diese Lösung lieber, da sie ohne globale Variable mit 'Seiteneffekten', die im Submit ausgelöst werden auskommt.

Die Methode hört sich für mich schon mal in der Beschreibung kompliziert an, wird dann in der Anwendung auch nicht wirklich 'kinderleicht' sein. Ausserdem möchte ich das System mal in der Produktion sehen, da ist meist nicht halb so viel Platz um den Roboter/die Vorrichtungen wie auf den Bildern.
Nichts desto trotz finde ich die Idee gut.
Ich selber habe schon einige Anwendungen in entfernt ähnlicher Art verwirklicht, die auch tatsächlich täglich verwendet werden (schon seit mehreren Jahren). Erfahrungsgemäss lohnt sich das nur bei quasi täglich neu einzurichtenden Bahnen (sowas gibt's). Für das Einrichten eines Programms, das dann über Wochen/Monate oder gar Jahre praktisch unverändert abläuft dürfte der Installationsaufwand die gesparte Zeit für's Teach-In wieder auffressen.

Nur mit Bus, ohne RSI.

Auf der MFC-Karte ist ein Device-Net Master vorhanden, grüner Combicon-Stecker (heisst glaube ich so) mit 5 Kontakten.

Für eine 'Buskommunikation' brauchts auf PC-Seite (oder was auch immer da angeschlossen werden soll) einen Device-Net Slave (für PC's gibts das z.Bsp. von Hilscher).

Die 'Kommunikation' sieht dann so aus, dass man einzelne dig. Eingänge / Ausgänge setzt / zurücksetzt. Wenn Zahlenwerte (Sensorwerte) übergeben werden sollen, dann werden eben einzelne Bits zu Bytes, Worten oder Doppelworten zusammengefasst.

Naja,
die Include-Anweisung ist in allen mir bekannten 'Sprachen' genau so implementiert:
Da wird schlicht und einfach der Text aus der Include-Datei so behandelt, als würde er an der Stelle des Include-Befehls stehen.