Variablen in Makros verwenden?

[Spud]

Habe jetzt mal die "EnertexLicht.lib" geöffnet, und unter anderm Namen gespeichert.
Dann die Einbindung unter [Makros] der EnertexLicht.lib gelöscht.
Wenn ich jetzt das umbenannte Makro einbinden will geht nix mehr.

Wie gesagt, ich bekomme nichts, wirklich nichts zu laufen
Ich weiß gar nicht wo ich anfangen soll wenn nicht mal so etwas funktioniert.

[Uwe!]

hast Du auch die umbenannte neue Bibliothek wieder eingebunden?

Und allgemein:

Auf Aussagen wie "es geht nix" ist es relativ schwierig mit konkreten Vorschlägen zu antworten. Eine Fehlermeldung und ein Programmausschnitt wären schon mal ein guter Anfang.

[enertegus]

Habe jetzt mal die "EnertexLicht.lib" geöffnet, und unter anderm Namen gespeichert.
Wenn ich jetzt das umbenannte Makro einbinden will geht nix mehr.

Wenn Du die Makrolib eingebunden hast, dann solltest Du einfach rechts unten die Makros entdecken und einbinden können.

Grundsätzlich können Makros so wie sie sind ohne großes Hintergrundwissen genutzt werden. Alsbald man da aber von der Anwendung abweicht und man den Code oder Argumente ändert, muss man dann doch Hintergrundwissen sich aneignen.
Besser wäre es, Du würdest einfach mal im Klartext formulieren, was Du machen willst und wir/ich geben dir den Code.
Du willst offenbar nicht auf eine GA schreiben, sondern nur eine Variable setzen.
Dazu

:begin DaemmerungsschalterZeituhr(LichtSensor,LichtWert,Lichtaktor, StundeAus, MinuteAus, StundeEin, MinuteEin)
:info $Wenn der Lichtsensor den Lichtwert unterschreitet wird der Lichtaktor eingeschalten. Überschreitet der Lichtsensor den Lichtwert, \\
schaltet der Lichtaktor ab. \\
Zusätzlich wird der Lichtaktor zeitgesteuert aus- und eingeschalten. \\
Z.B. von 22:30Uhr - 6:00Uhr ist der Aktor aus, egal ob es hell oder dunkel ist.$ \\
    $Gruppenadresse des Lichtsensor$ \\
    $Lichtwert, bei dessen Unterschreitung der LichtAktor geschalten werden soll. Angabe in Lux.$ \\
    $Gruppenadresse des LichtAktor zum Schalten des Ausgangs$ \\
    $Stunde, zu der der Aktor ausgeschalten werden soll$ \\
    $Minute, zu der der Aktor ausgeschalten werden soll$ \\
    $Stunde, zu der der Aktor eingeschalten werden soll$ \\
    $Minute, zu der der Aktor eingeschalten werden soll$
:shortinfo $Daemmerungsschalter, der einen Lichtaktor zeitlich- und helligkeitsabhängig steuert$

if convert(LichtSensor, 0u16)<LichtWert^u16 then write(Lichtaktor,EIN) endif
if convert(LichtSensor, 0u16)>LichtWert^u16 then write(Lichtaktor, AUS) endif
if htime(StundeAus,MinuteAus,00) then write(Lichtaktor, AUS) endif
if htime(StundeEin,MinuteEin,00) and convert(LichtSensor, 0u16)<LichtWert^u16 then write (Lichtaktor, EIN) endif

in

:begin DaemmerungsschalterZeituhrVariable(LichtSensor,LichtWert,Lichtaktor, StundeAus, MinuteAus, StundeEin, MinuteEin)
:info $Wenn der Lichtsensor den Lichtwert unterschreitet wird der Lichtaktor eingeschalten. Überschreitet der Lichtsensor den Lichtwert, \\
schaltet der Lichtaktor ab. \\
Zusätzlich wird der Lichtaktor zeitgesteuert aus- und eingeschalten. \\
Z.B. von 22:30Uhr - 6:00Uhr ist der Aktor aus, egal ob es hell oder dunkel ist.$ \\
    $Gruppenadresse des Lichtsensor$ \\
    $Lichtwert, bei dessen Unterschreitung der LichtAktor geschalten werden soll. Angabe in Lux.$ \\
    $Gruppenadresse des LichtAktor zum Schalten des Ausgangs$ \\
    $Stunde, zu der der Aktor ausgeschalten werden soll$ \\
    $Minute, zu der der Aktor ausgeschalten werden soll$ \\
    $Stunde, zu der der Aktor eingeschalten werden soll$ \\
    $Minute, zu der der Aktor eingeschalten werden soll$
:shortinfo $Daemmerungsschalter, der einen Lichtaktor zeitlich- und helligkeitsabhängig steuert$
if convert(LichtSensor, 0u16)<LichtWert^u16 then Lichtaktor=EIN endif
if convert(LichtSensor, 0u16)>LichtWert^u16 then Lichtaktor=AUS endif
if htime(StundeAus,MinuteAus,00) then Lichtaktor=AUS endif
if htime(StundeEin,MinuteEin,00) and convert(LichtSensor, 0u16)<LichtWert^u16 then Lichtaktor=EIN endif

Nun kannst Du das Makro entsprechend mit Variablen nutzen.

Der Unterschied ist, einmal wird auf dem Bus geschrieben write (Lichtaktor, EIN) und im anderen Fall eine Variable gesetzt Lichtaktor=EIN.

[Tessi]

Das (leidige) Validierungsschema:

In der obersten (Haupt-)Ebene

1. werden Ausdrücke neu berechnet, wenn deren Teilausdrücke (Variablen, Funktionswerte) sich ändern.
2. werden then-Zweige dann ausgeführt, wenn der Wert der Abfragebedingung (if) sich auf TRUE ändert.
3. werden else-Zweige dann ausgeführt, wenn der Wert der Abfragebedingung (if) sich auf FALSE ändert.
4. werden Ausgabe-Komandos wie z.B. write() gar nicht ausgeführt, egal ob sich eines ihrer Argumente geändert hat, oder nicht.

In tieferen Ebenen (wohl immer in einem übergeordneten then- oder else-Zweig enthalten) wird der Code nur ausgeführt, wenn der übergeordnete Zweig ausgeführt wird. Dann aber wird der Code wie erwartet quasi statisch ausgeführt, d.h. es

1. werden then-Zweige dann ausgeführt, wenn der Wert der Abfragebedingung (if) TRUE ist.
2. werden else-Zweige dann ausgeführt, wenn der Wert der Abfragebedingung (if) FALSE ist.
3. werden Ausdrücke immer neu berechnet. *)
4. werden Ausgabe-Komandos wie z.B. write() immer ausgeführt. *)

*) wobei man im Hinterkopf haben muss, das der ganze Code-Zweig, in dem sie eingeschlossen sind, ja nur manchmal in Abhängigkeit vom if in der Hauptebene überhaupt ausgeführt wird.

Weil die automatische Ausführung von Code in Abhängigkeit von von außen kommenden Änderungen an internen verwendeten Parametern ziemlich kompliziert werden würde wenn man innerhalb dieses Codes Schleifen und vergleichbares zulassen würde, hat man sie beim EibPC einfach nicht im Sprachschatz.
Da aber die Statements in der Hauptebene automatisch ausgeführt werden, wenn sich Parameter ändern, führt dies indirekt zu einer schleifenartigen Ausführung, wenn Ergebnisse gleichzeitig auch Parameter sind.
So direkte Zuweisungen vom Typ a=a+1 werden vom Compiler zwar zurückgewiesen, sobald man die Abhängigkeit aber hinter Bedingungen "versteckt", geht es. Quasi Schleifen durch die Hintertüre...


Und nun mal zurück zum Makro:

Warum kann ich GAs und Variablen nicht gleich behandeln?
Nun, eine Variable ist wie eigentlich überall nur ein benannter Speicherplatz für einen Wert eines bestimmten Typs. Den kann ich jederzeit lesen oder überschreiben ohne das zunächst einmal weiteres passiert.
Eine GA dagegen repräsentiert einen IO-Kanal (die meisten Systeme nennen so was einen Handle). Lesen von oder schreiben auf einen solchen IO-Kanal bedeutet weitaus mehr als nur lesen oder schreiben einer Speicherstelle. Fast immer steckt da eine Menge an Aktionen (Code) dahinter (meist in Bibliotheken oder in Befehlen der Sprache selbst verborgen).

Kurz, hinter dem Zugriff auf eine GA steckt eine IO-Operation, hinter dem Zugriff auf eine Variable "nur" Speicher.

Natürlich könnte ich einen IO-Zugriff so virtualisieren, das es dem System gegenüber so einfach aussieht, wie ein Speicherzugriff. KNX nutzt diese Konzept auch wenn es von Kommunikations-Objekten spricht. Beim EibPC hat man das aber nicht übernommen. Hier muss man ausdrücklich (wie bei den meisten Programmiersprachen auch) ausdrücklich einen Schreibbefehl (write()) ausführen, eine einfache Zuweisung geht nicht. Das hat Vor- und Nachteile. Vorteilig ist die größere Flexibilität in der Anwendung, nachteilig der größere Aufwand. Die Entscheidung fällt aber meist der Sprachdesigner, als Anwender muss man es nehmen wie es ist.

Übrigens kann man in den meisten Sprache auch kein IO-Handle als Argument übergeben wenn eine Referenz auf eine Variable erwartet wird.
Der Fehler der meisten Neueinsteiger ist eher der, das sie eine GA gedanklich mit einer (internen) Variablen gleichsetzen. Das ist sie aber nicht!

Es wäre übrigens denkbar, auch im EibPC Code zu schreiben, der eine Funktionalität vergleichbar den KNX-Kommunikations-Objekten liefert. Lohnt sich aber wohl nur in besonderen Fällen.

[saft6luck]

Weil die automatische Ausführung von Code in Abhängigkeit von von außen kommenden Änderungen an internen verwendeten Parametern ziemlich kompliziert werden würde wenn man innerhalb dieses Codes Schleifen und vergleichbares zulassen würde, hat man sie beim EibPC einfach nicht im Sprachschatz.

Schleifen wären durchaus möglich, wobei es ausschließlich um die Schleifen geht, die in einem Zyklus abgearbeitet werden würden.

Die berechtigte Angst von Michael ist, dass der Anwender die erlaubte CPU-Last für einen Zyklus überschreitet.

Lösbar: Beispiel, durchaus sinnvoll und leider nicht Teil des eibPC-Sprachschatzes:

For i=x to y partition 10 .... Next i

Hier gibt das notwendige Kommando partition die Anzahl der Schritte pro Zyklus an, also 10 Schleifendurchläufe, im nächsten Zyklus geht's dann weiter.

Ein Array durchsuchen geht so deutlich schneller.

Da aber die Statements in der Hauptebene automatisch ausgeführt werden, wenn sich Parameter ändern, führt dies indirekt zu einer schleifenartigen Ausführung, wenn Ergebnisse gleichzeitig auch Parameter sind.
So direkte Zuweisungen vom Typ a=a+1 werden vom Compiler zwar zurückgewiesen, sobald man die Abhängigkeit aber hinter Bedingungen "versteckt", geht es. Quasi Schleifen durch die Hintertüre...

Es gibt das Makro für eine For-Schleife

[enertegus]

Es gibt das Makro für eine For-Schleife

welches genau eine Iteration pro Zyklus ausfüht, also "partition=1" in Deiner Terminologie.

[Tessi]

Schleifen wären durchaus möglich, wobei es ausschließlich um die Schleifen geht, die in einem Zyklus abgearbeitet werden würden.

Wie willst du denn eine Schleife darauf beschränken? Der Compiler kann die Laufzeit doch kaum bestimmen. Oder soll alles verboten werden, was nicht exakt vorherbestimmbar ist?

Und wie soll das Validierungsschema damit umgehen, wenn in jedem Durchlauf mehrere Variablen sich ändern und ausserhalb der Schleife Ausdrücke davon abhängen? Diese bei jedem Schleifendurchlauf erneut auswerten? Oder erst nachdem die Schleife verlassen wird?

Die berechtigte Angst von Michael ist, dass der Anwender die erlaubte CPU-Last für einen Zyklus überschreitet.

Und das würde garantiert oft genug passieren und natürlich ist dann der EibPC schuld...
Ich kann Enertex da verstehen, auch wenn ich es auch lieber anders hätte.

Lösbar: Beispiel, durchaus sinnvoll und leider nicht Teil des eibPC-Sprachschatzes:

For i=x to y partition 10 .... Next i

Hier gibt das notwendige Kommando partition die Anzahl der Schritte pro Zyklus an, also 10 Schleifendurchläufe, im nächsten Zyklus geht's dann weiter.

Interessante Erweiterung...
Hätte ich auch gerne, aber falsch angewendet wären wir wieder im Überlastfall...
Und auch das würde garantiert wieder häufiger passieren.

Und auch hier bleibt die Frage: Wie soll das Validierungsschema damit umgehen, wenn in jedem Durchlauf mehrere Variablen sich ändern und ausserhalb der Schleife Ausdrücke davon abhängen? Diese bei jedem Schleifendurchlauf erneut auswerten? Oder in jedem Zyklus einmal? Oder erst nachdem die Schleife verlassen wird?

Das ist ein Teil von dem, was ich als "kompliziert" umschrieben habe. Es kommen eine Menge Fragen/Entscheidungen/Konflikte auf einen zu, wenn man damit anfängt. Das bedeutet ja nicht, das es nicht lösbar wäre, nur würde es für die meisten Anwender damit noch fehlerträchtiger und das Validierungsschema mit noch mehr Regeln und Ausnahmen aufgeblasen. Dabei kommen schon jetzt genug Anwender ganz offensichtlich nicht richtig damit klar...

Es gibt das Makro für eine For-Schleife

Ich sagte ja: Schleifen durch die Hintertüre, der deutlich höhere Aufwand halt nett in einem Makro versteckt.
Und wie du schon sagtest, langsam (weil umständlich) verglichen mit richtigen Schleifen.

Ich hätte auch gerne Schleifen und etliches andere, was gegenüber "normalen" Programmiersprachen fehlt. Aber ich verstehe auch Enertex, wenn ihnen das in Verbindung mit dem Validierungsschema einfach zu riskant erscheint.

[saft6luck]

Das bringt wohl nichts, dieses Thema wieder aufzuwärmen.

[Tessi]

welches genau eine Iteration pro Zyklus ausfüht, also "partition=1" in Deiner Terminologie.

Ich wollte es ja nicht so sagen, aber nun steht es ja doch hier...

Das bringt wohl nichts, dieses Thema wieder aufzuwärmen.

Nun, damit hast du mehr Erfahrung als ich...
Ich würde sagen, es kommt darauf an, was man gerade erreichen will.
Bezüglich deines Ziels wage ich die Prognose: NEIN.

Aber wie war das mit dem Apfelbäumchen?
Die Hoffnung stirbt immer zuletzt.
Und manchmal geschehen ja wirklich noch Wunder...

Aber eigentlich ging es hier ja auch nicht um ein Wunschkonzert (da würde ich an vorderster Linie mitsingen) sondern nur um das Verständnis, warum man Variablen und GAs nicht einfach mal so in einen Topf werfen kann.
Und da, hoffe ich, ist jetzt einiges klarer geworden.

[saft6luck]

Ich wollte es ja nicht so sagen, aber nun steht es ja doch hier...

Das kann man ganz offen aussprechen, ist ja kein Geheimnis. Das Makro wird eher viel zu oft übersehen.

[Spud]

Ich Danke allen für die Hilfe :-)

Jetzt funktioniert es!