Der Roboterforum Wunschzettel an KUKA Roboter (Soft.- und Hardware Request)

- Programm-Module
- kein Windows mehr
- keine Festplatten mehr
- Socket Messaging aus dem Echtzeitsystem heraus
- CODESYS als Soft-SPS

dust2

Zwei Links zu Thema 4D Arrays beziehungsweise MehrDimensionalen Arrays
[url=http://wimmer.teamchris.info/joomlatest/content/view/84/53/lang,de/]http://wimmer.teamchris.info/j…ntent/view/84/53/lang,de/[/url]
http://de.wikipedia.org/wiki/Feld_%28Datentyp%29

Für den speziellen Fall des 4D Array nochmal ein genauere Beschreibung

Wie die vorhergehende Artikel es schon beschreiben werden alle n-Dimensionalen Arrays stehts gleich beschrieben bzw gespeichert.
Es bedarf stets 2 Dinge
Nr 1 Berechnung des Speicherbereiches für das Array
Nr 2 Ermittlung des Indexes des Arrays für ein angegebenes Feld

BSP:

Ich benötige ein 4D Array Folgender Grösse [2,4,2,2]
Nun muss man sich die Frage stellen, wieviel Speicher dieses Array benötigt
Wir möchten der Einfachheit halber den DatenTyp BOOL speichern also Bits.
Hätte Ich ein Ein-Dimensionales Array der Grösse 2 so bräuchte ich 2 Bits um diese zu speichern
Erweitere ich dieses Array um eine Dimension der Grösse 4 so benötige ich 8 Bits(Die Anzahl der Speicherbereiche für alle Vorhergehenden Dimensionen multipliziert mit der Grösse meiner neuen Dimension. Also in diesem Fall 2*4=8 )
Die nächste Dimension Nr 3 folgt dem gleichen Prinzip
Somit ergibts sich eine Speichergrösse von 16
Bei der 4 beträgt die Speichergrösse dann 32
Somit benötige ich 32 Bits an Speicher
(Kurzum erkennt man, dass man einfach nur alle Dimensiongrössen miteinander multiplizieren muss 2*4*2*2=32)

Als 2. Der Index.
Um den Index zu berechnen muss man für jede Dimension wissen, wieviele Felder im Speicher die jeweils nachfolgenden Dimensionen belegen.
Die Speicher Belegung eines Arrays definiert sich ja über die Multiplikation aller Dimensionsgrössen.
Für unser Beispiel eines Feldes [2,4,2,2] belegen folglich die letzen 3 Dimensionen 4*2*2= 16 Speicherplätze
Auf diesen SpeicherPlätzen sind alle Werte unseres Arrays für den (FeldIndex 1) =1 gespeichert also[1,1-4,1-2,1-2]

Somit ergibt sich eine Art Offset,der SpeicherBereichAnfangsSprungOffset (SBASO) für eine DimensionsIndexerhöhung
Alle Dimension, ausser die Letzte, bestitzen solch einen SpeicherBereichAnfangsSprungOffset der angibt um wieviele Felder sich die Adresse in unserem Speicherbereich verschiebt wenn sich der DimensionIndex um 1 erhöht

Für unser Beispiel:
hat die 2.Dimension einen Offset von 4 Also 2*2 (3. und 4. Dimension)
und die 3. Dimension einen Offset von 2 (4.Dimension)
Nun kann man den Speicherbereich mit diesen Werten berechnen
Wenn ich nun den Bereich oder Index im Speicher für (2,3,2,1) Berechnen möchte
rechne ich einfach: Index= (Index1-1)*SBASO1+(Index2-1)*SBASO2 + (Index3-1)*SBASO3 +Index4
Index = (2 -1) * 16+(3 -1)* 4 + (2 -1)* 2 + 1
Index= 27

Nun zu KRL
Man schreibt sich ein Modul in dem man in der Dat ein einDimensionales Feld generiert
Die Grösse definiert sich über die Anzahl der Dimensionen n von seinem Mehrdimensionalem Array und den Dimensionsgrössen derer(siehe oben)
Nun schreibt man sich in der SRC z.b. Globale Funktionen um mit dem Array zu arbeiten
zb.
setValue(Index1, Index2, Index3, Index4,Value )
getValue(Index1, Index2, Index3, Index4)
clearAll()

Die Grösse seines Arrays ist durch die maximale Grösse des einDimensionalen Arrays in Bezug auf den Datentyp begrenzt. wobei man diese Grenze auch übergehen kann in dem man seine Daten in mehreren einDimensionalen Arrays speichert.

ahh danke, ja da hätte ich eigentlich auch selber drauf kommen sollen. Ich habe einfach zu weit gedacht und nicht von Grund auf gedacht
aber danke für die Ausführung.

Eine gute Lösung - Danke

Hallo Dust2.

Dein Eintrag interessiert mich näher.
Kannst Du auf Deine Motivation zu diesen Aufzählungen näher eingehen?

Warum kein Windows und keine Festplatte? Hast Du Erfahrung mit anderen Fabrikaten?

Danke.

Gruß Roland

Hallo Roland,

hier die Motivation für meine Weihnachtswünsche:

1. Programm-Module:
Iststand: der Compiler bestimmt die oeffentliche (globale) Hauptprozedur(/-funktion?) eines Moduls anhand der Uebereinstimmung des Prozedurnamens mit dem Dateinamen.
Wunsch: beliebig viele öffentliche Prozeduren(Funktionen) mit modulweit bekannten Variablen (die gibts ja schon)
Damit könnte man Prozeduren funktional prima zusammenfassen, z.B. alles was mit Greifer zu tun hat, z.B. in einem .src-Modul!
Wenn man nun noch öffentliche Zugriffsfunktionen für modulweite Variablen (Properties) schreibt, erreicht man fast schon eine Kappselung wie bei OOP!

2. kein Windows mehr auf der Steuerung!!
hab lange überlegt, ob ich das hier schreibe, denn dieses Forderung ist hochpolitisch und ne abolute Grundsatzfrage! Aber ich sehe das einfach so und bin für Gegenargumente offen:

Der Endanwender (und nur um den geht es ja letzendlich) hat in der Produktion keinen funktionalen Nutzen von Windows!
Ich als Systemintegrator kann es nicht nutzen, darf ja keine weiteren Programme installieren. Windows nutzt mir also gar nichts, außer das ich keinen Laptop zum Programmieren brauche. Ich fahre aber lieber mit nen Laptop zum Kunden, auf dem eine komplette Entwicklungsumgebung inkl. Simulation und Netzwerkzugriff installiert ist und mit der ich jedes Robotersystem mit ein paar Schlüsseln in fünf Minuten nacherzeugen kann, als mit einer Tastatur und ner Maus und nen Stapel CDs untern Arm!
Ich erbe also vom Windows nur die bekannten Probleme (such mal hier im Forum nach Registry und achte auf den Robotertyp in den Beiträgen, dann weißt Du was ich u.A. meine).

3. keine Festplatten mehr:
Ich hatte neulich eine Plattenausfall(fehlerhafte Sektoren) von einem Roboter Lieferjahr 2004, wenn man da kein Image hat, wirds ne lange Nacht! (Fernwartung ist ja dann auch nicht mehr)
Wäre echt mal interessant, was Großanwender (die Automobillisten mit Ihren 500 Robotern oder die harten Jungs aus der Schmiede mit extremen Umgebungsbedingungen für Ausfallraten haben?)

4. Socket Messaging aus dem Echtzeitsystem heraus:
macht sich gut, wenn man Positions- oder Sensorwerte schnell und ohne Umstände an einen externen PC oder Robi zur Auswertung schicken möchte oder mit intelligenten Kameras kommunizieren will

5. CODESYS als Soft-SPS:
ist halt mehr verbreitet als PROCONOS und super zu programmieren

Dem Endanwender sind solche Dinge schnuppe, der will nur, das der Robi robotet und das tun die KUKAs dann ja auch fast immer!

Mal sehen was der Weihnachtsmann bringt.....

Grüße dust2

dust2

Zitat

2. kein Windows mehr auf der Steuerung!!

Es ist schon eine Zeitlang her (halbes Jahr) da wurde meine Frage an einen Kuka Mitarbeiter, warum nicht Linux als Basis des Robotersystems folgend beantwortet:
Wenn wir eine freie Software unter GPL verwenden, kann ja jeder einen Bug einbauen und unser System lahmlegen.
So ungefähr jedenfalls, mit meinen Worten wiedergegeben.

Mittlerweile ist Linux standardmäßig echtzeitfähig, zumindestens Debian, das den Ruf eines Bastelsystems schon lange nicht mehr verdient.

Kuka könnte einen Softwarestand nehmen, diesen selber pflegen und erst nach Prüfung, neue Softwarekomponenten integrieren.
Keiner hat die Möglichkeit VXWORKS zu manipulieren, weil die Pflege bei einer Firma liegt.
Dies würde unter Linux genauso funktionieren.

Wenn Kuka noch lange Linux verweigert denke ich, werden Systeme auf Linuxbasis, evtl. mit der OpenRObotControlSoftware (OROCOS) die Windowsvariante verdrängen.
Die Uni Karlsruhe (www.ira.uka.de) hat schon eine Grundlage geschaffen, die den Linuxroboter, der stabiler und flexibler, modular gestaltbarer, in greifbare Nähe rücken lässt.

Sollte Kuka, die in meinen Augen der Ferrari unter den Robotern Steuerungseitig sind, nicht bald reagieren, werden Ihre durchaus gelungenen Manipulatoren unter dem Logo anderer Hersteller vermehrt zu sehen sein.
(Reis füllt Ihre Produktpallette jetzt schon mit KukaMechaniken in Verbindung mit Hauseigener Steuerung auf, die sich in der Genauigkeit, Haltbarkeit sowie in der Verarbeitung mit den Mechaniken anderen Herstellern jederzeit messen kann)

Leute! Bleibt doch mal realistisch....

Nun, ich kann Robotnik nur zustimmen.

Ich arbeite mit Windows als auch mit Linux, und in meinen Augen ist Linux das System der Zukunft. Schon allein im Bereich der Serverbetriebssysteme macht Linux schon seit langem die bessere Basis aus. Zudem stürtzt ein Windowssystem immer noch öfter ab als ein Linuxsystem, das kann ich aus eigener Erfahrung sagen.
Ich würde es sehr begrüssen wenn KUKA auf Linux umsteigt, Siemens hat es schon getan.
Die neuen Maschinensteuerungen, das weiss ich, hab schon drauf rumgespielt, werden schon mit Linux ausgeliefert.
Weitere Vorteile sind, es ist weniger anfällig für Viren und der gleichen.

Also Firma KUKA, kein intresse in die Zukunft zu investieren?
Ich denke es ist Zeit dies zu tun.

Gruss

M.B.

Ich stelle in letzter Zeit WindowsXP bei den Robis auch immer mehr in Frage.
Ich kenne mich zu wenig in Windows aus und weiß deshalb nicht, ob eine "kleinere" Version von Windows nicht auch anpassbar wäre für die Robis.
Fakt ist jedoch bei unseren Kunden, dass wir das KCP bei immer mehr Neuanlagen fast vor den Bedienern verstecken sollen. Den Kunden ist es lieber ein zusätzliches Display zu installieren mit den nötigsten Funktionen - aber ja nicht das KCP dafür verwenden.
Ich frage mich auch ob die ganze Entwicklungsumgebung wirklich mit Draufgepackt werden muss.

Die Bedienung des Roboters und der Anlage über ein Display ist so nicht machbar bei uns und unseren Kunden.

Mir wäre ein einfaches, günstiges, stabil laufendes System lieber.
Wenn ich nur schon an die tausen INI-Dateien denke die man zur Installation ändern muss (configmon.ini, iosys.ini, ...).
Fakt ist auch, dass einem das draufpacken einer zusätzlichen Visualisierungs- oder Bediensoftware nich einfach und günstig gemacht wird. Eine einfache und günstige Schnittstelle zur Integration in die BOF vermisse ich.

Und mit CoDeSys muss ich voll zustimmen. Das fehlt auch.

Dennoch ist die Hochsprache KLR finde super.

Aber nun lasse ich mich mal überraschen was uns der Weihnachtsmann für nächstes Jahr bringt.

Gruß Roland

Mir fehlt seit neuestem eine Funktion PulseVar(bBooscheVar,State,Time)
Soll einen Roboter in den Simulationsbetrieb nehmen ohne etwas am Quellcode zu ändern.
Jetzt hab ich die EA's über den Sub.sps entkoppelt

If Not bSimulation Then
diSignal = simdiSignal
...
Endif
Alle Signale wurden mit einem "sim" erweitert und die orginal Signals als Bool und Int's deklariert. funktioniert toll, nur die ganzen Pulse(Signal,...) kann ich jetzt vergessen.

Hallo dust,

Zitat von dust2

...

1. Programm-Module:
Iststand: der Compiler bestimmt die oeffentliche (globale) Hauptprozedur(/-funktion?) eines Moduls anhand der Uebereinstimmung des Prozedurnamens mit dem Dateinamen.
Wunsch: beliebig viele öffentliche Prozeduren(Funktionen) mit modulweit bekannten Variablen (die gibts ja schon)
Damit könnte man Prozeduren funktional prima zusammenfassen, z.B. alles was mit Greifer zu tun hat, z.B. in einem .src-Modul!
Wenn man nun noch öffentliche Zugriffsfunktionen für modulweite Variablen (Properties) schreibt, erreicht man fast schon eine Kappselung wie bei OOP!
..

Alles anzeigen

Das gibt's schon.
Schreib mal in einer lokalen Prozedur 'Global' vor das DEF.

Hermann

Hallo Hermann,

oh ja, hast recht, habe gerade ausprobiert und es funktioniert! War aufgrund des zitierten Satzes aus irgendeiner Doku nie auf die Idee gekommen, das der Compiler Prozeduren mir anderslautenden Namen finden kann? Wie findet der die denn jetzt eigenlich? Egal super ein Wunsch weniger

Danke..

dust2

Ich wünsche mir:

Not-Aus mit Schrei- , Sprachsteuerung.

..ochneee....
Dann komme wieder 25 Deppen vorbei, machen AAAAH! und ich muß unter der Anlage rauskriechen zum Quittieren. Niemals....

Zitat von WolfHenk

..ochneee....
Dann komme wieder 25 Deppen vorbei, machen AAAAH! und ich muß unter der Anlage rauskriechen zum Quittieren. Niemals....

Quittieren muss auch Sprachgesteuert sein.

So was änliches: "Bittttttte!!!! Quittieren!!!!!! Bin doch Roboterprogrammierer!!!!" und am Ende " "

"Computer!"
"Biep Biep"
"Quittiere Notaus, Richte Phaserbänke auf Fehlalarmierer aus und dann Feuer!"
"Biep. Notaus Quittiert, Phaserbänke ausgerichtet. Programmierung nach drittem Gesetz verbietet Feuer auf menschliches Wesen."
"Computer, das ist kein Mensch, das ist ein SPS-Programmierer!"
"Biep. SPS-Programmierer. Verstanden. Ziel zerstört"

Hallo WolfHenk

Also ich generiere immer ein Phase 5 Eindämmungsfeld, das jeden der vor meine Anlage rumschreit assimiliert.
Bei dem Typen werden dann die Phaserbänke rekalibriert und anschließend läuft er als statische Null mit den ganzen
anderen Borg willenlos und sabbernd durch die Gegend.
Es werden zwar langsam zu viele, aber eine kollektive Null ist wenigstens konstant und berechenbar.
Gruß
Schybulla

Zitat von privet199

Ich wünsche mir:

Not-Aus mit Schrei- , Sprachsteuerung.

Sprachakzent soll auch erkannt werden

(Türkisch, Bayerisch- hayab, Saksonisch - weischt du, Kroatisch, Russisch, u.s.w. )