Software Request an KUKA Roboter (der Roboterforum Wunschzettel)

[fischertech]

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

[dust2]

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

[Robotnik]

@dust2

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)

[IrrerPolterer]

Leute! Bleibt doch mal realistisch....

[MaBo]

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.

[fischertech]

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

[Robotnik]

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.

[Hermann]

Hallo dust,

...

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!
..

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

Hermann

[dust2]

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

[privet199]

Ich wünsche mir:


Not-Aus mit Schrei- ,  Sprachsteuerung. 

[WolfHenk]

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

[privet199]

..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 "    "

[WolfHenk]

"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"

[Schybulla]

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

[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. )