Schaltobjekte per Variablenübergabe in aufzurufendem Macro

Bugreports und Updatewünsche an die Firma contronics
Keine allgemeinen Fragen!

Moderator: Co-Administratoren

Antworten
Zeuge
Beiträge: 170
Registriert: 14.09.2006, 21:46
Wohnort: München Harlaching

Schaltobjekte per Variablenübergabe in aufzurufendem Macro

Beitrag von Zeuge » 29.01.2007, 04:05

Hallo
Ich möchte um Programmcode zu sparen gerne Funktionen in einem Macro-Objekt realisieren, auslagern.
Dazu schreibe ich Objektnamen, Aktornamen in Variablen und Übergebe diese dem aufzurufenden Macro.

Im Aufrufenden Macro geschieht folgendes:

Code: Alles auswählen

LaufzeitBegrenzung.Objekt:="WZ_01_Deckenlicht_Dimmer_1111" ** ist vom Typ Zeichen, Aktor ist ein Dimmer
Aufrufen(LaufzeitBegrenzung)
Im aufgerufenen Macro LaufzeitBegrenzung steht z.B.:

Code: Alles auswählen

LaufzeitBegrenzung.ObjektStatus:=LaufzeitBegrenzung.Objekt  ** Typ Zahl, Erwarte als Ergebnis 0,1 oder 1-16
LaufzeitBegrenzung.ObjektLaufzeit:=StoppZeit(LaufzeitBegrenzung.Objekt) ** Typ Uhr, Erwarte als Ergebnis 00:00:00
LaufzeitBegrenzung.Objekt:=0   ** Erhoffe mir ein Ausschalten des Aktors
LaufzeitBegrenzung.Objekt einschalten  ** Erhoffe mir ein Einschalten des Aktors
Richtig aufgelöst würde der Code ja so aussehen:

Code: Alles auswählen

LaufzeitBegrenzung.ObjektStatus:=WZ_01_Deckenlicht_Dimmer_1111
LaufzeitBegrenzung.ObjektLaufzeit:=StoppZeitWZ_01_Deckenlicht_Dimmer_1111) 
WZ_01_Deckenlicht_Dimmer_1111:=0            
WZ_01_Deckenlicht_Dimmer_1111 einschalten
In Wirklichkeit schauts so aus:

Code: Alles auswählen

LaufzeitBegrenzung.Objekt hat Inhalt WZ_01_Deckenlicht_Dimmer_1111
LaufzeitBegrenzung.ObjektStatus hat immer Inhalt 0 Ist womöglich der Status der Variable
LaufzeitBegrenzung.ObjektLaufzeit hat laufenden Zeitinhalt in Form 00:02:35, scheint aber die Laufzeit der Variable und nicht des Schaltobjektes zu sein.
Frage:
Wie kann ich Aktornamen per Variable, Parameter an andere Macros übergeben
und dort die Aktoren z.B. Ein- Ausschalten usw.

Vielen Dank für Lösungsvorschläge, Anregungen
Zuletzt geändert von Zeuge am 29.01.2007, 13:51, insgesamt 1-mal geändert.
greetings Zeuge :wink:

Konfig: Windows 7 Pro 64Bit, FHZ1350PC, ca. 40 Funkkomponenten, Wetterstation und Heizungssteuerung

gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

Re: Schaltobjekte per Variablenübergabe in aufzurufendem Mac

Beitrag von gwanjek » 29.01.2007, 11:03

Zeuge hat geschrieben:Ich möchte um Programmcode zu sparen gerne Funktionen in einem Macro-Objekt realisieren, auslagern.
Wer möchte das nicht, zumindest als normaler Programmierer, der es gewohnt ist, funktional und prozedural zu strukturieren..... Sehr verständlich dein Wunsch.

Ich sehe hier aber einen Widerspruch. Erst weist du eine Zeichenkette zu:

Code: Alles auswählen

LaufzeitBegrenzung.Objekt:="WZ_01_Deckenlicht_Dimmer_1111" ** ist vom Typ Zeichen, ...
dann nimmst du diese aber an und weist sie einer numerischen Variable zu...

Code: Alles auswählen

LaufzeitBegrenzung.ObjektStatus:=LaufzeitBegrenzung.Objekt              ** Typ Zahl, Erwarte als...
Kann das überhaupt so gutgehen? Einfach die Bezeichnung eines Elements zuweisen und hoffen, auch dessen Eigenschaften übergeben zu haben und auswerten zu können?

Das würde ja echte Objektorientiertheit mit den Eigenschaften als dessen Methoden bedeuten. Wäre ja schön, wenn das hier wirklich ginge! Hast du oder jemand anders das schon mal erfolgreich bei den Makros anwenden können?

Meiner Erfahrung nach sind das hier aber noch nichtmal lokal verriegelte Variablen, weshalb sowas hier -leider- niemals überschreibfest durch andere Prozesse oder sogar parallelverarbeitbar realisierbar ist. Und das wäre dann ja der Normallfall der Anwendung derartiger gekapselter funktionaler Makros. Schließlich will man die ja von verschiedenen Stellen aus aufrufen können. Aber durch den zeitliche Abstand zwischen Setzen eines (globalen) Variablenwertes und dessen Benutzung durch Aufruf des Makros sind dem zwischenzeitlichen Überschreiben der Variablen durch andere Prozesse Tür und Tor geöffnet. Mit Objektorientiertheit würde das nicht passieren...

...Jaja, ich weiß, herstellerseitig heißt es, Parallelverarbeitung kann nie passieren. Gleichzeitig werden aber auch Ausnahmen gemacht, z.B. mit dem "warte"-Befehl. Und spätestens jeder als gekapselter Prozeß gestartete PHP-Block oder gar ein dort aufgerufenes "eval" führen zwangsläufig zur Parallelverarbeitung. Logisch, muß ja auch so sein. Denn die Welt, die diese Software modellhaft abbildet, initiirt nun mal stochastisch determinierte Events (sprich: Die Welt löst Ereignisse aus wann sie will, und nicht wann die Software das vorgibt). Und die Software hat darauf nunmal zu reagieren, wenn sie ihrer Aufgabe ordnungsgemäß nachkommen will. Und dazu gehören nunmal auch gleichzeitig stattfindene Ereignisse...

Und dann kommen diese schlimmen Anwender-Programmierer auch noch daher, und wollen Funktionalitäten zusammenfassen in einem Makro, was die Sache nochmal um Größenordnungen verschlimmert. Denn Laufzeiten begrenzen oder Meldungen absetzen oder Datenbanken beackern oder was auch immer diese Funktional-Makros dann tun, wollen dann auch noch ganz unterschiedliche Objekte gleichzeitig! Und nun behaupte bitte keiner, Gleichzeitigkeit kommt real nicht vor! Ok, in Natura vielleicht weniger, aber softwaregesteuerte Wiederholzeiten sind an Minutengrenzen gebunden, selbst eine Stunde oder ein Tag wechseln genau an der Grenze einer Minute zur anderen...

Das wär nun alles überhaupt nicht schlimm, wenn es wie überall sonst in solchen Programmumgebungen üblich, auch hier einen Weg gäbe, die zu einem Aufruf gehörenden Daten (also Parameter usw.) überschreibfest durch andere Prozesse auch genau diesem Aufruf zu übergeben. Ebenso dürfen andere Prozesse, auch nochmalige Aufrufe des gleichen Makros in weiterer Instanz, lokal deklarierte Variablen innerhalb des Makros nicht überschreiben.

Objektorientiertheit wäre dabei natürlich der Königsweg.... und wäre eigentlich heutzutage wohl auch das völlig Normale. Aber man ist ja anspruchslos.... Allerdings bis auf den kleinen Anspruch der Software-Abbildbarkeit des hier vorhandenen realen Prozessmodells. Letzteres ist auch nicht gewünscht, sondern gefordert, sonst bräuchte man diese SW außer vielleicht als Schnittstelle eigentlich nicht wirklich.

Also: Parametrisierbarkeit von Aufrufen von Instanzen(!) eines Makros bei lokaler Verriegelbarkeit der Variableninhalte innerhalb der Makroinstanz zu deren Laufzeit
  • gibts die schon / ist die stabil nutzbar? (so wie z.B. Zeuge das vorhat)
  • wenn nicht: kommt sowas irgendwann, oder wird das herstellerseitig strikt abgelehnt?


Gruß Gerd

Zeuge
Beiträge: 170
Registriert: 14.09.2006, 21:46
Wohnort: München Harlaching

Beitrag von Zeuge » 29.01.2007, 14:04

Hallo Gerd
Ich sehe hier aber einen Widerspruch. Erst weist du eine Zeichenkette zu:

LaufzeitBegrenzung.Objekt:="WZ_01_Deckenlicht_Dimmer_1111" ** ist vom Typ Zeichen, ...
dann nimmst du diese aber an und weist sie einer numerischen Variable zu...

LaufzeitBegrenzung.ObjektStatus:=LaufzeitBegrenzung.Objekt ** Typ Zahl, Erwarte als...
Das ist kein Widerspruch. In LaufzeitBegrenzung.Objekt steht ja: WZ_01_Deckenlicht_Dimmer_1111

Der nachfolgende Befehl lautet aufgelöst dann: LaufzeitBegrenzung.ObjektStatus:=WZ_01_Deckenlicht_Dimmer_1111

Und das ist ein astreiner Befehl um den Status des Objektes zu ermitteln.
Wie gesagt ist hier ein Ergebnis von 0,1 oder 1-16 zu erwarten - je nachdem ob Schalter oder Dimmer.

Und ich erhalte als Ergebnis ja auch eine 0.
Nur hat diese 0 leider nichts mit dem Status des gewünschten Aktors zu tun.
Warum kann ich nicht sagen.

Habe aber selbst schon mal den Typ zu Zeichen umdeklariert.
Ergebnis ist eine statische 0.
greetings Zeuge :wink:

Konfig: Windows 7 Pro 64Bit, FHZ1350PC, ca. 40 Funkkomponenten, Wetterstation und Heizungssteuerung

Familienvater
Beiträge: 7151
Registriert: 31.12.2006, 15:18
System: Alternative CCU (auf Basis OCCU)
Wohnort: Rhein-Main
Danksagung erhalten: 34 Mal

Beitrag von Familienvater » 29.01.2007, 20:01

Moin,

nur um auch mal meinen Senf dazu geben zu können:

Wenn Du einer Zeichen-Variablen die Zeichenfolge "1+1" zuweist, und nachher einer Variable vom Typ Zahl die Zeichen Variable zuweist, wertet er nicht die Zeichenvariable aus, dazu müsste man schon EVAL oder soetwas nehmen.

Code: Alles auswählen

strTemp:="1+1"       
lngTemp:=strTemp   ** lngTemp hat nicht den Wert 2

Vielleicht ist jetzt klarer, warum er ein Objekt-Namen in einer Zeichen-Variablen nicht "auflöst", dazu müsste man Pointer/Zeiger/Referenz-Variablen haben, und dann wäre das Chaos perfekt, da dann für Debug-Ausgaben keinerlei Möglichkeit mehr gegeben ist, den Zeiger in "Lesbare" Form zu bringen, ausser alle Objekte werden wiederum um Eigenschaften wie .NAME erweitert.

Parallelitäts-Probleme mal ganz aussen vor gelassen.

Ich habe schon öfters in meinen Makros ein ME oder THIS vermisst, da dann "Templates" für bestimmte Funktionen möglich wären, und nicht immer wieder das Objekt im Objektmakro ausgeschrieben werden müsste.

Der Familienvater,
der gerne in VB6 programmiert...

Zeuge
Beiträge: 170
Registriert: 14.09.2006, 21:46
Wohnort: München Harlaching

Beitrag von Zeuge » 30.01.2007, 04:23

Ich gebe Dir Recht Familienvater.
Meine Überlegungen gingen in die Gleiche Richtung..

Aber bei einer Programmierbarkeit des FS20-Systemes erwartet man wie ich glaube nicht zu Unrecht,
dass Objektnamen auch in Variablen zur Steuerung des Systemes verwendet werden können.

Darum meine Frage an das Forum, Contronics wie so etwas realisiert werden kann.

Deine Überlegung bezüglich einer Einführung der Eigenschaft Objekt.Name gefällt mir gut!
Anregung für Contronics!?

Liebe Contronics-Mitarbeiter, Ich bitte freundlichst um Typumwandlungs-Funktionen wie z.B. Zeichen -> Objekt :idea:
greetings Zeuge :wink:

Konfig: Windows 7 Pro 64Bit, FHZ1350PC, ca. 40 Funkkomponenten, Wetterstation und Heizungssteuerung

gwanjek
Beiträge: 76
Registriert: 18.12.2006, 17:32
Wohnort: Ostseeküste

Beitrag von gwanjek » 30.01.2007, 08:31

Zeuge hat geschrieben:Das ist kein Widerspruch. In LaufzeitBegrenzung.Objekt steht ja: WZ_01_Deckenlicht_Dimmer_1111

Der nachfolgende Befehl lautet aufgelöst dann: LaufzeitBegrenzung.ObjektStatus:=WZ_01_Deckenlicht_Dimmer_1111
Und wer bitte "löst das auf"? Wie Familienvater schon schreibt, wenn du in ein Buch reinschreibst: "1+1" wird da auch nur "1+1" drinstehen, und nicht etwa "2". Außer, dein "Buch" ist ein Taschenrechner :-) (=eval-Funktion oder sowas). Das ist eben gerade der Unterschied zwischen String- und numerischen Variablen.

Weist man einer numerischen Variablen einen String-Wert zu, kann das maximal "implizit" konvertiert werden, so lange im String ein sauberer numerischer Wert, also die Zeichenfolge einer Ziffer wie "12345", steht. Ansonsten gehört da eigentlich dann ein Laufzeitfehler wegen fehlerhafter Typenkonvertierung hin. Also ist das wohl eher ein Bug, wenn der hier nicht erscheint, oder?

Aber das, was wir beide oder alle drei wollen ist doch das gleiche: Echte Makro-Objekte im objektorientierten Sinne, denen man als Methoden andere Objekte oder die Parameter mitgeben kann. Dann wäre sowohl ein sauberes "Template"-Handling als auch ein instanzen-gekapseltes Abarbeiten gegeben. Genau deshalb gibt es diese Sachen ja schließlich auch in der Informatik.

Meine Frage ist nur: Wenn das wirklich jetzt schon in der SW gehen sollte (sorry, im Moment keine Zeit das selbst zu probieren), ist da vielleicht schon sowas eingebaut??? Also implizites Objekthandling durch Zuweisung des Objektnamens? Das kann aber nur Contronics beantworten.

Interessant wäre dann natürlich deren "offizielle" Schnittstellenbeschreibung, um das dann im Projekt auch stabil und mit zukunfstsicher verwenden zu können.

Übrigens glaub ich auch schon, daß ich weiß wovon ich rede. Schließlich mache ich beruflich seit 18 Jahren nichts anderes (Java, Perl, Javascript, ASP, VBasic, SQL). Ach ja, und Prozeßprogrammierung übrigens auch... :-)
Zeuge hat geschrieben:Aber bei einer Programmierbarkeit des FS20-Systemes erwartet man wie ich glaube nicht zu Unrecht,
dass Objektnamen auch in Variablen zur Steuerung des Systemes verwendet werden können.
Ich formuliere es mal anders, noch weicher eigentlich: Ich erwarte einfach die Möglichkeit, prozedural zu programmieren. Ich weigere mich heutzutage einfach strikt, mehrere hundert Zeilen Code z.B. für eine einfache Durchschnittsbildung zu schreiben, die noch dazu dann systembedingt ungenau ist oder gar noch für jedes Werte liefernde Objekt neu geschrieben werden muß. Oder gleiches fürs Handling von auszukoppelnden Nachrichten (Steuerung ob Bildschirm, Logdatei, Alarm-SMS usw)... Das jedesmal neu zu schreiben ist einfach vorsintflutlich und seit Einführung von "Unterprogrammen" überholt! Es muß ja noch nichtmal OOP sein (objektorientierte Programmierung), aber wenigstens prozedurales kapseln von Code sollte gehen, oder zumindest ein Weg eröffnet werden, selbstgeschriebene Bibliotheken einzubinden und auch noch stabil laufen zu lassen. Und da gehören dann sauber übergebene Parameter, die sich zur Laufzeit nicht noch gegenseitig überschreiben können, natürlich dazu.

Gruß Gerd

Antworten

Zurück zu „homeputer Studio / Standard: Bugs & Updatewünsche“