Objekt in Robo Pro

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
robopro
Beiträge: 55
Registriert: 08 Nov 2010, 18:57

Objekt in Robo Pro

Beitrag von robopro » 08 Nov 2010, 19:25

Hallo,
ich weiss nicht was objekt Variablen in Robo Pro sind!
Kann mir da jemand helfen?
Grüße robopro
Grüße robopro!
Ohne ft ist alles doof!

Benutzeravatar
Endlich
Beiträge: 362
Registriert: 01 Nov 2010, 08:45
Wohnort: Ingelfingen
Kontaktdaten:

Re: Objekt in Robo Pro

Beitrag von Endlich » 09 Nov 2010, 06:35

Hallo robopro,

ich denke, da hilft dir die Anleitung zu RoboPro sehr viel weiter. Die ist auf der CD vom TX Training Lab dabei, oder du benutzt das Handbuch.

Benutzeravatar
schnaggels
Beiträge: 389
Registriert: 31 Okt 2010, 23:14
Wohnort: Kelkheim
Kontaktdaten:

Re: Objekt in Robo Pro

Beitrag von schnaggels » 09 Nov 2010, 16:01

"Ich denke" hilft hier nicht weiter...

Es gibt leider noch KEINE Dokumentation zu den Objekt Variablen, zum kompletten RoboPro Level 5 "Objekte" fehlt die Dokumentation in der Online-Hilfe. Sollte immer mal wieder kommen, ich würde mal nicht damit rechnen in nächster Zeit...

Unter dem bisherigen Account RPE hat sich der RoboProEntwickler (Michael Sögtrop) hier noch nicht angemeldet, auch im Betatester-Bereich haben wir seit 2 Monaten nichts mehr von ihm gehört oder gelesen :shock:

Gruß,
Thomas

Trophi
Beiträge: 5
Registriert: 02 Sep 2016, 17:11

Re: Objekt in Robo Pro

Beitrag von Trophi » 12 Sep 2016, 17:50

Hallo,

weiß vielleicht sonst jemand, was die Objektvariablen genau sind?

Vielleicht würde das mir bei meinem Problem extrem weiterhelfen!

Trophi

hamlet
Beiträge: 332
Registriert: 12 Jan 2011, 21:41

Re: Objekt in Robo Pro

Beitrag von hamlet » 13 Sep 2016, 22:55

Hallo,
Ich versuch mal eine oberflächliche Übersicht.

Namensgebunden: Standardmäßig ist diese Option bei Variablen aktiviert. Ich lass das auch immer so. Ansonsten hat man völlig unabhängige Variablen, die allerdings den gleichen Namen haben können. Ich vermute, dass diese Variablen mittels einer verborgenden eindeutigen ID in RoboPro unterschieden werden. Ich nutze dieses Feature nur, um schnell mal Debug-Anzeigen in Programme einzubauen. Dafür eignen sich globale und nicht namensgebundene Variablen ganz prima, da man sich nicht um den Variablen/Anzeigenamen scheren muss: Obwohl "global" und mit gleichem Namen, sind sie alle unabhängig voneinander.

Global: Tja, halt eine globale Variable mit all ihren Vor- und Nachteilen. Egal in welchem Unterprogramm oder auf welchem Prozess sie geändert wird, jeder andere Programmteil, der von dem Wert der Variablen abhängt, wird auf diese Änderung reagieren. Das ist Fluch und Segen zugleich. Sie wird einmal beim Programmstart mit dem Startwert initialisiert und danach kann jeder sie ändern und jeder kann auf Änderungen reagieren. Mit globalen Variablen kann man so recht einfach Informationen zwischen den Unterprogrammen oder Prozessen austauschen. Durch diesen Durchgriff in das Verhalten anderer Programmteile kann man durch den leichtfertigen Gebrauch globaler Variablen allerdings auch in Teufels Küche kommen. Jeder kann an jeder Stelle das Verhalten irgendwo anders im Programm verändern. Da verliert man ganz schnell den Überblick und die Fehlersuche wird ein großer Spaß.

Lokal: Der Einflussbereich einer lokalen Variablen ist begrenzt auf das Unterprogramm, in dem sie definiert ist. Von außen kann sie niemand ändern. Das gilt auch, wenn mehrere Instanzen eines Unterprogramms gleichzeitig auf mehreren Prozessen ausgeführt werden. Mit globalen Variablen gibt's da meist böse Überraschungen. Auch die Lebensdauer der Variablen ist begrenzt. Bei jedem Eintritt in das Unterprogramm wird sie auf den Startwert initialisiert und nach Verlassen des Unterprogramms ist sie vergessen. Falls man keinen Durchgriff auf andere Programmteile benötigt, sollte man immer durch Verwendung lokaler Variablen die lokalen und temporären Daten kapseln. Das hält die Komplexität gering. Falls etwas schief läuft beschränkt sich die Fehlersuche auf das Unterprogramm und man muss nicht den ganzen Rest des Programms auch noch in Betracht ziehen.

Objekt: Mit einer Objektvariablen erhält ein Unterprogramm ein "Gedächtnis". Wie eine lokale Variable beschränkt sich der Einflussbereich und die Zugreifbarkeit einer Objektvariablen auf das Unterprogramm in dem sie definiert ist. Aber der Wert der Variable bleibt beim Verlassen des Unterprogramms erhalten und steht wieder zur Verfügung wenn das Unterprogramm erneut betreten wird. Hierbei hat jede Instanz eines solchen Unterprogramms ihr individuelles "Gedächtnis", d.h. sie speichert ihre eigenen Objektvariablen unabhängig. Die Objektvariablen werden nur einmal beim ersten Betreten des Unterprogramms auf den Startwert initialisiert.
Beispiel: Das "X>N" Unterprogramm aus dem "loop"-Ordner der ft Bibliothek in RoboPro verwendet eine Objektvariable als Schleifenzähler.

Auch bei Listen kann man sowohl die Daten als auch den Index global, lokal oder objektgebunden deklarieren. … Im Prinzip ist's da genauso wie bei einfachen Variablen. Einfach mal probieren. Ein globaler Listenindex ist in den meisten Fällen eine saudumme Idee.

So und nun geht's ans Eingemachte.
Ein Rechtsklick auf eine Unterprogramm-Instanz öffnet ein Menü "Objektvariablentyp … Lokal, Global oder Objekt". Die Auswirkungen dieser Einstellung habe ich erst heute begriffen: Jede Instanz eines Unterprogramms mit einer Objektvariablen hat ja nun ein "Gedächtnis", ist also selbst so etwas wie eine Variable. Enthält nun ein Unterprogramm Aufrufe/Instanzen von Unterprogrammen mit Objektvariablen kann man mit dieser Einstellung steuern, wie sich das "Gedächtnis" der eingebetteten Unterprogramme auf der Ebene des übergeordneten Unterprogramms verhält:
  • Gobal: Kollektiv … "We are the Borg". Die eingebetteten Programme mehrerer Instanzen des übergeordneten Programms teilen sich ihr "Gedächtnis". Mhm, Komisches Verhalten.
  • Lokal: Individuell aber dement. Das "Gedächtnis" der eingebetteten Programme wird bei jedem Betreten des übergeordneten Programms neu initialisiert. Automatisch wählt RoboPro diese nicht unbedingt sinnvolle Option, was zu Überraschungen führen kann.
  • Objekt: Mit individuellem "Gedächtnis", … meines Erachtens die sinnvollste Variante. Die eingebetteten Programme einer jeden Instanz des übergeordneten Programms haben ihr eigenes individuelles Gedächtnis.
Dazu habe ich ein kleines Demo-Programm vorbereitet. Einfach mal im Simulationsmodus verschiedene Einstellungen "Objektvariablentyp … Lokal, Global oder Objekt" für die Instanzen des Unterprogramms "Sub" in "SubWrap" wählen und die Ergebnisse im Hauprogramm beobachten.

Für die ultimative Verwirrung bietet RoboPro noch die Möglichkeit bei den gelben Daten-Ein- und Ausgängen eines Unterprogramms und bei den Operatoren die Option "Global", "Lokal" oder "Objekt" zu wählen. Hier lass ich immer RoboPro entscheiden.
  • Falls ein blauer Prozess durchs Unterprogramm verläuft, wählt RoboPro hierbei "Lokal". Eingehende Werte werden an den Eingängen gepuffert und erst dann verarbeitet wenn das Unterprogramm betreten wird.
  • Falls kein blauer Prozess durchs Un,terprogramm verläuft, wählt RoboPro die Option "Objekt". Nun sind die Ein- und Ausgänge immer durchverbunden. Jede Änderung an den Eingängen wird sofort prozessiert und das Ergebnis an die Ausgänge weitergeleitet. … Das kann bei einem großen gelben Rechen-Netzwerk ganz schön teuer werden, da jedes Zwischenergebnis (unnötigerweise) komplett durch das Netzwerk propagiert wird.
=> Da macht es dann Sinn an manchen Stellen Fake-Prozesse (Prozess-Ein und Ausgang direkt verbinden) in die Unterprogramme ohne blauen Prozesspfad einzufügen, d.h. man lässt RoboPro die Ein- und Ausgänge automatisch "lokal" konfigurieren. Damit erhält man Kontrolle darüber, wann die Berechnungen in einem Unterprogramm durchgeführt werden. Solange man das Unterprogramm nicht betreten hat, werden die Änderungen/Zwischenergebnisse an den Eingängen lediglich gepuffert, die Weiterleitung ist blockiert. Durch solche Blocker lässt sich die Rechenlast in komplexen Programmen signifikant reduzieren.

Dann gibt es noch die schöne Option "Nur '=' Befehle" oder "Beliebige Befehle" für Unterprogrammeingänge. Habe ich selbst noch nicht häufig verwendet. Die Wahl "Beliebige Befehle" macht, glaube ich, nur Sinn in einem Unterprogramm ohne blauen Prozess. Da verbindet RoboPro dann automatisch immer alles mit der "Objekt"-Option durch. Die Prozessierung erfolgt instantan und nicht erst wenn das Unterprogramm betreten wird. Ansonsten verlöre man evtl. Signale an den Eingängen, da die "Beliebigen Befehle" beim Betreten des Unterprogramm-Prozess nicht nochmal zur Initialisierung der automatisch "lokal" eingestellten Operatoren wiederholt werden. Dazu steht auch nochmal was in Kapitel 6.3 der RoboPro Hilfe.

Au Backe, jetzt hoffe ich nur, dass ich selbst verstehe, was ich da verzapft habe.

Auf jeden Fall bezeichnet "Objekt" in RoboPro nicht unbedingt das was man in objektorientierten Sprachen (C++, Java, …) als "Objekt" bezeichnet.

Beste Grüße,
Helmut

Trophi
Beiträge: 5
Registriert: 02 Sep 2016, 17:11

Re: Objekt in Robo Pro

Beitrag von Trophi » 15 Sep 2016, 19:34

Vielen vielen Dank für diese ausführliche Erklärung!!!
hamlet hat geschrieben:Auf jeden Fall bezeichnet "Objekt" in RoboPro nicht unbedingt das was man in objektorientierten Sprachen (C++, Java, …) als "Objekt" bezeichnet.
So hat es mir jedoch ein ft-Mitarbeiter in einer Email geschrieben, als ich ihn wegen genau diesem Problem angeschrieben hatte. Komisch :D

Trophi

Antworten